Navigating around Amsterdam was difficult. One could easily get whiplash looking for street signs while putting a finger on what is quietly striking about the city.
This time the BeNeLux lispers played host to the Cologne contingent. About a dozen people total, and we were warmly received.
Lectures: Code Walkers, Macro Advice, Compiler Macros
One surprising thing is how fast a lisp lecture can be while remaining understandable. They went at a brisk pace, yet didn't pass into incomprehensibility. The code's abstraction levels managed to stay at the same level as the concepts which were communicated. I did require rereading the slides afterwards (and checking the standard) to make sure I got all the points, but at no point did I feel bored or my energy level drop, which generally kills comprehension.
Dirk's Lecture: "Lisp Code Walkers, An Introduction"
Code walkers are like any interesting thing in life ÃÂ cool and currently a little dangerous. Operating on code with the same muscles trained for data-handling is a powerful concept. They have myriad uses: program development tools, complex macros, program analysis, and even some things which touch upon the fuzziness of the term "code." Dirk Gerrits cut through a lot of seeming complexity, categorizing the issues one might face. For example, operators are important since they largely determine the meaning of a list of code. Dirk examined the issues raised by each of the three types: functions, macros and special forms. Environments were also covered, since identical code in different environments have different meanings.
His slides, plus commentary + errata.
Dirk explained current weaknesses of code walking as a general technique. One reason is that every lisp is a code walker: hijacking it can save time. Another is the controversial decision to not include strong environment accessors with the last standard. (Lisp's main strength is opening up the system to human access in order to be programmed, so this is a noticeable omission.)
As a complementary introduction, Dick Waters's article from Lisp Pointers magazine is handy. Also, Dave Moon's arguments against naively representing code in s-expressions are interesting. (It's a long page, so you'll want to search for "moon".) Incidentally, Franz seems interested in setting a defacto environment-accessing standard similar to CLtL2's.
Ernst's Lecture: "Macros and General Code Walkers in Lisp ÃÂ how useful! or, how useful?"
Macros often represent a liberation from other languages. But when a programmer has gotten appropriately jaded, its current limitations become clear. As I interpret Ernst van Waning's lecture, he argued that code-is-data should be considered like any other paradigm ÃÂ while one can get a lot of mileage out of it, it should still work within a multiparadigm ensemble. To this end, he analyzed where practical users have found it most appropriate, as well as where it starts acquiring a certain "smell." (As some engineering communities say.)
Ernst's slides are here. He created a quick model of macros and gave us a tool to help analyze them. Then he outlined basic useful areas:
- controlling evaluation (such your own control structures)
- computing during expansion
- as accessors ("setf-expanders")
- setting up lexical bindings (with- and do- macros)
Increased thoughtfulness becomes vital as we step into code walkers and domain-specific extensions. As we saw in Dirk's lecture, there are practical problems to be solved in current lisp implementations. And it is a balancing act for them; increasingly dynamic features can complicate our static analyzers.
(Questioning one's tools like this is not meant to discourage, because domain-specific extensions and code walkers are powerful. These are questions one must ask of any paradigm as they step up in power, such as functional and OOP. Ernst claimed, "No one knows all of Common Lisp," so a little enlightened laziness in doing research, instead of jumping into code, can save time and maintenance.)
Intermission
There was no formal intermission, but I noticed something remarkable between the lectures. Arthur had pulled out a couple books on reasoning which were written in some mixture of English and lisp. It became clear to your author that the brilliant systems mentioned at previous meetings, like the metaobject protocol, were built in an atmosphere where people spoke lisp in order to describe reality and the imagination. They were inspired by insights built upon a lisp substrate.
For reference, the books were:
A Computational Logic by Boyer & Moore Computer-Aided Reasoning: An Approach by Kaufmann, Manolios & Moore.
(The first book I liked more, though I had little time to read either of them.)
Arthur's Lecture: "Compiler Macros"
Lisp is not simply about transforming notation. More generally, it is about symbiosis with one's system. "Compiler macros" are a mechanism for compilers to ask the programmer for advice on how to optimize a function call.
The technique is to optimize a function call by transforming it into a higher-performance form. An example is with (* 3600 12 365). We could simply type in 15768000. However, this is error prone and we are essentially hand-compiling code. Instead, we let the compiler macro do it, by having it multiply the numbers together before sending it off to the compiler.
Suppose we have a simple vector addition function.
-
(vector+ #(1 1 1) (foo a) #(1 1 1))
can easily be transformed into (vector+ #(2 2 2) (foo a)). If foo has some pattern, the compiler macro may possibly optimize even further. -
(vector+ #(1 1 1) (foo a))
If foo has no useful static patterns, the compiler macro could sensibly decline to handle the task.
Arthur Lemmens's slides and demo are full of case studies taken from opensource code and his own work. Mario Mommer was especially interested in his type system. Arthur deals with quantities like 5 km2/s, and wanted a system which checked arithmetic operations and converted between units. Compiler macros led to a 3X speedup. Mario pointed out that lispers were empowered in creating useful type systems; it was again an example where a paradigm (static type checking) worked harmoniously alongside supposedly opposing paradigms.
Conclusion
One interesting theme was that lisp is about letting programmers program the entire system. Not just the notation.
Another theme is that intriguing things can mercifully be expressed with few lines of code. Lispers code closely to the semantics, to meanings.
A final theme was that software paradigms seem to have a wall of diminishing returns. With a sweet spot where the paradigms are extremely powerful. One example was Arthur's type system which Mario liked so much. It gave Arthur peace of mind and a more expressive language; but forcing the entire codebase to use it offers a questionable return on investment.
(I'd like to refer people to Robert Floyd's 1978 Turing lecture, "The Paradigms of Programming." That paper should not be locked up behind ACM's vaults; it talked about how true programmers should be conversant with different ideas, without crossing over into religious bias. In particular, it even mentioned his initial confrontation that same year with lisp.)
"Although my previous enthusiasm has been for syntactically rich languages like the Algol family, I now see clearly and concretely the force of Minsky's 1970 Turing lecture, in which he argued that Lisp's uniformity of structure and power of self reference gave the programmer capabilities whose content was well worth the sacrifice of visual form."[Update: Markus Fix is now hosting a copy of Floyd's paper, which allows free redistribution!]
ÃÂ Robert Floyd, "The Paradigms of Programming"
Conversation
After the introductions, the lectures started immediately. Here are snippets from various conversations.Thank You from CL-LC
I thought those lectures were important for people to read about. Lisp allows me to do something that has always frustrated me in other languages ÃÂ write good code. (Now I see that is near impossible, since meta-linguistic code is very hard for people to deal with, outside of lisp.)
So thank you Dirk, Ernst and Arthur for the excellent lectures. As well as everyone who brought different perspectives to the meeting. And to Pascal, who was shall we say, a little let down at first by those who served as navigators. (Incidentally, we were referred to as celebrities in the Usenet invitation, but they had the good taste to treat us just like normal people. I don't even think any of us were asked for autographs.)
"Knee-Jerk Anti-LOOPism and other E-mail Phenomena"
This oddly named paper is not really about lisp; more about social interactions on mailing lists back when email was new. It incidentally mentions that a lisper invented the smiley face emoticon. He is credited for this in ESR's Jargon File.
Candy
For some reason I missed the chance to try out the chocolates Arthur laid out. You snooze, you lose. Trying popular candies in different countries is always interesting.
He also laid out healthy stuff like bread and fruits for those who hadn't grabbed lunch beforehand. There might be a lesson here.
Road to Lisp
You might be tempted to be lazy about reading directions before embarking to a foreign nation. Do it anyway.
The way to Amsterdam alternated between casually unwinding stretches of road, to the sharp sudden need RIGHT NOW to make snap 5-second decisions upon seeing a sign, before it becomes too late to turn. You can imagine how pleased we were with this user interface.
(Incidentally, Mario got so fed up he bought a map, which was absolutely the Right Thing. He cut through that useless honor in being cheap. I mean, we only made one wrong turn on the autobahn, yet it carried substantial cost.)
Subversive lisp
Some of us had a small laugh about certain lispers, who seem to be in positions of influence where they subvert the status quo. Pascal mentioned that Richard Gabriel left the computer world for four years to pursue poetry after Lucid failed; when he returned, he was shocked to discover lisp had somehow disappeared from the world. (Perhaps not only lisp but good systems in general.) In its stead was formality-bound programming. As a subversive reaction, Richard founded the Feyerabend Project, named after an intentionally provocative philosopher of science who warned against hiding behind methodology.
It now appears defunct. Some of the participants wrote books I own, like Jerry Weinberg and Ward Cunningham. (One theme in their books is about how human systems maintain themselves in the face of change.) Perhaps the project succeeded in its goals; there is a continuum of good outcomes, and they do not need to be dramatic.
Common Lisp weaknesses
Hermann Ehrenburg asked about criticisms of Common Lisp. One person mentioned the inability to alter things like garbage collection strategies. Another pointed out that the lectures would soon answer this in detail.
Unfortunately, such an interesting question on public internet forums is unlikely to get answers. Many zealots from other cultures cite these answers as horrible flaws which only lisp has. Just as enslaved people might be shocked at the unique problems of freedom.
When Hydarnes counseled the Spartans to be friends with the King, for the Persian King well knew how to treat his friends, "Hydarnes," they answered, "you are a one-sided counselor. You have experience of half the matter, but the other half is beyond your knowledge. A slave's life you understand, but never having tasted liberty, you cannot tell whether it is sweet or no. Had you known what freedom is, you would have bidden us to fight for it, not with the spear only, but with the battle-axe."
ÃÂ Herodotus, book VII. 135 (recounted by Pournelle)
Main author: Tayssir John Gabbour