7 ms·

Me too. It’s too bad how stale the language has gotten.

peatmoss 9y ago
I think for people who want to be able to have a bit of lisp into their daily lives, Clojure is where the majority of the current industry-focused mindshare is going. At least as far as new development of language features is concerned. For people who are less industry focused, and more interested in the evolution of lisp from a CS perspective, Racket has gobbled up that mindshare. Common Lisp, in spite of its strengths, multiple standard implementations, and historical pedigree, seems at risk of fading more if there isn't some new lifeblood injected. The problem if I understand it, is that the Common Lisp spec is so gigantic, and was itself the product of a tenuous truce between many warring tribes of lisps long forgotten. I wonder how possible a new spec even is?
- lispm 9y ago
  > The problem if I understand it, is that the Common Lisp spec is so gigantic, and was itself the product of a tenuous truce between many warring tribes of lisps long forgotten Seems you understand it wrong. Common Lisp is a mainline Lisp, based on a direct line of specific Lisp heritage. Technically Common Lisp is mainly a modernized/standardized/portable version of Lisp Machine Lisp (aka Zetalisp). Clojure OTOH is fully incompatible with any previous identified Lisp dialect, so it is dubious to call it a Lisp.
  - peatmoss 9y ago
    > Seems you understand it wrong. Common Lisp is a mainline Lisp, based on a direct line of specific Lisp heritage. Technically Common Lisp is mainly a modernized/standardized/portable version of Lisp Machine Lisp (aka Zetalisp). Sure, I’m not intimately familiar with the lisps that Common Lisp drew from to be able to say what percentage was drawn from where. On the other hand, primary source material collected here (http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/doc/history/cl.txt http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/l...) would seem to suggest that CL at least considered the need to balance considerations of differing lisp communities of the time. > Clojure OTOH is fully incompatible with any previous identified Lisp dialect, so it is dubious to call it a Lisp. Eh, you’re certainly more expert on lisps than I am, but I have to say that the argument that Clojure isn’t a lisp because it’s not literally compatible with prior lisps seems petty to me. It looks like lisp, acts like lisp, and is commonly understood to be a dialect of lisp. Until the Grand Governing Body of Lisp Certifiers meets and declares Clojure not-a-lisp, I’ll continue being entirely not-dubious about its status as such.
    - lispm 9y ago
      Common Lisp the Language: https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node6.html#SECTION00510000000000000000 https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node6.html#SE... > Compatibility: Unless there is a good reason to the contrary, Common Lisp strives to be compatible with Lisp Machine Lisp, MacLisp, and Interlisp, roughly in that order. Zetalisp is a Maclisp dialect. The is basically very little compatibility to Interlisp. This leaves us with Zetalisp as its main predecessor. When CL was designed, Zetalisp, NIL, Spice Lisp and S-1 Lisp (the ones mentioned mostly in the CL history) were active implementations. They are now forgotton, because they were superseded with a language directly based on their heritage or, in the case of Spice Lisp, they are now actually Common Lisp. If you actually look at Zetalisp, the main predecessor, it was actually as large or even larger than Common Lisp - and Common Lisp looks larger, because the language includes part of a library and it was documented in more detail than other Lisp languages. > it looks like Lisp But it does not run ANY prior Lisp application and basically no substantial, beyond (+ 1 2), Lisp application can run in Clojure without being rewritten. Not ported. Rewritten. Clojure does not have any compatibility to the Lisp from McCarthy - not in the language itself and not even as a compatibility layer. It does not have most of its functions and if the functions have the same name, they mostly do something different. Even if you look at basic numerics, it does not do what one would expect from a Lisp, but uses the host language semantics (Java/JVM, Javascript, ...). It's base data structure is not the linked list, like every other Lisp dialect. A sheep has four legs, but it is still not considered to be a dog - it can't even bark. For me the general concept of being a Lisp is so vague, that I prefer a more strict definition: a language and its successors which strive to be compatible in syntax, semantics, pragmatics and community. If we take being a Lisp in a broad meaning, then it includes languages like Logo, Dylan, maybe even ECMAscript/Javascript. Which makes it a meaningless term, IMHO. Sure it make you sometimes feel well to be included in a family - but often enough this sets expectations which can not be fulfilled: like reading a Lisp book and then trying the example code in those languages - and then it does not work... CL is a specific branch of the Lisp tree. Clojure is a new tree, based on roots in Java (runtime and interop), Lisp (various ideas, like expressions, macros, ...), FPLs (ideas like 'persistent' data structures, ...
      - peatmoss 9y ago
- kazinator 9y ago
  The Common Lisp spec came to under 1100 pages. That's not a lot. I made a small scripting language starting in 2009. The reference manual is close to 640 pages now if turned into a PDF (with no cover pages, table of contents or index). You go bit by bit, document everything, and you'll be surprised at how the pages stack up over the years. I think Steele's ClTl (Common Lisp, The Language), a major base document, is already at > 1000. ECMAScript (i.e. JavaScript) 2017 is 885 pages. C11 draft: 696 pages. C hardly does anything! Just compiles some Von-Neumann-style word-pushing computation to machine code, and supplies a bare-bones library. (The K&R2 book is 288 pages and the C90 standard is around that size also. In that K&R2 book, the authors state: "C is not a big language, and it is not well served by a big book." Ha!) C++ ... let's not go there.
  - lispm 9y ago
    CLtL1 had around 470 pages.
    - groovy2shoes 9y ago
      I don't have a copy of CLtL1 myself (though I vaguely recall checking it out from the university library a few times many moons ago). I'm replying to you because your post was the last stop for my train of thought, but this isn't a rebuttal by any means. CLtL2 has 1053 pages if you count the front- and back-matter, 975 if you don't. For comparison, the ANSI C11 standard comes to 683 pages, but I think it's worth mentioning that CL leaves far fewer things unspecified, is much more "powerful", and is written in such a way that it can reasonably serve as an introduction and a reference in addition to a definition, compared to the C11 standard which, imo, doesn't serve particularly well for any use other than definition (I'm far more likely to reach for Harbison & Steele than for ANSI C if I need a C reference, and if a handful of programmers trying to learn C given only the standard were broadcast on TV, I'd set my DVR, because that would be very entertaining). The Emacs Lisp reference manual weighs in at 1077 pages. Nobody really cares. Standard ML (revised) comes to 583 pages between the Definition and the Basis Library, but its succinctness comes at the cost of being nigh incomprehensible to mere mortals, since the ~100 pages of the Definition are largely occupied by formal semantics; this is both a good thing (formal semantics are nice to have) and a bad thing (to understand it you have to learn the formal language first... I don't consider this a huge deal, but my experience has been that most people can't be arsed). IEEE Scheme comes to 73 pages, but it omits a lot of things that would be considered essential for "programming in the large": modules, records, macros, &c. While I don't think it could serve as an introduction for anyone not already versed in a Lisp dialect or at least some applicative language, it does function rather well as a reference, except that 80% of the time you're better off checking your implementation's documentation (for example, the 895 pages of the Guile 2.0 reference manual). ISLISP is 127 pages (the "official" ISO ISLISP standard is also the most expensive of all of these documents by far, but fortunately Kent did us all a solid), and suffers from some of the same "problems"[1] as IEEE Scheme. BCPL punches at the featherweight class, containing the language definition, tutorial, examples, reference, virtual machine specification, and a source listing of a self-hosted reference compiler, all in a mere 183 pages. Despite its admirable simplicity, so few people seem to be writing any serious software in BCPL these days. I wonder why that is... Die-hard Wirth fans like to champion the fact that the Oberon-07 report is small enough to keep in your wallet, so you can drunkenly show it to strangers at the pub and proudly tell them all about your wee little language that you haven't seen since your Wirth left you 10 years ago. It's only 17 pages, but it deals almost exclusively with matters of syntax, including only the bare minimum informal, imprecise descriptions of semantics interleaved therewith. The library reference consists of a couple lists of procedure names without even an afterthought mentioning what they actually do, all the while making even the IEEE Scheme standard library look luxurious and capacious in comparison. The point of mentioning all this is that even after a language has been designed and documented, the act of writing it down comes with all kinds of tradeoffs. Pages numbering in the quadruple digits can be intimidating and perhaps tedious at times, but pages numbering in the double digits can be rather frustrating and just as tedious at times, too: when you find that some aspect of the language is only vaguely specified or communicated, and you have to take your best guess (which is probably wrong, as a rule of thumb); or when your program grows beyond the original intent and suddenly packages and CLOS really start looking like they're worth their weight in paper. The complexity of a programming language is many-dimensional, and there are many possible functions that can map that complexity into the single dimension of page count; some of those functions might result in standards that are great for neophytes but aggravating for professionals, others might yield results that are brilliant for implementors but absolute rubbish for students. All things considered, I think ANSI CL (and CLtL, for that matter) approximate a sweetspot in the language standard space, not even just in terms of how they're designed but in how they're written: they're immanently accessible to regular programmers, provide thorough coverage of the language and libraries in a format that also serves as a handy reference, and (usually) offer enough detail that implementors don't have to roll any dice. They're not absolutely perfect, but having read so many language standards from so many different perspectives (learner, practitioner, implementor, and once-upon-a-time author), I've really developed an admiration for those in particular. It's not an easy task to write a language definition, especially with a language as featureful as CL, and yet they still manage to do it in a way that I consider exemplary. — [1]: Depending on your use case, they're features rather than problems. Everything would be so much better if only we could all agree on a damn use case.
- deleted 9y ago
  [deleted]
- TurboHaskal 9y ago
  I went from Scheme to Common Lisp to Clojure and back to CL. My impression is that CL is doing better than ever.

I think for people who want to be able to have a bit of lisp into their daily lives, Clojure is where the majority of the current industry-focused mindshare is going. At least as far as new development of language features is concerned. For people who are less industry focused, and more interested in the evolution of lisp from a CS perspective, Racket has gobbled up that mindshare. Common Lisp, in spite of its strengths, multiple standard implementations, and historical pedigree, seems at risk of fading more if there isn't some new lifeblood injected. The problem if I understand it, is that the Common Lisp spec is so gigantic, and was itself the product of a tenuous truce between many warring tribes of lisps long forgotten. I wonder how possible a new spec even is?

lispm 9y ago
> The problem if I understand it, is that the Common Lisp spec is so gigantic, and was itself the product of a tenuous truce between many warring tribes of lisps long forgotten Seems you understand it wrong. Common Lisp is a mainline Lisp, based on a direct line of specific Lisp heritage. Technically Common Lisp is mainly a modernized/standardized/portable version of Lisp Machine Lisp (aka Zetalisp). Clojure OTOH is fully incompatible with any previous identified Lisp dialect, so it is dubious to call it a Lisp.
- peatmoss 9y ago
  > Seems you understand it wrong. Common Lisp is a mainline Lisp, based on a direct line of specific Lisp heritage. Technically Common Lisp is mainly a modernized/standardized/portable version of Lisp Machine Lisp (aka Zetalisp). Sure, I’m not intimately familiar with the lisps that Common Lisp drew from to be able to say what percentage was drawn from where. On the other hand, primary source material collected here (http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/doc/history/cl.txt http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/l...) would seem to suggest that CL at least considered the need to balance considerations of differing lisp communities of the time. > Clojure OTOH is fully incompatible with any previous identified Lisp dialect, so it is dubious to call it a Lisp. Eh, you’re certainly more expert on lisps than I am, but I have to say that the argument that Clojure isn’t a lisp because it’s not literally compatible with prior lisps seems petty to me. It looks like lisp, acts like lisp, and is commonly understood to be a dialect of lisp. Until the Grand Governing Body of Lisp Certifiers meets and declares Clojure not-a-lisp, I’ll continue being entirely not-dubious about its status as such.
  - lispm 9y ago
    Common Lisp the Language: https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node6.html#SECTION00510000000000000000 https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node6.html#SE... > Compatibility: Unless there is a good reason to the contrary, Common Lisp strives to be compatible with Lisp Machine Lisp, MacLisp, and Interlisp, roughly in that order. Zetalisp is a Maclisp dialect. The is basically very little compatibility to Interlisp. This leaves us with Zetalisp as its main predecessor. When CL was designed, Zetalisp, NIL, Spice Lisp and S-1 Lisp (the ones mentioned mostly in the CL history) were active implementations. They are now forgotton, because they were superseded with a language directly based on their heritage or, in the case of Spice Lisp, they are now actually Common Lisp. If you actually look at Zetalisp, the main predecessor, it was actually as large or even larger than Common Lisp - and Common Lisp looks larger, because the language includes part of a library and it was documented in more detail than other Lisp languages. > it looks like Lisp But it does not run ANY prior Lisp application and basically no substantial, beyond (+ 1 2), Lisp application can run in Clojure without being rewritten. Not ported. Rewritten. Clojure does not have any compatibility to the Lisp from McCarthy - not in the language itself and not even as a compatibility layer. It does not have most of its functions and if the functions have the same name, they mostly do something different. Even if you look at basic numerics, it does not do what one would expect from a Lisp, but uses the host language semantics (Java/JVM, Javascript, ...). It's base data structure is not the linked list, like every other Lisp dialect. A sheep has four legs, but it is still not considered to be a dog - it can't even bark. For me the general concept of being a Lisp is so vague, that I prefer a more strict definition: a language and its successors which strive to be compatible in syntax, semantics, pragmatics and community. If we take being a Lisp in a broad meaning, then it includes languages like Logo, Dylan, maybe even ECMAscript/Javascript. Which makes it a meaningless term, IMHO. Sure it make you sometimes feel well to be included in a family - but often enough this sets expectations which can not be fulfilled: like reading a Lisp book and then trying the example code in those languages - and then it does not work... CL is a specific branch of the Lisp tree. Clojure is a new tree, based on roots in Java (runtime and interop), Lisp (various ideas, like expressions, macros, ...), FPLs (ideas like 'persistent' data structures, ...
    - peatmoss 9y ago
kazinator 9y ago
The Common Lisp spec came to under 1100 pages. That's not a lot. I made a small scripting language starting in 2009. The reference manual is close to 640 pages now if turned into a PDF (with no cover pages, table of contents or index). You go bit by bit, document everything, and you'll be surprised at how the pages stack up over the years. I think Steele's ClTl (Common Lisp, The Language), a major base document, is already at > 1000. ECMAScript (i.e. JavaScript) 2017 is 885 pages. C11 draft: 696 pages. C hardly does anything! Just compiles some Von-Neumann-style word-pushing computation to machine code, and supplies a bare-bones library. (The K&R2 book is 288 pages and the C90 standard is around that size also. In that K&R2 book, the authors state: "C is not a big language, and it is not well served by a big book." Ha!) C++ ... let's not go there.
- lispm 9y ago
  CLtL1 had around 470 pages.
  - groovy2shoes 9y ago
    I don't have a copy of CLtL1 myself (though I vaguely recall checking it out from the university library a few times many moons ago). I'm replying to you because your post was the last stop for my train of thought, but this isn't a rebuttal by any means. CLtL2 has 1053 pages if you count the front- and back-matter, 975 if you don't. For comparison, the ANSI C11 standard comes to 683 pages, but I think it's worth mentioning that CL leaves far fewer things unspecified, is much more "powerful", and is written in such a way that it can reasonably serve as an introduction and a reference in addition to a definition, compared to the C11 standard which, imo, doesn't serve particularly well for any use other than definition (I'm far more likely to reach for Harbison & Steele than for ANSI C if I need a C reference, and if a handful of programmers trying to learn C given only the standard were broadcast on TV, I'd set my DVR, because that would be very entertaining). The Emacs Lisp reference manual weighs in at 1077 pages. Nobody really cares. Standard ML (revised) comes to 583 pages between the Definition and the Basis Library, but its succinctness comes at the cost of being nigh incomprehensible to mere mortals, since the ~100 pages of the Definition are largely occupied by formal semantics; this is both a good thing (formal semantics are nice to have) and a bad thing (to understand it you have to learn the formal language first... I don't consider this a huge deal, but my experience has been that most people can't be arsed). IEEE Scheme comes to 73 pages, but it omits a lot of things that would be considered essential for "programming in the large": modules, records, macros, &c. While I don't think it could serve as an introduction for anyone not already versed in a Lisp dialect or at least some applicative language, it does function rather well as a reference, except that 80% of the time you're better off checking your implementation's documentation (for example, the 895 pages of the Guile 2.0 reference manual). ISLISP is 127 pages (the "official" ISO ISLISP standard is also the most expensive of all of these documents by far, but fortunately Kent did us all a solid), and suffers from some of the same "problems"[1] as IEEE Scheme. BCPL punches at the featherweight class, containing the language definition, tutorial, examples, reference, virtual machine specification, and a source listing of a self-hosted reference compiler, all in a mere 183 pages. Despite its admirable simplicity, so few people seem to be writing any serious software in BCPL these days. I wonder why that is... Die-hard Wirth fans like to champion the fact that the Oberon-07 report is small enough to keep in your wallet, so you can drunkenly show it to strangers at the pub and proudly tell them all about your wee little language that you haven't seen since your Wirth left you 10 years ago. It's only 17 pages, but it deals almost exclusively with matters of syntax, including only the bare minimum informal, imprecise descriptions of semantics interleaved therewith. The library reference consists of a couple lists of procedure names without even an afterthought mentioning what they actually do, all the while making even the IEEE Scheme standard library look luxurious and capacious in comparison. The point of mentioning all this is that even after a language has been designed and documented, the act of writing it down comes with all kinds of tradeoffs. Pages numbering in the quadruple digits can be intimidating and perhaps tedious at times, but pages numbering in the double digits can be rather frustrating and just as tedious at times, too: when you find that some aspect of the language is only vaguely specified or communicated, and you have to take your best guess (which is probably wrong, as a rule of thumb); or when your program grows beyond the original intent and suddenly packages and CLOS really start looking like they're worth their weight in paper. The complexity of a programming language is many-dimensional, and there are many possible functions that can map that complexity into the single dimension of page count; some of those functions might result in standards that are great for neophytes but aggravating for professionals, others might yield results that are brilliant for implementors but absolute rubbish for students. All things considered, I think ANSI CL (and CLtL, for that matter) approximate a sweetspot in the language standard space, not even just in terms of how they're designed but in how they're written: they're immanently accessible to regular programmers, provide thorough coverage of the language and libraries in a format that also serves as a handy reference, and (usually) offer enough detail that implementors don't have to roll any dice. They're not absolutely perfect, but having read so many language standards from so many different perspectives (learner, practitioner, implementor, and once-upon-a-time author), I've really developed an admiration for those in particular. It's not an easy task to write a language definition, especially with a language as featureful as CL, and yet they still manage to do it in a way that I consider exemplary. — [1]: Depending on your use case, they're features rather than problems. Everything would be so much better if only we could all agree on a damn use case.
deleted 9y ago
[deleted]
TurboHaskal 9y ago
I went from Scheme to Common Lisp to Clojure and back to CL. My impression is that CL is doing better than ever.