Lambda the Ultimate

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 :)

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.

...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 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.

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 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.

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.

"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 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 "rapid program development" instead of "programmer productivity"

I agree. This is an important distinction.

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.

You say: "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)"

Well, here it finally is: http://lambda-the-ultimate.org/node/5439 (or http://strlen.com/restructor/)

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 (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".

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 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.

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 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.

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.

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 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!

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.

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 had a setting for that, wouldn't it? I played around doing it with CSS on my site, as I don't have sidebars.

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 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 VLC player and get it over with. It can play almost every audio/video format on windows/osx/unix.

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

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.

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