A good criticism of the comon lisp language(?)

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..

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.

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.

schoppenhauer wrote: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.

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...

nuntius wrote: 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.

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

phil wrote: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.

phil wrote: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.

... 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.

(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.

schoppenhauer wrote: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.

I don't think any Lisp has ever just thrown anything away. Sheesh, every Lisp I know of still has CAR, CDR, and CONS.

Seriously, every Lisp ever designed learns from the experiences of its predecessors (except the first, obviously). IMO, Scheme is a good example of a "reformed" Lisp, which tried to be very true to the spirit of what had gone on before, but also left a lot of the cruft behind. Clojure does something similar, I think, but is more radical in some respects. The problem is that Scheme is minimalist and therefore it's hard to write "real" programs in standard or RxRS Scheme. You can certainly do it in a specific implementation such as MzScheme or Scheme48, but then you're bound to that implementation. CL has some of the same problems when you get to the fringes (networking, threading, etc.), but the fringes with Scheme start pretty quickly.

IMO, a group of interested Lisp folks need to come together and create the spec and reference implementation for a new version of Lisp that leverages the experiences of the past, but cleans things up. I always have this vision of a clean spec, like Scheme, that is also expansive enough to write real programs, like CL but even more so by creating standard behavior around modern requirements like threading and networking, for instance. Clojure is a good example of that, but I'm always turned off by the use of the JVM. Maybe that's just me and I need to spend more time with it. I'm not negative on Clojure generally, and I respect many of the things that Rich has done with it. The pure-functional data structures are very cool (though I haven't seen any good benchmarks about performance), and I can even appreciate the use of the JVM in those environments where your only choice is to run on the JVM (Google AppEngine just announced support for the JVM and my first thought was, "Oh, you could probably run Clojure on that. That's cool!").

The big problem is that nobody with enough "weight" in the Lisp community has the stomach for standards work any more. Everybody reacts like a dog that has been kicked daily for 3 years whenever anybody mentions Lisp standards. There is a big "don't go there" reaction. As a result, CL just stagnates, which is I think what Dan is reacting to.

Lisp seems to be getting more interest in recent years, coming out of the AI Winter. That's good. The problem is that while everybody is interested, when they go to look at the reality of things, they find that Lisp has been static since the early 1990s and doesn't match up well versus the full-featured programming languages being introduced today (things like Perl, Python, Ruby, etc.). It isn't that Lisp can't do the same things, it's that the implementations and libraries are very spotty and it's hard to assemble the environment that you want. Perl is full featured as a base language and it has CPAN if you want more. Python is too, and it has eggs. Ruby, likewise, and it has gems. CL doesn't even have a standard networking layer, and ASDF-INSTALL is brittle and while there are other options (Mudballs, etc.), none yet have critical mass.

Tom wrote:

... 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.

(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.

That's an interesting usage of displaced arrays, but it seems pretty costly in terms of garbage generated. Typically, when I call a predicate, I don't expect it to cons. Obviously, if you only call it rarely, that won't be a problem, but just recognize that you're making the GC work overtime.

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.

Yea, I don't see anybody arguing for too many fewer concepts. Most everything in CL has stood the test of time, and I find myself often saying, "Oh, that's useful," too, but in some cases we have multiple implementations of essentially the same thing (plists vs. alists, for instance). BTW, I would not classify LOOP vs. DOLIST or DOTIMES as examples of this issue. If you're just iterating over a list or for a specific number of times, DOLIST and DOTIMES are more straightforward, IMO. But their simplicity also means they cannot do things that LOOP or DO can. For what it's worth, I prefer LOOP over DO, but I'm starting to get tempted by ITERATE.

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.

ECL is a great implementation with a small footprint, but ECL can't solve fundamental CL issues. Weinreb is talking about things that are intrinsic to the language, not the implementation. The only way to solve those problems is to change the language itself.

"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.

Realize that sometimes feature complexity can domino across into other features, too. You end up with situations where you say, "I can't do optimization X because somebody might use feature Y and they aren't compatible." Weinreb is suggesting that since feature Y isn't used very often, it would make more sense to remove it and thereby make it easier for compiler writers to use optimization X. What are X and Y? I have no specific clue, but this comes up all the time in other languages, too, so I assume there are many (e.g. pointer aliasing in a big problem in optimizing C). Displaced arrays were mentioned and I think that they do probably force a couple more indirections when trying to access the data.

"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.

Yes, but... if too many things aren't portable, there is little reason to have a specification and standard. Simply allow everybody to implement their own version of "Lisp" and be done with it.

Also, portability is a stunting factor in the development of libraries. If everybody writes implementation-specific code, you end up with balkanized libraries.

"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".

Yea, I don't have too much problem with funky naming. Every language has some funky naming and you just have to get used to it. CAR vs. FIRST isn't that much of a problem for me. The bigger problem is regular naming. For instance, I love Scheme's use of "!" to signify mutation. I'd rather have APPEND and then APPEND! rather than NCONC.

"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.

Yes, but that's the sort of thinking that keeps anything from improving. In other words, I don't think anybody is arguing that CL is unusable. It isn't. People use it all the time. It's a great language, with a lot of great concepts. The only thing that Weinreb is saying is that it's a great example of a language that has evolved over time and now need some clean up. In the same way that we "refactor" code over time, the same concept could be applied to languages.

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.

You may be right.

Tom wrote: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.

Personally i prefer iterate, which is better in a bunch of ways.(imo, i discussed in this thread, hmm discussion of iterate and such a little later in that thread.)

gugamilare wrote: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.

Yeah, some reactions are pretty awful, like 'if i read (+ 1 (* 3 4) 5) i have to start reading in the middle and not with 1 + 3 *4 +6' this sort of statement makes me think they do not even know what they're reading.

findinglisp wrote:but in some cases we have multiple implementations of essentially the same thing (plists vs. alists, for instance).

Sometimes, though you need two implementations of exactly the same thing though. Basically hash tables, plists and alists, all do the same thing, except plists and alists are faster for smaller numbers of items.(But making them lists too doesn't make sense to me, conceptually.) The point where which of these implementations is chosen is when you decide the structure, hence the functions, gethash, assoc and getf should be one overloaded function.
Another case is sorting methods. There sometimes it is governed by the structure, red-black trees and sometimes they are just lists with different methods of sorting.

But i guess we do not always see the problem clearly enough to have one interface to multiple different implementations for different areas. Or it would take to long to see it. (Or maybe even not possible to make such an interface.) However, i guess a language/standard libraries should give such interfaces when we are able to without punishment.

An example where i do not think we could make a good single interface to multiple 'sorting' rectangles (or should we be more general? shapes?) could do this with quadtrees for instance. When i wanted to do this for simulation i looked at this but i didn't really get it.(Edit: was i stupid, now i see 'delete', 'insert', 'search', not that hard..) Quadtrees can be useful for drawing heightmaps, making easy interfacing hard too. (Btw 'quad-arrays' are inferior to quadtrees; you can make multiple levels of quadtrees in one structure, within which you can find a 'correct' element in the quad tree in one step.)

Thanks for your replies(not to imply not to keep them coming ), nice to know people here are open but not uncritical about improving lisp. On the other hand environment is very important too though, packaging easy installable libraries, utilities and documentation certainly sounds a good idea. I suspect that this causes more loss of people to other languages then problems with the language itself.

Jasper wrote:

Tom wrote: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.

Personally i prefer iterate, which is better in a bunch of ways.(imo, i discussed in this thread, hmm discussion of iterate and such a little later in that thread.)

I think Iterate is a good point for Common Lisp: The default answer for major changings to common lisp is mostly "why dont you write a library for that" - the fact that "iterate" exists, and can be used instead of loop if you wish, shows how flexible common lisp is.

Jasper wrote:The point where which of these implementations is chosen is when you decide the structure, hence the functions, gethash, assoc and getf should be one overloaded function.

I think it shouldnt be too hard to implement some kind of associated array class which overloads this function. Or at least define functions which do typechecking themselves for that (and use compiler macros for optimizing). Thats the same point: Just write a library "trivial-associative-arrays" that defines a "get"-function and use it and make others use it - if enough people use it, it will be portable since every implementation will want to support it (if its not pure-ansi, though).

And thats why I said: Dont throw Common Lisp away. Keep Common Lisp, but say whats deprecated, tell the people whats "not good coding style", and give "good" alternatives (like the iterate-library which could be recommended).

findinglisp wrote:That's an interesting usage of displaced arrays, but it seems pretty costly in terms of garbage generated. Typically, when I call a predicate, I don't expect it to cons. Obviously, if you only call it rarely, that won't be a problem, but just recognize that you're making the GC work overtime.

What's memory?

When I initially implemented that, I wondered if it was excessively consing, but the HyperSpec gave me the impression it might not be to bad.

HyperSpec wrote:displaced array n. an array which has no storage of its own, but which is instead indirected to the storage of another array, called its target, at a specified offset, in such a way that any attempt to access the displaced array implicitly references the target array.

I just profiled it and it is indeed consing a lot. Thanks for the heads up. It's still not a problem for my application, but now I'm a little worried. My MO at the moment, though, is make it concise and correct. Then, when the performance is unacceptable, profile and optimize.

findinglisp wrote:

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.

ECL is a great implementation with a small footprint, but ECL can't solve fundamental CL issues. Weinreb is talking about things that are intrinsic to the language, not the implementation. The only way to solve those problems is to change the language itself.

So, maybe what we're looking for here is not an updated Common Lisp, but a different lisp. That's basically what the link to L above describes, although it is a subset of Common Lisp. Upon further review of the ILC 2009 forum article, it appears that Weinreb was not referring to small memory so much as fast startup.

Weinreb wrote:OK, I should not have put it in terms of memory. The real point is that it should be possible to write programs that start up fast. In fact, I've been having a whole conversation on another blog about this. See ...

This is getting a little confusing.

findinglisp wrote:

"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".

Yea, I don't have too much problem with funky naming. Every language has some funky naming and you just have to get used to it. CAR vs. FIRST isn't that much of a problem for me. The bigger problem is regular naming. For instance, I love Scheme's use of "!" to signify mutation. I'd rather have APPEND and then APPEND! rather than NCONC.

Well, that falls under the first problem he stated.

findinglisp wrote:

"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.

Yes, but that's the sort of thinking that keeps anything from improving. In other words, I don't think anybody is arguing that CL is unusable. It isn't. People use it all the time. It's a great language, with a lot of great concepts. The only thing that Weinreb is saying is that it's a great example of a language that has evolved over time and now need some clean up. In the same way that we "refactor" code over time, the same concept could be applied to languages.

I waffle on this subject. Having Common Lisp defined and static is a benefit from the perspective of not having to worry about losing the investment made in writing a library and learning the idiosyncrasies of the language. The enemy you know is always better than the enemy you don't.

On the other hand, stasis is death, and there are obviously many lessons learned and changes in the computing environment since 1994 that would benefit an updated Lisp. On reflection, what I think I would want to see is not a new Common Lisp, but a new Lisp based on Common Lisp. Two things are required for me to buy into it:

(1) A detailed design and analysis document
The document should itemize the motivations for designing a new lisp. It should describe each problem, show specific code demonstrating the problem, a
literature review of the history of the problem, solutions to the problem and the proposed solution.

The document should then describe what the language will provide. Are we talking batteries included or a tight core language? Personally, I like the idea of a tight core language with everything else as a library. It's worked well for C. But, then again, you can't argue with those that advocate the Java/Python batteries included approach. No, really, I'm serious, you can't argue with them.

Finally, the document should define the language like the HyperSpec does, but without allowing implementation defined behavior. I realize this contradicts my previous argument, but that was cast in light of I don't really think it is a problem for Common Lisp. But in the new language, might as well get rid of implementation differences to negate this argument from the outset.

(2) A reference implementation
A design document is one thing, but there are complications with designs that simply don't manifest until you actually start to implement the design. So, there should be a reference implementation that evolves with the design document. Only when the implementation is fully synchronized with the design document should the new Lisp be frozen.

I could really care less if it is an ANSI standard. In fact, it would probably be better if it wasn't. I think a moderated wiki would work better. And without a standard, when the next round of miscreants surfaces griping about this new Lisp, they can fork it and run off into their corner and hack away to their hearts desire. I would argue this hasn't hurt the BSDs and in fact is beneficial when you consider the cross pollination that occurs.

@nuntius: When you say "not quite false", I'm not sure what you mean.

The reason I set up a separate site was that I had the idea that the conference could have its own site that would act as an extended part of the conference itself. I was hoping that a bunch of active threads would be set up before the conference happened. That way, we'd have some well-developed discussions in progress that we could continue in person. For the most part, the experiment didn't work. Maybe it's just a bad idea, or maybe it could have been done more effectively.

It seems to me that to consider the next 50 years of Lisp (or even the next five years), it helps to start off by being more concrete about what we feel the problems are with where we are now. I tried to gather together all the valid complaints that I could find about Common Lisp that many people were voicing, or that were fairly fundamental.

@schoppenhauer: There are no proposed solutions because that particular thread was just about gathering up the problems in Common Lisp. There are several things one can do, and they're not mutually exclusive: find ways to improve things for Common Lisp users, and/or work on new dialects that aren't Common Lisp. So I wanted separate threads for those topics, just to keep everything straight. What you're suggesting is one approach, but once you've defined this Common-Lisp-like new dialect, then what? Try to get a lot of the existing implementers of Common Lisp (there are 11 of them) to sign up to produce it? It might be hard to get agreement. However, don't let me stop you!

schoppenhauer wrote:I think it shouldnt be too hard to implement some kind of associated array class which overloads this function.

Yeah, it is pretty near trivial with common lisp:(untested)

(defmethod getsym ((sym symbol) (hash hash-table)) (gethash sym hash))
(defmethod getsym ((sym symbol) (plist list)) (getf plist sym))
(defmethod getsym ((str string) from) (getsym (intern str 'package-for-strings) from))

Tom wrote:The document should then describe what the language will provide. Are we talking batteries included or a tight core language? Personally, I like the idea of a tight core language with everything else as a library.

I thought 'batteries included' referred to a good number of (standard)libraries. Are the batteries in Java/Python really included in the language(gasp) or are they libraries? For me a tight core language with everything else as (standard)library is just-about a requirement. Maybe even to the level that the language is not really usable without the standard libraries it comes with. It should definitely come with 'batteries included' as-in easily installed/pre-installed recommended libraries.

I agree with your requirements for buying into a new lisp, but the road to the new lisp is different; it doesn't have to satisfy the requirements immediately to be good potentially. Also some issues, like namespaces/package systems are orthogonal to the others.

Tom wrote:The document should itemize the motivations for designing a new lisp. It should describe each problem, show specific code demonstrating the problem, a literature review of the history of the problem, solutions to the problem and the proposed solution.

I am not so sure that everything should be seen as 'this is a problem with CL and this solves it'. For instance, say the new language is more general at something then CL, and shows that this isn't a problem for speed or anything else. Isn't it CL that should prove that this generality is somehow not useful, rather then that of the new language?

Tom wrote:Finally, the document should define the language like the HyperSpec does, but without allowing implementation defined behavior. I realize this contradicts my previous argument, but that was cast in light of I don't really think it is a problem for Common Lisp.

At some places i agree, but at others, having implementation defined behavior can make the implementors job or making things faster easier. The only place (i think) this happens is numbers though. I see no reason why every number type should behave exactly the same across cpus and implementations.

dlweinreb wrote:The reason I set up a separate site was that I had the idea that the conference could have its own site that would act as an extended part of the conference itself. I was hoping that a bunch of active threads would be set up before the conference happened. That way, we'd have some well-developed discussions in progress that we could continue in person. For the most part, the experiment didn't work. Maybe it's just a bad idea, or maybe it could have been done more effectively.

I guess people didn't feel like registering, making a password and all. I guess there have been many discussions outside your website. (Actually, sometimes when i want to look up a discussion i actually type "reddit " infront of the url to look up if there is a discussion on reddit.)

Why should the 11 common lisp implementors sign up to produce it? It would be great when they do, but i don't see it any reason for being a requirement.