This would be easier if it was more difficult

That’s the counter-intuitive idea behind Rudolph Winestock’s The Lisp Curse (hat tip to Ilkka Kokkarinen). For non-CS types, this is about the great-in-theory-but-impractical programming language, not the speech impediment. The idea that easily being able to branch off for your own purposes and create something new is bad contrasts greatly with the perspective of the dynamic geography/competitive government folks. For unabashed Lisp fanboyism (complete with cartoons) see here (hat tip to mtraven, can’t find his post though).

For my own part, I have hardly any experience with functional languages like that. I find them unfamiliar for someone raised on the C-family, and therefore unpleasant.

I’m just paraphrasing someone else, not saying it myself. This argument and “worse is better” are both made by Lisp proponents who are trying to explain why Lisp as successful as its greatness merits. I would expect other folks would see things quite differently.

AMcguinn, you say that your argument is almost the opposite of “worse is better”. Although I suppose an opposite can be similar. I didn’t quite understand it though. Why does badness actually help with standardization? I get the argument for why ease of creation prevents any particular solution from becoming standard, but not for why the same marginalization didn’t apply to XML.

mtraven, I don’t know much about Lisp. This is my only experience with it, and it reminded me of OCaml, the only functional language I had been required to use before.

If you use a more sane format, it’s easier to write a parser for it than to integrate one.

XML is very hard to write a parser for. You have to handle entities, namespaces, etc. Therefore you are forced to the effort of integrating an existing xml parser. Therefore there is a standard implementation, and so there is no divergence from the standard.

Equivalent to C++ in Winestock’s example: if you want to use objects in a lisp program, you write a few object extensions. If you want to use objects in a C program, you need to use someone else’s work (Obj-C, C++ or, to go half-way, GLib).

mtraven, though it is online I doubt I’ll get through it before statistics. And I haven’t made any progress on the latter. So many easy distractions.

AMcguinn, I think I get it better. I’d never heard of Lisp S-expressions, but is the premise here that they are not equivalent to XML? So that there are different versions which would not be compatible with the same parsers?

I was the key implementor of the Rutgers variant of UCI Lisp in the 80’s. My take on the subject is diametrically opposite from Winestock. Here from my book “Beyond AI”:

Common Lisp

Object-oriented programming is an exceptionally bad idea which could only have originated in California.

–Edsger Dijkstra

By 1980, the lisp programming language, which had been one of the keystones of Golden Age AI, had begun to look like the syllabus of a comparative religions course. In addition to the original lisp 1.5, there were maclisp, interlisp, rutgers/uci lisp, Utah’s Portable Standard Lisp (psl), franz lisp, scheme, nil, and native versions of lisp for each of the several brands of hardware lisp machine that were being developed.

Programming at the highest levels, like any world-class creative art, is an extremely personal activity. Since lisp made modification of the language easy because of its self-referential properties, a diaspora of dialects was almost inevitable. However, since the AI community was trying to break out into the commercial world, this messy situation looked like dirty laundry, so the leaders of the lisp world looked for standardization.

This came in the form of common lisp. The result of a series of industry and academia-wide meetings, it was a political compromise of a design that had something in common with all such compromises: it was ugly. It was the antithesis of the elegant, intellectually powerful lambda calculus on which lisp was first based. It had a bloated pile of mismatched features, included not because they worked well together–they didn’t–but because, for each feature, there was some member of the consortium who insisted on including it.

Common lisp went on to become ANSI standard X3.226-1994.

Nobody appeared to notice that common lisp killed the “marketplace of ideas” that had given vitality to the jungle of different lisps. It took a decade for consolidation, shakeout, and the rise and failure of the lisp machine companies. At the same time, lisp was still so far ahead of the general run of programming language development that there was never any temptation to move to anything else, and thus little occasion to notice that it was standing still.

Even so, over the past two decades lisp ceased to be a significant source of programming language ideas. It remains among the best, but the others are moving and it is not. Lisp has become the Latin of programming languages.

At a higher level, the Common Lisp phenomenon was part of a general shift in the sensibilities of AI that moved away from an interest in programming in general. This may be part of what caused the AI subfield of automatic programming, alive and well up through 1980, to disappear not too long afterward.

The notion that a small group of people can sit down and write a formal specification that can substitute for the ongoing efforts of a dynamic community is an example of what I call formalist float.

…

The language that has inherited the mantle of LISP hackery (and the one I generally use now) is Python.