Living it up with a Live Programming Language

I've just finished a paper submission on live programming languages and how live programming is realized in SuperGlue. Any feedback is appreciated. Here is the link:

http://lamp.epfl.ch/~mcdirmid/mcdirmid07live.pdf

Because the paper has inlined movies, it is best read in a later version of AcroRead with QuickTime installed.

Abstract:

A dynamic language improves programmer productivity through flexible typing, a focus on high-level programming, and by streamlining the edit-compile-debug cycle. Live languages go beyond dynamic languages with more programmer-centric features. A live language supports live programming that provides programmers with responsive and continuous feedback about how their edits affect program execution. A live language is also based on declarative programming constructs such as rules or data-flow connections so that programmers can write less code. A live language should also provide programmers with responsive semantic feedback to enable time-saving services such as code completion. This paper describes the design a textual live language known as SuperGlue. SuperGlue is based on reactive values known as signals that are supported with declarative data-flow connections and dynamic inheritance. Through signals and dynamic inheritance, SuperGlue supports live programming, declarative programming, and responsive semantic feedback. We demonstrate live programming in SuperGlue with a working prototype.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Live programming

A really interesting paper, many lucid points, thanks!

Are you aware of TOPLAP? An organisation of people interested in using live and dynamic programming languages to improvise live music and video. I sent a link to your paper to the mailing list, I think it is a really useful contribution there...

Thanks for the

Thanks for the feedback!

Yes, I was aware of some of the work listed on TOPLAP. I couldn't find a nice way to integrate a discussion of live coding languages (e.g., Chuck) into the paper, so I just left it out for now. I'm not sure how suitable SuperGlue is to performance, it seems like live coding languages have fairly strict timing requirements on how edits are incorporated into the executing performance. I still have to get my mind wrapped around that paradigm :)

distracts from the real subject of your paper

A dynamic language improves programmer productivity through flexible typing, a focus on high-level programming, and by streamlining the edit-compile-debug cycle.

The sun is shining, breakfast was good, I don't think I'm crotchety this morning, but ... the flat assertion of that first sentence doesn't add anything to the discussion of the work you've done, and will completely distract some readers before they ever read about your work.

Imagine -
A static language improves programmer productivity through flexible typing, a focus on high-level programming, and by streamlining the edit-compile-debug cycle.

Removing the part about

Removing the part about typing'd make it fair enough - I tend to see the emphasis as being on dynamic in the sense of reflective (not just introspective!) and mutable.

Ditto...

...but long-time LtUers will be shocked to read that I had no problem with the first sentence. I guess it became plenty clear enough, rapidly enough, that "dynamic" here really does seem to have more to do with reflection and available metadata, if you will, about the program than about typing. Get all the way through the paper, and you come to realize that all of this is being implemented on top of Scala, no one's idea of a dynamically-typed language.

But perhaps that only serves to support the view that associating SuperGlue with "dynamic typing" by application of unclear terminology should be resolved.

By the way, that aside, the paper strikes me as quite good, and SuperGlue itself sounds intriguing. Is it available for experimentation yet?

The point was that there is

The point was that there is a path beyond dynamic languages; I had to put live programming into context somehow. The paper targets the OO community, hence the dynamic languages lead in. Given a different audience, this wouldn't work.

No release available yet. I still need to make language improvements and revamp things that I'm not happy about in the current prototype (mostly performance issues). Also, I've really got to get the new Scala plug-in out, so I probably won't have a decent SuperGlue release until the end of summer.

a path beyond dynamic languages

In what way does a mushy statement that a "dynamic language improves on programmer productivity" compared to some un-named kind of language help show "that there is a path beyond dynamic languages"?

If anything it gives the impression that you're going to be saying that dynamic languages are the path beyond some un-named kind of language.

Mostly it just made me want to say - show me that is true (and I would have had the same feeling if it started "A static language improves ...")

I guess I wasn't being

I guess I wasn't being precise enough. Dynamic languages [are designed] to improve productivity. They focus on programmer productivity by trading off other things that a static language might consider more important (performance, robust static guarantees, etc...). Most static language designers (and maybe anyone with formal training in PLT) cringe when they see what Ruby does in the name of improving programmer productivity. I'm not arguing if this emphasis is good or bad, it is just an observable characteristic. I'm definitely not trying to start a dynamic vs. static language flame war :)

Static typing has a lot of advantages that also improve programmer productivity, for one it enables very responsive semantic feedback in an IDE. I talk about this in my paper.

a live walk

One of the notions I find interesting is a well-defined excursion from a static-typing language into an alternate "live" syntax with fewer rules, followed by a migration back into the static world. You'd have the heavy-hitting static stuff that we all know and love, plus be able to relax the rules for a while.

Of course, SuperGlue is as much about the runtime support as it is about the language itself.

in the name of improving programmer productivity

"I'm definitely not trying to start a dynamic vs. static language flame war"
Didn't think you were - the way you happened to phrase that first sentence makes it a barrier that will divert people off into their familiar flame war, before they ever start reading what your paper is really about.

Water follows the easiest path; readers follow their easiest path through a text, the path that's been reinforced in their minds.

Now that's mush :-)

I'll try to use that opening

I'll try to use that opening in my next paper :)

I've been thinking about it, and maybe I should have used "rapid program development" instead of "programmer productivity". Many dynamic languages are designed to enable programmers to write code quickly, without focusing so much on long-term maintainability or scaling.

maybe I should have used

maybe I should have used "rapid program development" instead of "programmer productivity"

I agree. This is an important distinction.

A live language supports

A live language supports live programming that provides programmers with responsive and continuous feedback about how their edits affect program execution.
...
A live language should also provide programmers with responsive semantic feedback to enable time-saving services such as code completion.

That sounds like a nice definition, and fits with an intuitive notion of what a "live language" might mean.

A live language is also based on declarative programming constructs such as rules or data-flow connections so that programmers can write less code.

Why did you choose to restrict the definition of "live languages" in this manner? Would it not be possible to have a live language which was not based on declarative constructs? Do you think prototype based languages could be considered live languages?

I see some connections to this work and aspect oriented programming languages, which I think would be interesting to explore.

Very well written and thought provoking paper. I am glad to see papers of this nature.

In the original paper, he

In the original paper, he excludes Self from his definition of "live languages". This makes sense --- in Self, you have to explicitly re-execute the code after you change it if you want to see its effect.

In languages with side effects, it's potentially very painful to have your program editor re-executing arbitrary parts of your program as you edit it. For example, the ClarisWorks spreadsheet could pop up dialog boxes from formula evaluation, and although this could be useful, it was quite annoying when you were editing the logic that fed into that formula. (This feature seems to be missing in Excel X for Mac.)

So that's my hypothesis about why declarativeness is (so far) pretty much a prerequisite for liveness.

I wonder if you could handle this in a less extreme way than outlawing side effects entirely, though --- maybe by restricting their range of effect?

There has been some previous discussion about "programming in the debugger" on LtU, which I think is about as close as you can get in an imperative language.

I really appreciate the reference to Chris Hancock's Ph.D. thesis, "Real-Time Programming and the Big Ideas of Computational Literacy", which I'm finding very interesting so far. A couple of other related bits of work are the Vital/Pivotal work in Haskell, Wouter van Oortmerssen's "abstraction-free programming" work that he discussed here on LtU a couple of years back (which he seems to have finished, called Horse and Knoflook, and abandoned without publishing anything substantial), and Conal Elliott's Eros work, "Functional Programming by Interacting with Tangible Values".

And of course Subtext is cited, and very relevant, but I already knew about it.

My own Bicicleta work will eventually be relevant, but there's not enough implemented yet to brag about. My approach is most like Wouter's, and like early versions of Subtext.

If the language isn't simple

If the language isn't simple (i.e., declarative), then repairing the program's execution in response to an edit would be very difficult. I'm even excluding pure functional languages here, where unbounded recursion shares many characteristics with imperative assignment.

Self supports live programming via its Morphic meta-menu. However, in this case the programmer is directly manipulating an object, and not the code that created this object. One trick to allow live programming of code in Self is through periodic polling (see Maloney's morphic paper), but polling has well-known responsiveness problems.

I think one could support live programming in a simple procedural, even imperative, language. The trick could be to map the code to a run-time data-flow graph of the code's execution, which can then be responsively repaired by the run-time. I want to explore doing this (maybe in a simple version of Scala), but I'm not sure if it would be worth it as declarative languages also have usability advantages. However, a live procedural language might be useful as a teaching language.

If the language isn't simple

If the language isn't simple (i.e. declarative) ...

Surely you mean "(e.g. declarative)"?

I think one could support live programming in a simple procedural, even imperative, language.

That's what I think as well. Either way there is no clear reason to restrict the definition of live programming by saying it is "based on declarative constructs". It would be more accurate to say something along the lines of "declarative constructs facilitate live programming".

I'd stick with the i.e.

IMHO, the i.e. is actually appropriate in the strong sense that introducing mutable state represents a change to the semantics with non-local effects, a point articulated particularly well in CTM. CTM is equally clear that mutable state strictly adds expressive power to the language—we see this also in Oleg Kiselyov's work on delimited continuations, where delimited continuations and mutable cells are macro expressible in terms of each other—so there is, as usual, an expressive power/complexity trade-off. But CTM gets 400+ pages in, and expresses several programs, before introducing mutable state! So I think the argument that "simple" == "declarative" isn't an unreasonable one.

The point is that the

The point is that the language has to form a simple data-flow graph at run-time. Some, but not all, declarative languages have this property. Interestingly enough, a general Prolog program wouldn't form a simple data-flow graph because of recursion and backtracking.

You are probably right, but declarative is sort of simple, so I think the i.e. fudge is acceptable, if not completely accurate. I would like to redefine, if I could, declarative language to just mean a language with a simple non-recursive, non-imperative, run-time semantics. However, this definition would exclude Prolog and Haskell, which are what we think of as the traditional declarative languages.

What works?

I'm curious to learn (in a didactic way, not a sarcastic one) what languages would be (or be close to being) examples of ones which fit under your redefinition?

I mean languages whose

I mean languages whose programs have simple execution models that don't involve a lot of dependencies. Complicated dependencies are more easily created through mutation, control flow, and recursion. But its not so much the language that is important as it is the programs expressed in the language.

Hypothetically, we could take a simple Scala program, even one that uses recursion and imperative assignment, and program it live. However, the program would probably not be able to do very much. A real Scala program would bring a live programming environment to its knees.

So the programs must be able to do interesting things without complicated dependencies. This is why reactive programming languages, which deal with state transparently, make good live programming languages. For example, if we added reactive signals to Scala so that expressing UI programs didn't require the use of event handling, we could support live programming for UI programs expressed in Scala. I think most of these extensions are necessarily domain specific, so maybe DSLs are the best example of languages that could be made live.

Per-frame paper?

It's wonderful work.

By the way, the paper says there's a version available that has per-frame-exploded animations so we don't have to use proprietary software to read it. Where is that version?

Here it is, but I am really

Here it is, but I am really hoping people can read the live version:

http://lamp.epfl.ch/~mcdirmid/mcdirmid07dead.pdf

I wish there was a better movie format than Quicktime. I tried MPEG4 and AVI, but they are too big and didn't look very good.

Why not create an HTML version?

I'm not too keen on installing Acrobat Reader just to view the movies. (They don't work in Preview.app on OS X.) If you want people to view it on their computers, a format designed for computer viewing would be ideal. Despite Adobe's marketing material, PDFs aren't designed for that.

I agree PDF isn't ideal, but

I agree PDF isn't ideal, but I disagree that HTML is preferable. I personally never print out papers, and I prefer PDF to HTML for online reading. Why do HTML documents always look horrible? PDF documents are better formatted (unless generated from Word) and are rendered with anti-aliasing enabled. I can't bear reading large papers in HTML.

But maybe this is more a matter of personal taste. I should probably go ahead and figure out how to generate an HTML version, as Latex should support that. Thanks for the input!

[ot] web / usability / rotations / graves

As noted before on LtU usability has a fair bit of subjectivity to it. The original idea of the web allowing the browser to decide the layout sure sounded good! Whatever happened to that? Gosh, humans and technology are kinda lame.

columns

Wide text columns are one thing I hate about HTML; usually the PDF version of a paper will be either two-column or fairly narrow. Luckily, we Mac folks have Tofu, which reflows most HTML into multiple columns.

It would be nice if browsers

It would be nice if browsers had a setting for that, wouldn't it? I played around doing it with CSS on my site, as I don't have sidebars.

better movie formats

There are several better movie formats than Quicktime --- Ogg Theora, XviD/DIVX, and Flash FLV, for different meanings of "better". XviD is probably the best bet for good compression.

The limiting factor is

The limiting factor is finding a utility that can capture screen sessions. I'm using Snapz ProX, which only produces quicktime. I haven't had any luck converting QuickTime files to other formats.

Otherwise compression isn't really an issue (well, except for MPEG4, which is bad); its just will the user likely have the viewer necessary to the view the movie? QuickTime is yes for Mac maybe for Windows, WMF is yes for Windows and maybe for Mac, DIVX is probably for Linux and probably not for any other platform. I wish they would standardize on something.

Tell the user to download

Tell the user to download VLC player and get it over with. It can play almost every audio/video format on windows/osx/unix.

Holo-programming.

Not directly related to this topic, but in Star Trek, holo-novels are programmed live.

I think live programming is more natural than the edit-compile-debug cycle. Too bad none of the mainstream programming languages support it in a fully interactive way.

Examples?

What non-mainstream languages, if any, do you think come closest to it?

I am not the proper person to answer that!

I have only played with interpreted interactive languages out of curiosity. Other people with more experience can answer that question. I wish C++/C#/Java could be more dynamically programmed than what they are...too much time is spent in these languages trying to get to a state where bugs appear, which is extremely frustrating, especially in applications with lots of states.

It got in!

It got in!

Congratulations!

That's great news! I look forward to the publication.