What do they do at the Lisp Conference?

At dim sum on Sunday Arthur was wearing a Lisp Conference T-shirt.  Kleanthes asked “What do they do at the Lisp Conference?”  I chimed in “it is a bunch of old guys talking about how a 20-year-old version of Lisp is so much better than all the language tools being hyped right now.”  My position was that this isn’t a credible stance.  Though it is probably true that you can be more productive in Common Lisp (1982) than in C# (2002), nobody will believe that the industrial software world has stagnated for 20+ years.  I said that nobody will take Lisp seriously until it at least adds the truly state-of-the-art language features such as type-inferencing (from ML) and preconditions, postconditions, and invariants (from Eiffel).  Bill came up with a novel objection to this idea:  “My style of programming is exploratory and anything that gets in the way of that slows me down.”

Could he be right?  Is old-style Common Lisp or Scheme actually the best that we can do?

——————– a quote from a problem set that I wrote a few years ago

“Another issue is a perennial side-show in the world-wide computer programming circus: the spectacle of nerds arguing over programming tools. The data model can’t represent the information that the users need, the application doesn’t do what what the users need it to do, and instead of writing code, the “engineers” are arguing about Java versus Lisp versus Perl versus Tcl. If you want to know why computer programmers get paid less than medical doctors, consider the situation of two trauma surgeons arriving at an accident scene. The patient is bleeding profusely. If surgeons were like programmers, they’d leave the patient to bleed out in order to have a really satisfying argument over the merits of two different kinds of tourniquet.

“If you’re programming one Web page at a time, you can switch to the Language du Jour in search of higher productivity. But you won’t achieve significant gains unless you switch from writing code for one page. You need to think about ways to write down a machine-readable description of the application and user experience, then let the computer generate the application automatically. “


  1. Christian Nybø

    August 12, 2003 @ 3:17 am


    What do you mean by the “industrial software world”? What are they looking for? Type inferencing as opposed to not declaring types brings nothing but speed, does it?

    The quote on doctors and programmers occurs in your web development book. See http://philip.greenspun.com/internet-application-workbook/metadata

  2. a

    August 12, 2003 @ 6:41 am


    But then doctors do argue about the right treatment all the time.

    Witness the row in the UK over whether receiving the MMR vaccine may be linked to the development of autism.

    Witness the arguments about alternative therapies. Medicine is full of arguments – I am sure that for most people they would be as incomprehensible and geeky as the arguments about Lisp etc

  3. Jagadeesh K Venugopal

    August 12, 2003 @ 10:07 am


    The problems with LISP that I see are as follows:

    * Rather than take lisp out to the world and evangelize it to John Q. Programmer, they are content with preaching to the converted in conferences, papers and symposia. Unfortunately lisp needs to be marketed to people who do _not_ know lisp.

    * LISP was a great programming language and environment for its day. How has it evolved? In today’s world the choice of programming language is often secondary to the quality of its development and runtime environment. Witness the immense popularity of Visual Basic, admittedly a very poor programming language.

    * When most IT programming consists of widgets and SQL code, does LISP (and the strengths that it brings) really matter? After all we are just talking about a way to put buttons, etc. on a form, send out a SQL statement and parse the results

  4. Daniel Barlow

    August 12, 2003 @ 10:09 am


    Actually, I had more fun than I was expecting at ILC last year; I was worried I’d be the youngest person there, but no.

    Still, it’s very good news to hear that type inferencing and DBC are what’s holding Lisp back from commercial success: the usually cited reasons are threads, sockets, XML and SOAP. For the record, the compiler in CMUCL/SBCL has type inferencing, and a quick google for “design by contract lisp” pulls up an example implementation using clos method-combinations to do exactly that (~250 lines of code). So, I look forward to world domination soon 😉

  5. Fazal Majid

    August 12, 2003 @ 2:30 pm


    The real reason medical doctors are paid more is that the AMA operates a cartel, restricting supply (numerus clausus for admissions to Med school) to inflate prices. Why else does a visit to a GP cost $110 in the US, when it costs only Euro 25 (about $27) in France? Having experienced both, I can tell you it is certainly not quality of service that explains the difference.

  6. Michael Bernstein

    August 12, 2003 @ 3:14 pm


    Philip, have you seen Paul Graham’s article ‘The Hundred-Year Language’?:


  7. David Cohen

    August 12, 2003 @ 4:40 pm


    Actually, Lisp is lurching forward into the 21st century as people develop new IDEs, SOAP implementations, web tools, etc.–a good place to keep up with new developments is John Wiseman’s weblog, Lemon Odor: http://www.lemonodor.com

    Be sure to read the archives too.

  8. Shimon Rura

    August 12, 2003 @ 7:11 pm


    Old-style Lisp or Scheme is not the best we can do. Languages with the kinds of semantic straightjacketing you mention, however, do indeed result in programs that are excessively resistant to exploratory development.

    But consider one way to adress this deficiency: instead of using formal specifications purely to constrain what the programmer can do, we could use them to enable richer, more meaningful changes. After all, we want restrictions on our programs that will make them do the right thing when they can, and make it clear when they cannot. The problem is too many unneccessary alarms. But your language (or development environment) could tell you where and why you broke a precondition or failed a type check, and offer you options for fixing this including changing types or broadening preconditions. Then you could not only explore and improve the program but rework the straightjacket so that you end up with the strongest rules supporting the most essential parts of your program, and flexibility where it is required.

    Automatic tools can already help you move a method between classes, but that’s elementary. What if you could find out exactly what changes would be needed to have some off-the-shelf component handle a new kind of input? Type systems and preconditions help a lot when doing the kinds of formal analysis that could help answer a question like “how is this input to this function used?”.

    Sure, some of the changes you make will only be small steps to recovering the flexibility of less structured languages. But the changes will be fast and no-risk, made automatically by your IDE. The payoff, hopefully, would be to take advantage of constraints by using them not just to eliminate options but to discover them.

  9. Ross Judson

    August 13, 2003 @ 12:53 am


    Love what’s under LISP, have a lot of trouble reading it. Total lack of signposts in the language; it doesn’t get tokenized by my brain very well.

    The most powerful thing about Lisp is eval, and s-expressions. In fact, that pretty much defines the language.

    The barrier I’m worried about is how well the runtimes behave in the large. Java runtimes run very comfortably with multi-gigabyte, heavily collected heaps these days, which is something our customers play with every day. I haven’t see or heard much about how the LISP runtimes play in those kinds of environments. I’m curious.

  10. Tayssir John Gabbour

    August 13, 2003 @ 4:31 am


    Language features seem like OS features — bring in the investment, they’ll be shoved in somehow.

    Someone (whose name escapes me — an AI guy who famously telecommutes for $35/hr) proposed to a large Common Lisp vendor that he’d happily contract with them to build .NET support. Xml, soap, yadda yadda. He says they haven’t taken him up on that offer. If they’re at all rational, and they did survive the AI winter, we can assume their customers haven’t exactly been clamoring for these features. I would extend this to type-inferencing and design by contract.

    But I wonder why anyone would assume Lisp is in a terrible position. People are slowly ingesting the usefulness of optional typing.. functional style.. gc.. is it maybe that the world needs to learn block by block?

  11. Kristian Sørensen

    August 14, 2003 @ 1:46 pm


    Having learned Lisp over the eight months and presently being in the process of creating a product using Common Lisp, I could not resist to commetn on this thread.

    Boradly speaking todays Common Lisp implementations offers all I can get from the SUN Standard Edition java except a cross OS/hardware/Common Lisp implementation GUI toolkit.

    Yes Common Lisp of today does have threads and tcp/ip sockets. Though they are not a part of the ANSI standard, libraries exists that gives them a uniform API no matter which Common Lisp implementation you are targeting. The threads comes on both flawors, ie. in-process simulated ones (called green threads in java), and threads the OS is aware of and can spread over multiple CPUs etc. Of course you can also fork in Common Lisp.

    What Common Lisp gives me that Java does not give strait away me is:

    macros (which again can give me a great amount of features unavailable in java, C++, c#, VB etc.)
    continuations (only available in CL after a little extra work – see “ANSI Common Lisp”)
    signals and restarts
    generic functions and the dispatch model of CLOS
    multiple return values, optional arguments
    type checks that can be switched on and off as needed in the various phases of program creation
    multiple vendors of mature compiler and runtime implementations

    Regarding the alleged lack of substitutes for J2EE, Xerces etc. I have experienced this as less of a disadvantage than I had anticipated. It turns out that by using macros and lambda functions combined with restarts and signals while taking advantage of closures it is possible to do what JSP/Servlets/EJB are trying to do, and do it with so few lines of code that J2EE seems extremely cumbersome in comparison. Basically what is happening is that you are able to get a few layers of abstraction above the level on which J2EE operates, and this is what gives the productivity gain. I am exploring this at the moment, and being both surprised and very pleased at what I discover!

    Regarding the programming environment it is a mixed bag. The Franz implementation has a wonderfully productivity enhancing IDE while implementations such as the CMU CL comes without an IDE, and you are supposed to use xemacs, which btw. is a surprisingly effective way of working with the ilisp package.

    What I am doubting at the moment is how well Common Lisp lends itself to projects with more than two-three programmers, or with programmers who are less than very good at understanding a program in great detail as well as on all the higher levels of abstraction at the same time.

    Java seems to be very good for situations where you need to enforce processes upon a great number of programmers in order to avoid having them shoot each other in the foot, and instead actually being able to produce something. This makes Java a likely “COBOL for the 21 century”.

  12. William Morton

    August 15, 2003 @ 3:51 pm



    In truth, many areas have too much healthcare (see http://www.dartmouthatlas.org/) – and “more” often does not translate to “better”. As I’m sure you’re aware, the same can be said for software engineering. Possibly why Lisp gets short-shrift?

    Two other quick comments:

    – The debate over the MMR vaccine and autism stemmed from a highly flawed study published in The Lancet (e.g. very small, non-random sample). The concern with Thimerosal (mercury-containing vaccine preservative) has more scientific merit.

    – I believe France has socialized medicine, which means the government foots most of the bill.

  13. Justin Johnson

    August 24, 2003 @ 3:14 am


    I’m learning Common Lisp now for a class, after taking Scheme several years ago, and programming professionally in Java for a few years.

    My highest level impression of Lisp is that it’s too clever. I can see how Lisp enables certain very elegant programming structures, how a 20 year veteran could whip something up that would wow an audience in less than 100 lines, how it’s an extremely artful language. And that may be its problem.

    At the same time as Lisp offers great aesthetic possibilities, it stands in my way of accomplishing small things simply. I’m left with the nagging suspician that I’m doing something wrong, even after I’ve wittled things down to a beautiful, recursive nubbin of a function. It’s all parentheses and nested closures, and it seems incredibly un-intuitive, such that I despair of making it to that expert level where the universe unfolds for me in Lisp.

    If I may analogize it to my art education, Lisp seems like brush drawing: a tool of great skill and delicacy allowing impossible things, but also one that seems out of reach to most actual artists. It seems to rarefied to be useful to most.

  14. anonymous

    August 26, 2003 @ 5:10 am


    I’m trying to learn java and lisp(scheme) at the same time. But why should I. Won’t I be replaced by a programmer in the third world?

  15. Tom Solomon

    September 2, 2003 @ 11:47 pm


    Didn’t you found Lisp?

  16. Alok

    August 19, 2006 @ 7:31 pm


    I am looking forward to attend the ILC 2007 in Cambridge http://www.alu.org/alu/alu-ilc-2007 I am a Lisp newbie who professionally codes in C++ most of the time. But I am very interested in exploring Lisp and its style of programming and indeed using Lisp for my personal purposes.

Log in