December 20, 2007
The design of programming languages
Only two weeks ago Larry Wall wrote a quite comprehensive paper featuring a list of common major decision points in programming language design.
Today I came across Kent Pitman’s paper Condition Handling in the Lisp Language Family from the year 2001 where he voices his personal experiences in the design of a programming language standard. The most interesting part is this:
“In my experience, much of language design is like this. We think we know how it will all come out, but we don’t always. Usage patterns are often surprising, as one learns if one is around long enough to design a language or two and then watch how expectations play out in reality over a course of years. So it’s a gamble. But the only way not to gamble is not to move ahead.
I once saw an interview on television with a font designer from Bitstream Inc. about how he conceptualized the process of font design. It is not about designing the shape of the letters, he explained, much to my initial surprise. Then he went on to explain that it was really about the shape of words. The font shapes play into that, but they are not, in themselves, the end goal. Programming language design is like that, too. It’s not about the semantics of individual operators, but about how those operators fit together to form sentences in programs.
Unlike the situation with fonts, where whole books can be viewed instantly in a new font to see how the design works, we don’t know in advance what sentences will be made in a programming language. We have to wait and see what people choose to write. Common Lisp took a step forward, and while we can quibble endlessly over whether any given design decision was right, the one design decision I’m most certain was right was to offer the community a rich set of capabilities that would empower them not only to write programs, but also to have a stake in future designs. Never again will I fear sending out e-mail to a design group asking for advice about what the semantics of HANDLER-BIND should be and finding that no one has an opinion! To me, that kind of progress, the evolution of a whole community’s understanding, is the best kind of progress of all.”
Kent Pitman, lead contributor of the ANSI Common Lisp Standard is a very competent advisor on Lisp matters and still greatly involved in the community. Quite often I’m amazed how much insight and effort was put by him and a bunch of other people into making Lisp a language very capable for Rapid Prototyping, Small Team Development (yeah, I made up that latter buzzword) and all the things that make software development a fun experience instead of a frustrating one.
Among those that instantly come to my mind are
- the symbol data type
- the condition system
- the Common Lisp Object System (CLOS) and its Meta Object Protocol (MOP)
- the reading and printing facilities
- the type system
- the garbage collector
- the ability to use and mix the paradigms of imperative, functional, declarative and object-oriented programming
It is unfortunate that the standardization process has stopped in 1995. But it doesn’t really matter since it gave the Lisp community a solid base to build quasi-standards upon. This deters newbies, of course, but all mostly self-reliant programmers and those who are willing to ask smart questions on comp.lang.lisp happily make it. And this is the type of programmer who profits most from Common Lisp, anyway.
Comments(1)
Thanks for the Pitman’s paper link. I’m ashamed that I don’t use condition system more often, though I feel that writing with it is more of an art, not a black art, but art nevertheless.
Slobodan