Daniel Weinreb: Fundamental problems with the Common Lisp language(ilc2009.scheming.org)
ilc2009.scheming.org
Daniel Weinreb: Fundamental problems with the Common Lisp language
http://ilc2009.scheming.org/node/7?
6 comments
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.
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.
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.
Trying to port code from the JVM to GCJ is not straightforward.
Porting code between implementations that meet the Java standard, however is straightforward. Porting code between Common Lisp implementations that meet the ANSII specification isn't.
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.
It's not that hash tables, alists, and plists are redundant, (they aren't) but that they're too different. Hash tables are efficient, alists holds any kind of association and allows you to go both ways, and plists map right into argument key-lists. Each has an advantage the others can't easily duplicate. But, they hold very similar, and sometimes overlapping kinds of data.
It's trivial to write one, but there should be an established interface for converting between types as needed as well as one for using them. I should be able to pass a piece code a map of any sort, and expect the code to be able to handle it so long as it doesn't need to do anything particular to a specific kind of map. A single method, get-value, should be able to dispatch based on whether or not a data structure is a hash-table, etc and fetch the key/value pair requested.
Ideally you'd be able to do this with methods, but because alists and plist are of the same type, this isn't really possible, which leads into the un-uniformity of the object-orientation.
On the rare occasion that I want to implement something like a new type of sequence
It's not so much about implementing new kinds of sequences by about polymorphically extending the kinds that already exist. Both alists and plists are of the type 'list,' but they should be of the type 'alist,' and 'plist,' each of which a subtype of both 'list' and a generic 'map' class. This would make it much easier to design and extend a consistent interface across similar data-structures.
I've wanted for this ability before, attempting to design methods to instantiate objects that would either clone an object passed it, or accept a plist, hash-table, alist, and use the values listed to initialize the slots. I was able to do it, but my solution was significantly less clean that it should have been.
Porting code between implementations that meet the Java standard, however is straightforward. Porting code between Common Lisp implementations that meet the ANSII specification isn't.
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.
It's not that hash tables, alists, and plists are redundant, (they aren't) but that they're too different. Hash tables are efficient, alists holds any kind of association and allows you to go both ways, and plists map right into argument key-lists. Each has an advantage the others can't easily duplicate. But, they hold very similar, and sometimes overlapping kinds of data.
It's trivial to write one, but there should be an established interface for converting between types as needed as well as one for using them. I should be able to pass a piece code a map of any sort, and expect the code to be able to handle it so long as it doesn't need to do anything particular to a specific kind of map. A single method, get-value, should be able to dispatch based on whether or not a data structure is a hash-table, etc and fetch the key/value pair requested.
Ideally you'd be able to do this with methods, but because alists and plist are of the same type, this isn't really possible, which leads into the un-uniformity of the object-orientation.
On the rare occasion that I want to implement something like a new type of sequence
It's not so much about implementing new kinds of sequences by about polymorphically extending the kinds that already exist. Both alists and plists are of the type 'list,' but they should be of the type 'alist,' and 'plist,' each of which a subtype of both 'list' and a generic 'map' class. This would make it much easier to design and extend a consistent interface across similar data-structures.
I've wanted for this ability before, attempting to design methods to instantiate objects that would either clone an object passed it, or accept a plist, hash-table, alist, and use the values listed to initialize the slots. I was able to do it, but my solution was significantly less clean that it should have been.
"Yes, but unless you're implementing the language you can really almost ignore the concepts you don't like."
Or unless you are reading other people's code.
Or unless you are reading other people's code.
Yes, hence "almost." Of course, this is true regardless of the language. In C, for example, even though the language does not include linked links, I've parsed through lots of programs using linked list in C (with the added treat that each program is reimplementing the concept differently).
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.
Now, all the community need to figure out is what to do about these problems. Because the diagnosis is sound, in my opinion.
[deleted]
(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...
Allright, Lispers -- take the joke...
1950 called. They want their hilarious joke back.
If you're gonna crack a Lisp joke that sucks, at least attempt prefix notation and pretty-printing.
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))
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."