At OOPSLA 2019, the Flapjax paper won the conference’s Most Influential Paper Award. This award is given every year to an OOPSLA paper published 10 years before deemed most influential over the intervening period. Looking at the paper’s authors, there is an interesting set of affiliations: two at Brown, one at Berkeley, one at Penn, two at Google, and one at Microsoft. How did all these companies and universities come together? How did these authors even find one other?
They didn’t. All the authors were at Brown, where the work was done. But the paper appeared so much later that they’d almost all graduated and dispersed. How did this happen? This article, written by four of the seven authors of the paper, outlines the Flapjax language but more importantly focuses on the milieu of its creation: a language design principle, and the process that led to the paper.
JavaScript Then
It must be hard to believe now, but in the early 2000s, browsers routinely had JavaScript turned off. JavaScript had been merely an annoying way of creating scrolling banners on Web sites, and most users had little use for that.
Things changed with systems like Google Maps and Gmail. They exploited the XmlHttpRequest primitive to combine the benefits of Web applications with the interactivity of their desktop counterparts: whereas previously every click required a page reload (yes, children, that’s how we zoomed our maps!), now Web applications could appear just as smooth as desktop ones. (Despite this, one of the paper’s reviewers, noting that Flapjax runs atop JavaScript, said, “Flapjax programs therefore run on 90% of web browsers.” Even in 2009, JavaScript penetration was not considered total!) But JavaScript arrived with few useful program design abstractions; Flapjax was designed to fill that gap.
To understand the lack of abstractions, transport yourself back to 2006. We’ll illustrate it with a concrete example below. But if you want to skip the code and the rest of this section, it’s enough to know this: this new context presents an old problem, that of inversion of control. Due to its execution model, JavaScript condemns programmers to “callback hell”. Very little is compositional; most work is done through side-effects. A page element obtains its value from computations distributed throughout the program, so reasoning about even simple programs can be staggering. Debugging, sharing code, and other best practices become very hard.
To illustrate this concretely, imagine you’ve been asked to write a stopwatch program to run on the Web. It counts time upwards, starting from zero. There’s a Reset button; when a user clicks on it, the time goes back to zero, then starts counting up again. You might write:
var timerID = null;
var elapsedTime = 0;
function doEverySecond() {
elapsedTime += 1;
document.getElementById('curTime').innerHTML = elapsedTime; }
function startTimer() {
timerId = setInterval(doEverySecond, 1000); }
function resetElapsed() {
elapsedTime = 0; }
<body onload="startTimer()">
<input id="reset" type="button" value="Reset" onclick="resetElapsed()" />
<div id='curTime'> </div>
</body>
The program dependence graph for this tiny program is staggering. The program’s goal is to fill the curTime element. Its value is set by the document.getElementById, which gets its value from elapsedTime, which is modified by doEverySecond. This is triggered every second by setInverval, which is in startTimer, which is (phew) invoked in onload. But there’s more! It’s also modified indirectly by resetElapsed, because it modifies elapsedTime; in turn, resetElapsed is called by the reset button.
Language Design Philosophies
We don’t talk as often as we should about programming language design philosophies. Therefore, before moving on to what Flapjax is, let’s pause for a moment to consider its driving philosophy. Many researchers start from mathematical axioms. But there are other possibilities, too. We have tended to follow this principle:
Explicitly or implicitly, programming languages mirror application domains. The best languages weave the concerns of a domain through a compatible computational model.
There are two ideas here. First, an application domain can also be the source of design. Second, a language should combine domain abstractions with a compatible computational model. Finding or creating those compatible models should be the métier of a programming languages researcher.
The Flapjax Response
Concretely, in response to what we noticed in JavaScript, we created the language Flapjax, borrowing from dataflow programming languages, especially functional reactive programming (and also inspired by temporal logic). In Flapjax, the above program becomes
stTm = nowB.valueNow();
showTime(
nowB – $E('reset','click')
.snapshot(nowB)
.startsWith(stTm));
nowB is a “behavior” that always represents the current time. valueNow snapshots its value at the time of evaluation. $E(‘reset’, ‘click’) turns the reset button’s click events into a stream. These are transformed (.) into another behavior, which records (snapshot) the time (nowB) when the click occurred (valueNow and snapshot are similar operations on different datatypes); its initial value is given by the time when the program started (stTm). Consequently, the timer and the button have been turned into active values that automatically generate updates to the program’s behavior (the - (subtraction) is automatically lifted to operate over these values). When something (such as nowB) changes, updating all the values to keep them consistent is a job for the language, not for the programmer. The expression thus captures the relationship at all times.
The reader might complain that this isn’t a fair comparison: we haven’t shown the definition of showTime. In a sense, that’s the point. We have a clean separation between the HTML that defines the page’s static structure and the code that defines its dynamic behavior. The HTML just needs to refer to its parameter in the right place, and Flapjax does the rest.
The Project Grows
Flapjax started as a summer undergraduate project and then accreted. The team added to the core system, created demos, wrote applications, and did new research atop it. Most of all, though, it was building systems using Flapjax — not “research” systems but ones in production (such as a trio of systems that handled conference paper review, graduate school applications, and faculty job applications) — that pushed the language’s implementation and gave us a rich understanding of what one could build with it.
In short, we wrote a lot. But the one thing we didn’t write was a Flapjax paper.
Shriram felt that time spent writing papers was time that could better be spent building a system. DrScheme (now DrRacket) had a similar roll-out, with a user base long before any papers, so Shriram had seen the value of the “late paper” approach, which he imposed here. (The graduate-school-bound undergrads on the project fervently disagreed, but were wrong on this point.) We wanted a system that we, and others, could use. It took three years to get there. (Particularly thrilling — and scary — moments came when we saw a job ad mention it, and when commercial press authors began to cover it.) Indeed, production systems in Flapjax ran as late as 2016.
… And Then, We Did Write a Paper
One might assume that writing a paper that wins a Test-of-Time award (it also won a Best Student Paper award at OOPSLA 2009) must have been painstaking. Actually, we started writing the paper just two weeks before the conference deadline, and it was one of the easiest papers any of us has written. This is because, between June 2006 and paper submission, Shriram had presented the work over 15 times in academic and industrial settings. As a result, we’d anticipated most questions and polished our examples. The paper was largely just a transcript. (This runs at odds with conferences as venues for rapid dissemination: sometimes, software accomplishes that end much quicker and better.)
There are three lessons embodied in this process and paper:
- Too often, papers are written before a system is even finished. However, a paper can be written much later. Those papers “write themselves”.
- The Flapjax paper was expressly written for a “developer” rather than “academic” audience. We could easily have “Greeked up” the paper, but consciously decided not to (and hence sent it to OOPSLA). Several developers have since told us how it served as their entrée into the world of reactive programming.
- Presenting ideas to others strengthens them. Because the paper was deferred, all these audiences made it better.
Of course, there’s a risk to deferring publication. For one, we were confident we wouldn’t get scooped. We also felt that by building something rich and useful, we would get much deeper into the problem than most academic projects, so readers would still be interested in our experience. We have found this principle to apply in several of our projects.
Making a Mark
Programming languages research is sometimes criticized for not having enough impact on practice. Impact is difficult once a community of practitioners has settled into its ways. However, when a technology is in its infancy, there is a great opportunity to identify its properties and abstractions.The community creating it is eager for more hands and for improvements. That makes it possible for even an academic team (even one of mostly full-time undergraduates!) to make a real contribution. Of course, this requires keeping track of ideas from outside programming languages (e.g., in networking, security, systems, etc.), not waiting for visioning reports to find out what to work on. It also entails some risk of chasing the wrong ideas. But when it pays off, the rewards are rich.
Author bios
Shriram Krishnamurthi is a professor of computer science at Brown University. He was startled to discover that flapjacks in Britain are a completely different food from flapjacks in America.
Michael Greenberg is an assistant professor of computer science at Pomona College. He makes sourdough pancakes regularly, but his favorites are jianbing and dosa.
Arjun Guha is an associate professor of computer science at UMass Amherst. Pancakes are his least favorite breakfast food, seriously.
Leo Meyerovich is the CEO of Graphistry, Inc. He is thankful for Japan’s discovery of the soufflé pancake.
We are indebted to Mike Hicks for his editorial work, which hugely improved this article.
Disclaimer: These posts are written by individual contributors to share their thoughts on the SIGPLAN blog for the benefit of the community. Any views or opinions represented in this blog are personal, belong solely to the blog author and do not represent those of ACM SIGPLAN or its parent organization, ACM.
