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.
April 16, 2011 at 8:35 pm
Actually if you dig up some of Moldbug’s old posts on functional programming he has some points that are pretty similar to what you’re saying.
April 16, 2011 at 10:21 pm
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.
April 17, 2011 at 1:12 am
You may (or may not) be interested in a different approach to functional programming, i.e. concatenative programming as used in Joy and in Factor. There is also a Yahoo newsgroup for concatenative programming. You can also get to Joy through the links at my page of occasional work on another one, Furphy.
April 17, 2011 at 8:59 am
There has to be some way round the problem that standards have to be arbitrarily over-complex just to stop people producing minor variants. I don’t know what it is though.
I identified the same problem as Winestock in 2005 (though using XML rather than C++ as the contrast to Lisp’s simplicity).
“It’s easier to design and implement a suitable format than to find, download and learn the interface to someone else’s”
April 17, 2011 at 12:10 pm
Lisp isn’t really a functional language, that is, most Lisp programs are not written in a functional style, they employ state all over the place. New Lisp dialect Clojure is somewhat more functional.
I had some commentary on Winestock’s article here.
April 17, 2011 at 7:52 pm
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.
April 17, 2011 at 10:21 pm
You’re a smart lad, you should go through Structure and Interpretation of Computer Programs (uses Scheme, though not really about Scheme). It has the true Lisp nature in it.
April 17, 2011 at 11:16 pm
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).
April 19, 2011 at 7:36 pm
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?
May 17, 2011 at 12:57 pm
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.