Daniel Weinreb: Fundamental problems with the Common Lisp language
ilc2009.scheming.org
ilc2009.scheming.org
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."
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.
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.
Or unless you are reading other people's code.
Now, all the community need to figure out is what to do about these problems. Because the diagnosis is sound, in my opinion.
Allright, Lispers -- take the joke...