5 ms·

Daniel Weinreb: Fundamental problems with the Common Lisp language

26 points by parenthesis 18y ago

sbt 18y ago
This is an even better post than the previous. I think Weinreb hits the spot and demonstrates that he is pretty well oriented about what's going on at the grass roots. Now, all the community need to figure out is what to do about these problems. Because the diagnosis is sound, in my opinion.
stcredzero 18y ago
Daniel is right, and splitlist is wrong. Irregularity is clearly harmful. It is much more difficult to produce new parsers and VMs for Ruby than it is for Lisp, Smalltalk, and even Python. This has clearly had an impact on the Ruby community. It should be possible to produce a "mainstream" language with the attractive qualities of PHP, Perl, Ruby, and Python, but with a more elegant design. (Ruby itself was implemented as a way of getting the power of Perl, but with cleaner OO.) I suspect that Stallman had it right when he came up with his grand unification plan through GUILE. Modulo the cultural expectations of the programming mainstream Lisp makes a better compiler target than a language. Now, before the Lispers get all up in arms -- this would make a Lisp the "one language to rule them all."
jcausey 18y ago
(You know, something's always (bugged me) with Common Lisp (and other Lisps (for that matter)) but I can't seem (to remember what it was)) Allright, Lispers -- take the joke...
- jrockway 18y ago
  1950 called. They want their hilarious joke back.
- gamache 18y ago
  If you're gonna crack a Lisp joke that sucks, at least attempt prefix notation and pretty-printing.
- mindslight 18y ago
  You(know, something's, always, bugged(me), with, python, and(other, programming, languages, for(that, matter)), but, I, can't, seem, to(remember, what, it, was))
tc 18y ago
Dan Weinreb is a smart guy, but too many of these points seem like straw men, at least if the point of identifying problems with CL is to investigate the apparent lack of mainstream adoption. Let's see: Too many concepts; irregular Yes, but unless you're implementing the language you can really almost ignore the concepts you don't like. If you prefer property lists, then forget about alists if you want. But really, a lisp in which you couldn't make an alist would seem awkward and irregular to me. Hard to compile efficiently I benchmark. SBCL is fast. It's much faster than it needs to be for mainstream adoption. It knocks the socks off of perl, python, and ruby, for example. For years it destroyed the JVM in performance, though I presume that the JVM has caught up somewhat by now. And really, any language is hard to compile efficiently. GCC has received tens of thousands of hours of optimization. A naive C implementation would likely be slower than SBCL for real-world code. At this point in history, we've even figured out how to implement ECMA JavaScript efficiently. Too much memory OK, I can agree with this. All of us would like an implementation with a tree-shaker, for example. But for production applications this isn't too much of a problem. In 2009 you shouldn't still be using CGI calls. Not portable Java is 'portable' because there is one widely used implementation of the language. Trying to port code from the JVM to GCJ is not straightforward. Porting CL code that runs on Linux to BSD requires no work. Porting from Linux to Windows requires no more work than would be expected in Perl, and probably less because CL makes an attempt at handling the pathname issues. Archaic naming Is this really a problem? People who don't speak English seem able to learn programming languages in which all of the symbol name choices would seem meaningless initially. And plenty of common English-like names don't actually map to their English equivalents: 'for' in C has almost no relation to 'for' in English, and even 'or', which in programming languages is always inclusive, is usually used exclusively in English. Not uniformly object-oriented On the rare occasion that I want to implement something like a new type of sequence, or arbitrary precision floating point numbers, I care about this. The most common case though, is wanting to implement a new type of stream, which has already been fully handled by gray-streams, widely implemented on all CL implementations you would actually want to use.
- dbul 18y ago
  It's not so much putting up a straw man as it is flat-out whining. There wasn't much profound in his complaint. Too many concepts -- what language doesn't? Hard to compile -- nonsense. Too much memory -- like any language, it depends on how efficient of a programmer you are. Archaic naming -- please.
jgrant27 18y ago
http://jng.imagine27.com/articles/2009-04-07-135246_cl_hard_to_compile_efficiently.html http://jng.imagine27.com/articles/2009-04-07-135246_cl_hard_...
deleted 18y ago
[deleted]

26 points by parenthesis 18y ago

sbt 18y ago

This is an even better post than the previous. I think Weinreb hits the spot and demonstrates that he is pretty well oriented about what's going on at the grass roots. Now, all the community need to figure out is what to do about these problems. Because the diagnosis is sound, in my opinion.

stcredzero 18y ago

Daniel is right, and splitlist is wrong. Irregularity is clearly harmful. It is much more difficult to produce new parsers and VMs for Ruby than it is for Lisp, Smalltalk, and even Python. This has clearly had an impact on the Ruby community. It should be possible to produce a "mainstream" language with the attractive qualities of PHP, Perl, Ruby, and Python, but with a more elegant design. (Ruby itself was implemented as a way of getting the power of Perl, but with cleaner OO.) I suspect that Stallman had it right when he came up with his grand unification plan through GUILE. Modulo the cultural expectations of the programming mainstream Lisp makes a better compiler target than a language. Now, before the Lispers get all up in arms -- this would make a Lisp the "one language to rule them all."

jcausey 18y ago

(You know, something's always (bugged me) with Common Lisp (and other Lisps (for that matter)) but I can't seem (to remember what it was)) Allright, Lispers -- take the joke...

jrockway 18y ago
1950 called. They want their hilarious joke back.
gamache 18y ago
If you're gonna crack a Lisp joke that sucks, at least attempt prefix notation and pretty-printing.
mindslight 18y ago
You(know, something's, always, bugged(me), with, python, and(other, programming, languages, for(that, matter)), but, I, can't, seem, to(remember, what, it, was))

tc 18y ago

Dan Weinreb is a smart guy, but too many of these points seem like straw men, at least if the point of identifying problems with CL is to investigate the apparent lack of mainstream adoption. Let's see: Too many concepts; irregular Yes, but unless you're implementing the language you can really almost ignore the concepts you don't like. If you prefer property lists, then forget about alists if you want. But really, a lisp in which you couldn't make an alist would seem awkward and irregular to me. Hard to compile efficiently I benchmark. SBCL is fast. It's much faster than it needs to be for mainstream adoption. It knocks the socks off of perl, python, and ruby, for example. For years it destroyed the JVM in performance, though I presume that the JVM has caught up somewhat by now. And really, any language is hard to compile efficiently. GCC has received tens of thousands of hours of optimization. A naive C implementation would likely be slower than SBCL for real-world code. At this point in history, we've even figured out how to implement ECMA JavaScript efficiently. Too much memory OK, I can agree with this. All of us would like an implementation with a tree-shaker, for example. But for production applications this isn't too much of a problem. In 2009 you shouldn't still be using CGI calls. Not portable Java is 'portable' because there is one widely used implementation of the language. Trying to port code from the JVM to GCJ is not straightforward. Porting CL code that runs on Linux to BSD requires no work. Porting from Linux to Windows requires no more work than would be expected in Perl, and probably less because CL makes an attempt at handling the pathname issues. Archaic naming Is this really a problem? People who don't speak English seem able to learn programming languages in which all of the symbol name choices would seem meaningless initially. And plenty of common English-like names don't actually map to their English equivalents: 'for' in C has almost no relation to 'for' in English, and even 'or', which in programming languages is always inclusive, is usually used exclusively in English. Not uniformly object-oriented On the rare occasion that I want to implement something like a new type of sequence, or arbitrary precision floating point numbers, I care about this. The most common case though, is wanting to implement a new type of stream, which has already been fully handled by gray-streams, widely implemented on all CL implementations you would actually want to use.

dbul 18y ago
It's not so much putting up a straw man as it is flat-out whining. There wasn't much profound in his complaint. Too many concepts -- what language doesn't? Hard to compile -- nonsense. Too much memory -- like any language, it depends on how efficient of a programmer you are. Archaic naming -- please.

jgrant27 18y ago

http://jng.imagine27.com/articles/2009-04-07-135246_cl_hard_to_compile_efficiently.html http://jng.imagine27.com/articles/2009-04-07-135246_cl_hard_...

deleted 18y ago

[deleted]