Lambda the Ultimate

I read today a rant on pedadogical philosophy by Doron Zeilberger via Philip Wadler's web log.

The first one, due to my colleague and hero Israel Gelfand, I will call the Gelfand Principle, which asserts that whenever you state a new concept, definition, or theorem, (and better still, right before you do) give the SIMPLEST possible non-trivial example. For example, suppose you want to teach the commutative rule for addition, then 0+4=4+0 is a bad example, since it also illustrates another rule (that 0 is neutral). Also 1+1=1+1 is a bad example, since it illustrates the rule a=a. But 2+1=1+2 is an excellent example, since you can actually prove it: 2+1=(1+1)+1=1+1+1=1+(1+1)=1+2. It is a much better example than 987+1989=1989+987.

While writing a reply on LTU, I thought about modifying this principle to programming language design: If an example has a solution that is nearly as good without a given language feature, then that example is not a good motivation for that feature. Perhaps not following this principle is partly what earned FP it's ivory tower reputation.

Researchers love to generalize the heck out of any given feature, to add linguistic support for minor issues, etc. etc. It seems that as a result, PL researchers, particularly FP researchers, have a (deserved and undeserved) reputation for solving problems that aren't really there.

I'm not suggesting that every exploration must be practically motivated. Indeed, it's fun and educational to explore what can be done for its own sake. Was laziness ever practically motivated? I'm not aware that it was, but it certainly lead to some very important breakthroughs, most significantly how to satisfactorily deal with impure effects in a pure language.

However, when it comes to promoting a given language for wider use, features should be chosen to solve practical programming problem, preferably the problems that a niche finds unsatisfactory. (Or should find unsatisfactory... customers usually don't know what they need.)

What practical problems in what niches are LTU readers aware of?

Two interesting articles by Jaron Lanier on how protocols influence programming

SUN Interviev

If you look at the way we write software, the metaphor of the telegraph wire sending pulses like Morse code has profoundly influenced everything we do. For instance, a variable passed to a function is a simulation of a wire. If you send a message to an object, that's a simulation of a wire.

WHY GORDIAN SOFTWARE HAS CONVINCED ME TO BELIEVE IN THE REALITY OF CATS AND APPLES

If you model information theory on signals going down a wire, you simplify your task in that you only have one point being measured or modified at a time at each end. It's easier to talk about a single point in some ways, and in particular it's easier to come up with mathematical techniques to perform analytic tricks. At the same time, though, you pay by adding complexity at another level, since the only way to give meaning to a single point value in space is time. You end up with information structures spread out over time, which leads to a particular set of ideas about coding schemes in which the sender and receiver have agreed on a temporal syntactical layer in advance.

Odersky and Zenger - Scalable Component Abstractions

We identify three programming language abstractions for the construction of reusable components: abstract type members, explicit selftypes, and modular mixin composition. Together, these abstractions enable us to transform an arbitrary assembly of static program parts with hard references between them into a system of reusable components. The transformation maintains the structure of the original system. We demonstrate this approach in two case studies, a subject/observer framework and a compiler front-end.

This is pretty cool stuff. It reminds me in some ways of the PLT Scheme units + mixins system described in Modular OO Programming With Units and Mixins, but it feels to me like this supports a much more natural programming style. (Obviously that's a subjective judgement, but what bothered me about the PLT system, at least as described in that paper, is the need to define units and stitch them together in order to define even simple mixin composition. It seems like a much too common operation to require that degree of plumbing, but maybe I didn't quite understand it.)

Anyway, I like it. (And, for Leon Smith, this is an eminently practical technique, motivated with very clear examples. I think most Java programmers would immediately "get" this.)