[ in a state of controlled semantic decay ]

Things fall apart; the centre cannot hold. If you meet Mr. Man on the Tao of Recursion, a student once came to Buddha and told him a story: “A buddha once came to the moon, killing my whole life with his words, softly (two times, two times).” In fact, if he started to tell us about his wife we should get impatient; all we expect of him is that he should know the way and be able clearly to explain it.

It remains to show that Fame and Glory are total. To obtain your own copy of a platonic universe, make the mouse appear. Animate the universe with the five platonic mice and their three combinations. They are being ended by the Masters redirecting energies; well, not exactly, I sit in my shorts, aging, drinking beer, the windows open, and they look at me, 6 p.m., coming in from their little jobs… There's no end to termination.

*

Below: materials for ideological instruction, followed by miscellaneous, half-done, ramblings on the merry old muddle vs. systematically sound discomfort, object orientation, and related issues. Plus an extra serving of quotes emanating from the computational tædium (the unfortunate superabundance in computing practice of many 0s drowning the rare 1s).

Programming languages have to strike a balance between power vs. intelligibility, ease of expression vs. ease of understanding. Do they let you say much in few words, or understand much in short time? Trade-offs can go wrong in many ways, but both bad and ugly fall under the law: Caked mud is no building material apt for transparent constructions.

[ illustrating by the way the characteristically sloppy approach of academic folk to maintaining information, in this case about former contests, on the web. The remedial and, of course, unofficial ICFP Contest Archive does not seem to be quite complete, so far. ]

On Lisp vs. Scheme

We can forgive a man for making a useful thing as long as he does not admire it. The only excuse for making a useless thing is that one admires it intensely. Oscar Wilde: The Picture of Dorian Gray

[ Fragmentary sketch of similarities and characteristic differences of Common Lisp and Scheme. I am going to argue –someday– that software should sport two conflicting qualities: dynamism and intelligibility, since it must cope with change and exceptions, but should nonetheless be easily analysable at write-time. Common Lisp offers strong dynamic features but not much leverage for static analysis. Scheme, the language and the culture that goes with it, promises a mathematically more disciplined dynamism —but fails to deliver, to some extent. Has the vanilla pudding of confusion gotten the better of us? Read further and you won't find out. ]

Scheme emerged and has departed quite notably from the Lisp world. Both Scheme and Lisp feature an approach to data based on structured external representations (by bracketed expressions), a built-in parser, and a well-supported concrete data-type for the parse-tree. (Avoiding the syntactic pain of XML or SGML and the rectal pain of object-request brokers.) Since the data may well be code, Scheme and Lisp make it quite trivial to build interpreters for specialised domain languages or to embed these languages into Lisp/Scheme.

Actually, (Common) Lisp even makes forms (definitions and expressions) object level values and assigns the dependent role to their textual representation. On the whole, CL is geared toward the runtime system, one and all, placing the problem at hand and meta-concerns such as parsing, evaluating, and inquiring code on the same footing. Scheme, by its spirit —to be grasped in the lambda experience or mystical onion — more than by its rudimentary definition, tends to separate these concerns, supporting arguably more intelligible layered architectures while retaining much of the power of Lisp.

Let's finally rave on the merits of sound engineering principles. First case study: doc strings. In Common Lisp, the programmer may stick a string documenting a function into its definition. The system prints that string when asked for the description of the (named) function. This comes handy for “library” functions (as opposed to internal machinery). At the same time, this requires the language not only to assign meaning to programs but to specify (other) properties of the runtime system, too. (In other words, this complicates the meaning of programs.) Whereas Scheme leaves the job of organising documentation to the development environment where it belongs. As a result, Scheme programmers usually fall back on the classical means, source comments and text search. Second case study: candied pumpkin. Makes about three cups.

The object movement innovated imperative programming with a multi-agent view of problem domains as well as programs, composed of stateful thingies that interact, offering a limiting but easily communicable basic metaphor. This isn't worthless, but nothing to get too excited about either. Objects localise meaning: agents respond to messages by their own lights, but even thoroughly object-oriented systems impose global constraints or conventions (such as: classes cannot/must not override the identity method), effectively shifting semantic authority from the objects to the language. OO proponents paid much attention to the structure of large scale development efforts, but generated a plethora of absurd provisions, tools, subordinate buzz. Object technology was a marketing success, but there's no silver bullet.