A good criticism of the comon lisp language(?)

[Jasper]

Via reddit, this article.

I'd like to add:

• Slapped-on type system.(Which probably has part in causing optimization problems, imo)
• Not modular enough; a lot of stuff should be libraries, instead of part of the language. Hell, who says that a Lisp even has to have lists after compilation? After all the macros are run, you don't need them anymore.
• Lisps are still awesome; next to stack languages the only sane way to represent a language. (that i know of)

As i excessively/compulsively advertise here, i got a project; Lang-lisp, it is far from ready to be used though.(And the site has to be better too)

Btw i can't believe people in reddit are whining about the lisp-1/lisp-2 thing, seriously..

[findinglisp]

Yes, I saw that yesterday, too. FYI, Dan Weinreb is a member of this forum. Dan has been around Lisp for a LONG time. He knows of what he speaks. Dan is a big Lisp supporter and he uses it a lot at ITA software on a daily basis. He was one of the original crew at Symbolics that created some of the first commercial Lisp machines. He implemented Emacs in Lisp a couple of times on Lisp machines. In most of his criticisms, I fully agree with him.

Also note that in this article, Dan is not criticizing Lisp itself, but rather issues with Common Lisp. It's important to realize that Common Lisp wasn't so much designed as it was agreed upon. That is, the whole drive of Common Lisp was DARPA basically telling the Lisp community to stop proliferating numerous Lisp dialects and to come together and agree on a standard that could be used by DARPA for all future Lisp projects. As a result, Common Lisp just standardized bits and pieces of multiple Lisp dialects and makes numerous compromises based on the implementations that were in existence at the time (nobody want to completely reimplement everything). Yes, there were some other very interesting pieces of new work, such as CLOS, but much of the standard simply put a stamp on existing practice from one or more different dialects. In other words, in the same way that a camel is a horse designed by a committee, Common Lisp is a Lisp designed by committee. Even worse, there was a specific goal of trying to keep compatibility with as much code as possible. This meant that even when warts were obvious, there was great incentive to avoid fixing them unless it was absolutely necessary to do so. From talks with people involved with the process, my sense is that the whole thing was so painful that nobody has had the emotional energy to do any more standards work on Common Lisp since, and that's one of the reasons that CL has been so static.

Richard Gabriel's site has a nice essay titled The Evolution of Lisp that goes into all the various Lisp standards efforts. There are a lot of other great essays there about Lisp if you are interested as well. I particularly recommend Worse is Better.

[schoppenhauer]

In http://ilc2009.scheming.org/node/7 problems are mentioned, but no solutions. I mean, what alternatives are there? Scheme? Clojure? NewLisp? I dont see that they are really much better in the end (maybe in single concepts, but not in general).

Wouldnt it be the best way to say "ok, thats an old concept, dont use it" to deprecated things, and define some "recommendation" out of that, i.e. a set of parts of common lisp that programs should not use, but leaving the decision to the programmer? That is, instead of creating something completely new, just use a subset of the old and fit it to today's needs? Just throw away anything which is not common or "good" in some way, tell alternatives, and maybe put additional comments for common libraries into it, like CLOS-Streams, usocket and trivial-socket, the CFFI, etc., which many people use? Then the programmers of compilers could focus on that and implement the deprecated stuff - if they wanted ANSI-Compliance - in a non-optimized way (so old code still works but works slow), or they could use some kind of wrapper-libraries providing old deprecated concepts using new concepts for downward compatibility.

Common Lisp is an old language which has a lot of Code and Research. Why just throwing it away?

Ok, this would also just produce a "new common lisp" which may have the same problems in 20 years but then one could just do the same again.

[TheGZeus]

In http://ilc2009.scheming.org/node/7 problems are mentioned, but no solutions. I mean, what alternatives are there? Scheme? Clojure? NewLisp? I dont see that they are really much better in the end (maybe in single concepts, but not in general).

Wouldnt it be the best way to say "ok, thats an old concept, dont use it" to deprecated things, and define some "recommendation" out of that, i.e. a set of parts of common lisp that programs should not use, but leaving the decision to the programmer? That is, instead of creating something completely new, just use a subset of the old and fit it to today's needs? Just throw away anything which is not common or "good" in some way, tell alternatives, and maybe put additional comments for common libraries into it, like CLOS-Streams, usocket and trivial-socket, the CFFI, etc., which many people use? Then the programmers of compilers could focus on that and implement the deprecated stuff - if they wanted ANSI-Compliance - in a non-optimized way (so old code still works but works slow), or they could use some kind of wrapper-libraries providing old deprecated concepts using new concepts for downward compatibility.

Common Lisp is an old language which has a lot of Code and Research. Why just throwing it away?

Ok, this would also just produce a "new common lisp" which may have the same problems in 20 years but then one could just do the same again.

Hmm...
C and C++ are both here, as is D.
Common Lisp seems a bit like an attempt to make the "one true C-type language."

I think it might be time to allow CL to die off into the sea, and let these other languages be the best at their intended purpose.

[nuntius]

I know many people take what Dan W writes as the gospel truth, but my take was that he was trying to generate a conversation by throwing out a bunch of "not quite false" starters.

IMO, the entire separate board was a bad idea; the conversation would have been better here. Oh well. He did set up a nice site, but it just takes to long to establish an online community (especially of lispers).

Just as a teaser to the C/C++/D guy: these languages are just now popularizing the things (e.g. functor objects = manually-rolled lambda closures) which make CL slow and hard to compile efficiently. There are headers in the Boost C++ library which add 30s to a single file's compile time, just by #including them. No, C++ doesn't have it solved. In fact, CL generally compiles this stuff faster (real macro language trounces template metaprogramming) and often results in more efficient code. For numerics, C or Fortran generally win hands down (why don't CL folks care to fix this? It's boring but straightforward) -- but for general-purpose computing...

[TheGZeus]

Just as a teaser to the C/C++/D guy: these languages are just now popularizing the things (e.g. functor objects = manually-rolled lambda closures) which make CL slow and hard to compile efficiently. There are headers in the Boost C++ library which add 30s to a single file's compile time, just by #including them. No, C++ doesn't have it solved. In fact, CL generally compiles this stuff faster (real macro language trounces template metaprogramming) and often results in more efficient code. For numerics, C or Fortran generally win hands down (why don't CL folks care to fix this? It's boring but straightforward) -- but for general-purpose computing...

I was saying that we should use Clojure for foo, Scheme for bar, Newlisp for baz...
There's no one sitting there with everything wrong and right with all of these that it's great and perfect.

[phil]

Is the reason that Common Lisp receives so much criticism because there really are so many problems in the language that it stops you from using it or is it because people observe a resistance to change the language in the community?

If it's the former then the criticism is justified, even if many of us don't seem to run into these problems. If it's the latter then perhaps more needs to be made of the fact that CL is very malleable to the point that a perceived limitation can often be easily side-stepped.

Please note that while I am an enthusiastic Common Lisp programmer, I'm not in denial about certain problems. Rather, I see that no programming language is perfect and as a result prefer one which allows me to change it when I need

[gugamilare]

Is the reason that Common Lisp receives so much criticism because there really are so many problems in the language that it stops you from using it or is it because people observe a resistance to change the language in the community?

I believe it is a bit of both, or sort of. CL has some defects. I didn't read the article that Jasper mention mostly because I've probably seen many (most?) of these common criticisms to Common Lisp and I am even tired of reading those and thinking about what I agree or what I don't. I like the language the way it is, and it has its little problems, and I won't care until I have some big impediments when using CL.

It is most likely that at least 70% of complains about CL are just newbies that are having difficulties to adapt themselves to the language. Sometimes (not all times) they are just finding some excuses not to keep learning CL. Lisp in general is a complex language, people won't learn it if they don't have a reason to do so.

The other criticisms are real, made by people who really have some impediment in the language that mostly don't keep them from using it. I believe the only big impediment from using CL is the lack of libraries or programs in CL, well, when there really is an impediment. Well, ok, I might be wrong here. And there won't be lack of libraries if people use it.

CL is ANSI, and CL comunity is spread, it doesn't have a "center", so the language won't change so easily. If there are just some people who don't like it the way it is, it doesn't matter, it will keep that way. There probably will only have real changes in the ANSI spec if some company or association or whatever (with enough power or influence over the comunity) decide that it is time to build a new standard because of a serious limitation of CL, and invest people or money to do so. Otherwise, I don't think there will be any changes at all.

Well, this is just my opinion. If changes come and they are for the best, then it's fine; if they don't come, I'll keep programming in CL anyway. I just think it is already time for me to stop complaining and start programming. CL desperately needs users. Look at the language C. It is the worst programming language ever (ok, there are worse languages, I am just being a bit dramatic ) but it has so many users that people keep using it whatsoever - even a watch can be programmed in C, most (all?) operating systems are made in C... And I believe that the same argument can be given about Windows XP being so widely used.

[Paul Donnelly]

Is the reason that Common Lisp receives so much criticism because there really are so many problems in the language that it stops you from using it or is it because people observe a resistance to change the language in the community?

I think it's because Lispers love to complain, but the problems with Common Lisp, while annoying, are often nothing more than that. For example, going down Dan Weinreb's list:
1. The existence of plists, several standard ways to loop, setq, both CLOS and older built-ins that do their own type dispatch (ties in with #7), and so on can be pretty much ignored. Just use the one you like best.
2. Sucks for those compiler writers, eh?
3. Memory is cheap.
4. See #2.
5. Who cares what Clozure does? I'm on SBCL (or CLISP, or ACL, or what have you). Mostly it's okay to be uni-platform, or not support all of them. Only in the F/OSS world do programs need to run on every system in the world.
6. Actually, I disagree with that one entirely. My other "retorts" are flippant, but I like the sense of history. Learning a couple of new words is not hard.
7. Good thing it's not really necessary.

I don't really mean to downplay these problems, but rarely are they show-stoppers. I'd like to see most of this stuff fixed. I think of them as being right over the "I hate this" threshold and right below the "I need to fix this right now" threshold. Anything that people complain about for decades seems big, but if it's that important, it either gets fixed or no one uses the language.

[Tom]

... and that aren't really that important, such as displaced arrays.

Ah! About a month ago, I would have agreed with this. Then, I realized that they are indispensable if you want a routine to compare the elements of 2 arbitrary arrays.

Code: Select all

(defun array-equal (array1 array2 &key (test #'number-equal))
  "Return true if the elements of the array are equal."
  (when (equal (array-dimensions array1) (array-dimensions array2))
    (every test
     (make-array (array-total-size array1)
                 :element-type (array-element-type array1)
                 :displaced-to array1)
     (make-array (array-total-size array2)
                 :element-type (array-element-type array2)
                 :displaced-to array2))))


I won't even insult you with the code I was using prior to this. I realize this may not be the "fastest" implementation, but it is getting the job done at the moment and I can always optimize later if necessary.

Which kind of sums up why I'd just as soon embrace the "Fundamental problems with the Common Lisp language", they're not inhibiting me from solving my problems. There are many parts of the language that I don't use, but as I've used it more, I've started to realize why those concepts are there. The current example is LOOP. I've avoided LOOP and found ways to use DOLIST, DOTIMES, DO and DO*. Recently, I kept finding myself using DO and friends in a unaesthetic manner and the rationale for LOOP clicked. Now I need to go learn LOOP. I'm realizing that the number of concepts in CL is beneficial.

I don't have enough knowledge to know if "hard to compile" is an insurmountable problem. Maybe "too much memory" can be solved with ECL http://ecls.sourceforge.net/ or something like L http://www.cs.cmu.edu/~chuck/pubpg/luv95.pdf.

"Unimportant features that are hard to implement" seems like a combination of "Too many concepts" and "Hard to compile efficiently", so I don't quite see how that is a separate problem from the previous problems.

"Not portable" is a problem that isn't a problem. It is a problem if portability between implementations is your goal. It isn't a problem if portability between systems is your goal. But portability between systems might be a problem if you choose an implementation that isn't portable. Luckily, there are several implementations available so you can choose one that fits your problem.

"Archaic naming" is a non-issue because CL has "Too many concepts", so you don't have to use the "Archaic naming". I'd like to take this opportunity to suggest starting an annual Common Lisp programming challenge along the lines of the "Obfuscated Code Contest" called the "Archaic Code Contest".

"Not uniformly object-oriented" has actually been a problem for me. But, compared to the conceptual limitations that I've hit my head against in other languages, I can live with it.

Sometimes I think the "Fundamental problem with Common Lisp" is that it is just good enough to enable us to envision the "perfect" programming environment, but not bad enough to motivate us to define and implement it.