Lambda the Ultimate

This list of classic books is the result of a poll ACM conducted where members named their favorite computer science books.

Good list. Bar the last two, which I have nothing against, the list consists of favorites of mine. It is always nice to see how many classics of CS come from work on programming languages. Not a surprise for anyone here, of course, but not always acknowledged. While we are on the subject of classic books, check out Luke's twitter poll here.

One of the tricks to creating a good user interface is to provide a continuous feedback loop between the user and the system. This can be done in many ways...live scrolling, live "scrubbing" of parameters via a slider, combo list, or whatever. Bringing this to PL is possible to an extent, but is limited by code that is basically non-continuous (to be described later!).

In math, we have the notion of a continuous function: a function whose outputs change a little bit when its inputs change a little bit. It is a prerequisite that the inputs also be able to "change a little bit"; i.e. are themselves continuous. This is a bit harsh, actually, and it is interesting to also consider discrete values that have some kind of order in a space (e.g. 1 ... 2) where going to an adjacent value is considered as the "small change." In any case, a continuous function can be augmented with excellent continuous feedback if the user is viewing its output while scrubbing its input (e.g. see Conal Elliott's Eros).

So we could treat code as a value "x" that is interpreted by a function "f", so "f(x)" gives us the output of the program defined by "x". If "x" was somehow a continuous value (or discrete value in an ordered continuum), and "f" was a continuous function, then we'd have the ultimate live programming environments: programmers simply move "x" around it its space according to how "f(x)" approaches or diverges from the desired output.

Of course, this isn't possible in general: code is hardly continuous in its value or interpretation. For small fragments of code, we can totally do this: e.g. scrubbing the position or color of a shape in a program. We can even scrub functions to a certain extent (e.g. shapes or colors in APX), but it is all quite limited to simply graphical/physical logic. Accordingly, most the successful demos of live programming are simple UI examples. I wonder also if this is the real bottleneck that visual programming runs into: that it is unable to provide reasonable feedback for many kinds of programming tasks, not because of (or at least, not just because of) real estate issues, but because the abstractions used are not amenable to continuous feedback.

The way forward is clear but perhaps difficult: we need to design programming languages and abstractions that are more continuous. Not just for graphical/physical computations, but for everything. One vague idea here is to distinguish between abstraction selection, a discrete non-continuous process, and abstraction configuration, which should be made as continuous as possible. Any other thoughts?