9 ms·

Can anyone please comment what advantages and short-comings Common LISP has over "modern LISP" (i.e. Clojure)?

FPGAhacker 8y ago
The community in clojure has been friendly in my experience. Unfortunately they’ve moved to slack for their communication. The clojure group on google is pretty stagnant which is too bad. Topic threads are the exception in a chat room. Conversations in a forum like groups can serve as their own documentation. Chat logs have to be deciphered.
- iLemming 8y ago
  There is Clojureverse
armitron 8y ago
(Mostly talking about SBCL) Mature native code compilation (including runtime assembler), type declarations that lead to optimizations in generated code, SBCL compiler can use declared types for compile-time type checks, read/compiler macros, extremely easy interface to C (JNI is a pain in the ass), multi-paradigm and doesn't prematurely optimize like Clojure (I have no need for STM or immutable data structures in 99% of the things I do), very powerful and flexible debugger, CLOS, more sophisticated interactive development. Clojure is a no-go for me primarily because it's tied to the JVM (or worse, Javascript) and the Java ecosystem but also because it prematurely optimizes with the sort of decisions it has made in the design space (immutability, STM, crippled reader, not Lispy-enough debugging and so on). Common Lisp is much more flexible in the sort of problems it allows you to explore and attack. Even the special features of Clojure (STM, immutable data structures) can be used in Common Lisp via existing libraries. Finally, for me Lisp == Lisp Machines and Clojure is a big step back in that regard (and not really modern at all) since it de-emphasizes (by lacking things that Common Lisp has) the interactivity that made Genera so iconoclastic and powerful.
- peatmoss 8y ago
  I do like Clojure for some of its opinions (immutable by default, strong encouragement of functional programming, convenient abstractions for collections, tasteful syntactic sugar). But, I too am not necessarily a huge fan of the ecosystems that Clojure is presently tied to. I'd love to see an SBCL implementation of Clojure or (especially) an LLVM based Clojure. I'm grateful when Clojure offers me an out from writing Java, but I also feel like I need to understand both the Java and the Clojure. The Rackjure dialect of Racket is pretty nice by my estimation (adds some of the conveniences of Clojure, isn't tied to / the beneficiary of an ecosystem like the JVM or Javascript). But I suspect it would frustrate people who like aspects of the CL ecosystem like long-lived system images, and a very neutral disposition toward immutability and functional programming.
  - FPGAhacker 8y ago
    Clojure isn’t really worth anything without the jvm/js ecosystem. It’s a glue language for assembling components, most of which are written in Java. Timothy Baldridge wrote a python based language heavily inspired by clojure called Pixie. That gives a feel for what clojure is like without the ecosystem. Basically it means reinventing many many wheels.
    - peatmoss 8y ago
      I don’t know—there are certainly some interesting / different things in Clojure as compared to other lisps. Even if you can technically do much of what Clojure can do in other lisps, idiomatic Clojure has a feeling that is distinct from CL, Scheme, or even Racket. If Clojure offers nothing without the large JVM/JS ecosystems, then we could say the same about most languages (that aren't the size of Java/JS). If it’s that the distinct cocktail of features and ideas in the language aren’t worth anything, then I’d respectfully disagree. But at that point we’d simply be arguing aesthetic preferences.
      - kamaal 8y ago
        Well that's the problem isn't it. Any new language today has little to compete with existing languages in terms language features, the competition is in terms or the library ecosystems, online help and overall ecosystem. That takes time and money to build. Given how large the Java ecosystem is, and what it took in terms of money and time to go there is not easy or even possible to match in any relative comparison. So it makes sense to make sacrifices(if needed) to re use all that Java work that has been done and has been going on over the years. Clojure is the best thing that has happened to Lisp in years.
justinhj 8y ago
Common Lisp has the advantage of being much more stable in terms of language changes. You can pretty much take CL code from the last two decades and run it. It's also got a better native compilation story. I like Clojure for bringing maps and vectors into first class language constructs with simple syntax and the fact that it runs on the JVM means I have access to the entire Java ecosystem of libraries and tools.
- lispm 8y ago
  I wonder where the vector myth comes from. Common Lisp always had a vector data type and syntax for it. Just not [], but #(). Actually Common Lisp has multi-dimensional arrays, bitvectors, ... Vector: CL-USER 102 > (map 'vector #'char-code "foobar") #(102 111 111 98 97 114) CL-USER 103 > (reduce #'+ #(102 111 111 98 97 114)) 633 Bitvector: CL-USER 105 > (reduce #'+ #*10101001010101) 7 2d-Array CL-USER 106 > (aref #2a((1 2) (3 4)) 1 1) 4
  - justinhj 8y ago
    I didn't say CL has no vectors or syntax, just that in Clojure using sets, maps and vectors, is much more similar to using lists than it is in CL.
    - lispm 8y ago
      Common Lisp reads and writes vectors, has a simple syntax for them and provides a sequence abstraction over lists and vectors.
      - justinhj 8y ago
        Operations that in Clojure require only changing the kind of brackets, in Common Lisp are more verbose and explicit. If you don’t see the clean syntax and simple utility in that then fair enough, but I do.
        lispm 8y ago
didibus 8y ago
I'd say pros: - Compiles to native - Superior REPL experience/interactivity - Easier C FFI I'd say cons: - Smaller ecosystem, not as many libraries. - Dated tooling. - Inferior support for multi-threading/multi-core. - Not as homoiconic. Only lists are by default. - Standard is abandoned. No new versions since 1994. Some CDRs till 2013. Neutral: - Leans towards OOP and imperative mutability over Functional and immutable. - Doesn't have unified abstractions over datastructures.
- IronBacon 8y ago
  I would add "- Better stack traces" to the pros.
- lispm 8y ago
  Common Lisp compiles to much more than just 'native'. Like C, LLVM, DLLs, ... and a has a bunch of exotic stuff like whole-program-to-C compilers, Common Lisp on the metal or Common Lisp on top of Prolog https://github.com/TeamSPoon/wam_common_lisp https://github.com/TeamSPoon/wam_common_lisp . Common Lisp also has full language interpreters: these are implementations of Common Lisp which interpret s-expression level code - not byte code. Common Lisp can easily dump images and make them executable. Saving and starting them is quick. Common Lisp has implementations mostly written in Common Lisp - including the compiler and large parts of the runtime.
  - vram22 8y ago
    Is this point of your parent commenter right? > - Not as homoiconic. Only lists are by default.
    - lispm 8y ago
      I read that, too. But I'm not sure what he means by 'Only lists are by default'. If he means that only lists have a literal representation, then it would be slightly wrong - since Common Lisp has literal representations for various numbers, symbols, characters, strings, vectors, arrays, structures, pathnames, ... Plus the s-expression syntax is user-extensible - making it as 'homoiconic' as the user needs it.
nextos 8y ago
I love Common Lisp (and I miss its frequent discussions on HN a decade ago). That trend seems to be resurfacing now. The main advantage of Common Lisp is standardization. There's very few languages that can run old code across so many platforms and implementations. But that also holds the language back a bit in terms of progress. Libraries feel like they have been falling a bit behind. It's also one of the few practical languages that has a great multi-paradigm support. The main advantage of Clojure is implementing lots of modern functional programming ideas. It's main disadvantage is being excessively tied to the JVM. That allowed initial rapid growth, but it brings some side-effects such as ugly stack traces. Aside from JavaScript, there are no alternative platforms. Racket will now run on top of Chez Scheme. That's another major Lisp worth considering. Lastly, Julia shows some of the multiple dispatch ideas in CLOS can lead to really efficient code generation when paired with LLVM or a similar backend. I wish someone put all these interesting ideas in a blender and implemented them on top of Common Lisp, or as a new language. Something functional, with great typing (like Shen), static analysis and an LLVM-like backend are really worth pursuing. We need better languages to address modern challenges, like merging symbolic and probabilistic AI.
patrec 8y ago
Common Lisp advantages: - "more interactive" resumable exceptions, better code reloading functionality - multiple values (cumbersome to use for superficial reasons, but with much better semantics than in e.g. scheme, for sure and probably also Lua) - compiler macros - readtable macros (although the design leaves to be desired) - more sophisticated pretty printer - more "target platforms"; with clojure it's basically jvm or, to a lesser extent, JS. If you dislike both you're out of luck - there's a treasure trove of old but interesting material that uses Common Lisp (like PAIP by Norvig) - much nicer for writing highly imperative code Common Lisp disadvantages: - Common Lisp has no eco system to speak off (but at least there's less churn than in clojure land) - the language is frozen/dead - career suicide, even compared to clojure - no high quality free implementations (for example sbcl has a rather poor garbage collector compared to java, go and other widely used languages) - single precision is de-facto the default floating point type - built around cons cells which are a terrible data structure: slow, cumbersome and brittle; there's OK support for vectors and slightly worse support for multidimensional arrays and hash-tables and very poor support for generic collection manipulation or efficient functional data structures - no out of the box support for laziness - no concurrency or parallelism abstractions - no good standard pattern matching library - brain drain: very few smart people doing interesting things left (most left by the 90ies) - often feels plodding and cumbersome compared to clojure (destructuring, basic string or sequence operations)
- sedachv 8y ago
  You have a lot of very wrong opinions on Common Lisp. > multiple values (cumbersome to use for superficial reasons How so? > Common Lisp has no eco system to speak off False. https://www.quicklisp.org/beta/ https://www.quicklisp.org/beta/ https://cliki.net/ https://cliki.net/ > the language is frozen/dead False. Extensions are being done through libraries and in the implementations. > career suicide, even compared to clojure I only ever get positive attention for having been a professional Common Lisp (and Scheme) programmer. Never had trouble finding freelance or full-time work. > no high quality free implementations (for example sbcl has a rather poor garbage collector compared to java, go and other widely used languages) How do you go from "SBCL's GC is slower than Java's" (which is a nonsensical statement, because different JVMs have different GCs), to "no high-quality free implementations?" There are three Free Software ones to choose from: SBCL, CCL, and ECL. > single precision is de-facto the default floating point type False. Where do you even pick up a ridiculous idea like that? http://www.lispworks.com/documentation/HyperSpec/Body/t_short_.htm http://www.lispworks.com/documentation/HyperSpec/Body/t_shor... > built around cons cells which are a terrible data structure Ignoring how dumb labeling the linked list a "terrible data structure" is, you do realize that data structures are something that you implement in a language, not something that you have to build into one? There are libraries for all kinds of data structures. > no out of the box support for laziness There is no reason to make it built in at the language level when you have closures. > no concurrency or parallelism abstractions That is handled by implementations and libraries. > no good standard pattern matching library Just a bunch of really great ones. > brain drain: very few smart people doing interesting things left (most left by the 90ies) You don't seem to know anything or anyone from the Common Lisp world. The best techniques for using the language (advanced use of closures, read macros, the condition system, and applications to domain-specific languages and transpilation) have only started coming out in the past 15 years, from people like Edi Weitz, Doug Hoyte, and Tobias Rittweiler. The only thing relevant from the 1990s is Paul Graham's On Lisp. Norvig's PAIP is very overrated.
kamaal 8y ago
One thing I tend to miss in Clojure is lack of TCO. Most people(like me), come to Lisp from SICP, The Little Schemer and PG's books. Where recursion is not just emphasized, you are actually trained to think recursively. I found lack of TCO to be a little like a stick in the neck when it comes to both Clojure and Emacs Lisp. It prevents you from thinking in the way you have been thinking in other Lisps. I understand Clojure depends on JVM and JVM doesn't do tail call eliminations yet, and Rich Hickey is right in thinking that method calls are too much a platform thing and we shouldn't be working around this limitation with a hack. However lack of TCO in Emacs Lisp is a little not easy to live with. From what I understand patches have been submitted to Emacs to make this happen but haven't made it to the upstream. TCO is very important for any language that sells functional programming these days. Apart from the performance advantages, Recursion is a thought framework. Limitations are not easy to live with. I hope some day Clojure and Emacs Lisp get TCO. On a tangential note, JVM is a great platform, its a also a widely used platform, so changes are going to come in very slowly. So I'm not holding my breath waiting for TCO.
- lispm 8y ago
  Most mainline Lisps either never did support TCO or only in some restricted way. The reason for that is that it clashes with other widely used language features in typical Lisps. There is a cost to supporting TCO - also a less nice debugging experience. Many CL compilers tend to support it with some restrictions - CL interpreters often not. Lisp Machines did not support it. CL on the JVM does not support it. https://0branch.com/notes/tco-cl.html https://0branch.com/notes/tco-cl.html I started with Scheme and Lisp (Standard Lisp, ZetaLisp, CL, ...) and wrote/used TCO a lot. I tend to view the use of TCO for basic iteration as a mistake, which makes code harder to read. I tend to like either higher-order iterative constructs or powerful iteration constructs like CL's ITERATE: https://common-lisp.net/project/iterate/ https://common-lisp.net/project/iterate/ I find the Clojure hack ugly.
  - kamaal 8y ago
    >>I tend to view the use of TCO for basic iteration as a mistake, which makes code harder to read. I understand some one like you is far more experienced and has been around for a long time. So obviously you know better than I ever will. And you are right. Even with very minimal Lisp exposure, after using Scheme and Common Lisp, Clojure's TCO thing feels unacceptable. In fact after using Common Lisp, and I'm a novice, even some one like me feels Common Lisp to be a far superior language compared to other Lisps around. The issue is, like I said, I started learning lisp starting with Scheme, and I started recently. First book was SICP, second was 'The Little Schemer', third was 'The Seasoned Schemer'. At that point your brain is hard programmed to think in terms of recursion, and whenever I see loops my mind moves to recursion automatically. You have to trust me when I say this, when I read PG's ANSI Common Lisp book , I skipped the sections on iterations and loops, because I thought I would never use them anyway. I have to say those Schemer books do their job really well. May be I just need more practice, so I will develop more stuff in Clojure, now that its not even possible to do that Clojure, eventually that TCO addiction should go away. :)

The community in clojure has been friendly in my experience. Unfortunately they’ve moved to slack for their communication. The clojure group on google is pretty stagnant which is too bad. Topic threads are the exception in a chat room. Conversations in a forum like groups can serve as their own documentation. Chat logs have to be deciphered.

iLemming 8y ago
There is Clojureverse

armitron 8y ago

(Mostly talking about SBCL) Mature native code compilation (including runtime assembler), type declarations that lead to optimizations in generated code, SBCL compiler can use declared types for compile-time type checks, read/compiler macros, extremely easy interface to C (JNI is a pain in the ass), multi-paradigm and doesn't prematurely optimize like Clojure (I have no need for STM or immutable data structures in 99% of the things I do), very powerful and flexible debugger, CLOS, more sophisticated interactive development. Clojure is a no-go for me primarily because it's tied to the JVM (or worse, Javascript) and the Java ecosystem but also because it prematurely optimizes with the sort of decisions it has made in the design space (immutability, STM, crippled reader, not Lispy-enough debugging and so on). Common Lisp is much more flexible in the sort of problems it allows you to explore and attack. Even the special features of Clojure (STM, immutable data structures) can be used in Common Lisp via existing libraries. Finally, for me Lisp == Lisp Machines and Clojure is a big step back in that regard (and not really modern at all) since it de-emphasizes (by lacking things that Common Lisp has) the interactivity that made Genera so iconoclastic and powerful.

peatmoss 8y ago
I do like Clojure for some of its opinions (immutable by default, strong encouragement of functional programming, convenient abstractions for collections, tasteful syntactic sugar). But, I too am not necessarily a huge fan of the ecosystems that Clojure is presently tied to. I'd love to see an SBCL implementation of Clojure or (especially) an LLVM based Clojure. I'm grateful when Clojure offers me an out from writing Java, but I also feel like I need to understand both the Java and the Clojure. The Rackjure dialect of Racket is pretty nice by my estimation (adds some of the conveniences of Clojure, isn't tied to / the beneficiary of an ecosystem like the JVM or Javascript). But I suspect it would frustrate people who like aspects of the CL ecosystem like long-lived system images, and a very neutral disposition toward immutability and functional programming.
- FPGAhacker 8y ago
  Clojure isn’t really worth anything without the jvm/js ecosystem. It’s a glue language for assembling components, most of which are written in Java. Timothy Baldridge wrote a python based language heavily inspired by clojure called Pixie. That gives a feel for what clojure is like without the ecosystem. Basically it means reinventing many many wheels.
  - peatmoss 8y ago
    I don’t know—there are certainly some interesting / different things in Clojure as compared to other lisps. Even if you can technically do much of what Clojure can do in other lisps, idiomatic Clojure has a feeling that is distinct from CL, Scheme, or even Racket. If Clojure offers nothing without the large JVM/JS ecosystems, then we could say the same about most languages (that aren't the size of Java/JS). If it’s that the distinct cocktail of features and ideas in the language aren’t worth anything, then I’d respectfully disagree. But at that point we’d simply be arguing aesthetic preferences.
    - kamaal 8y ago
      Well that's the problem isn't it. Any new language today has little to compete with existing languages in terms language features, the competition is in terms or the library ecosystems, online help and overall ecosystem. That takes time and money to build. Given how large the Java ecosystem is, and what it took in terms of money and time to go there is not easy or even possible to match in any relative comparison. So it makes sense to make sacrifices(if needed) to re use all that Java work that has been done and has been going on over the years. Clojure is the best thing that has happened to Lisp in years.

justinhj 8y ago

Common Lisp has the advantage of being much more stable in terms of language changes. You can pretty much take CL code from the last two decades and run it. It's also got a better native compilation story. I like Clojure for bringing maps and vectors into first class language constructs with simple syntax and the fact that it runs on the JVM means I have access to the entire Java ecosystem of libraries and tools.

lispm 8y ago
I wonder where the vector myth comes from. Common Lisp always had a vector data type and syntax for it. Just not [], but #(). Actually Common Lisp has multi-dimensional arrays, bitvectors, ... Vector: CL-USER 102 > (map 'vector #'char-code "foobar") #(102 111 111 98 97 114) CL-USER 103 > (reduce #'+ #(102 111 111 98 97 114)) 633 Bitvector: CL-USER 105 > (reduce #'+ #*10101001010101) 7 2d-Array CL-USER 106 > (aref #2a((1 2) (3 4)) 1 1) 4
- justinhj 8y ago
  I didn't say CL has no vectors or syntax, just that in Clojure using sets, maps and vectors, is much more similar to using lists than it is in CL.
  - lispm 8y ago
    Common Lisp reads and writes vectors, has a simple syntax for them and provides a sequence abstraction over lists and vectors.
    - justinhj 8y ago
      Operations that in Clojure require only changing the kind of brackets, in Common Lisp are more verbose and explicit. If you don’t see the clean syntax and simple utility in that then fair enough, but I do.
      - lispm 8y ago

didibus 8y ago

I'd say pros: - Compiles to native - Superior REPL experience/interactivity - Easier C FFI I'd say cons: - Smaller ecosystem, not as many libraries. - Dated tooling. - Inferior support for multi-threading/multi-core. - Not as homoiconic. Only lists are by default. - Standard is abandoned. No new versions since 1994. Some CDRs till 2013. Neutral: - Leans towards OOP and imperative mutability over Functional and immutable. - Doesn't have unified abstractions over datastructures.

IronBacon 8y ago
I would add "- Better stack traces" to the pros.
lispm 8y ago
Common Lisp compiles to much more than just 'native'. Like C, LLVM, DLLs, ... and a has a bunch of exotic stuff like whole-program-to-C compilers, Common Lisp on the metal or Common Lisp on top of Prolog https://github.com/TeamSPoon/wam_common_lisp https://github.com/TeamSPoon/wam_common_lisp . Common Lisp also has full language interpreters: these are implementations of Common Lisp which interpret s-expression level code - not byte code. Common Lisp can easily dump images and make them executable. Saving and starting them is quick. Common Lisp has implementations mostly written in Common Lisp - including the compiler and large parts of the runtime.
- vram22 8y ago
  Is this point of your parent commenter right? > - Not as homoiconic. Only lists are by default.
  - lispm 8y ago
    I read that, too. But I'm not sure what he means by 'Only lists are by default'. If he means that only lists have a literal representation, then it would be slightly wrong - since Common Lisp has literal representations for various numbers, symbols, characters, strings, vectors, arrays, structures, pathnames, ... Plus the s-expression syntax is user-extensible - making it as 'homoiconic' as the user needs it.

nextos 8y ago

I love Common Lisp (and I miss its frequent discussions on HN a decade ago). That trend seems to be resurfacing now. The main advantage of Common Lisp is standardization. There's very few languages that can run old code across so many platforms and implementations. But that also holds the language back a bit in terms of progress. Libraries feel like they have been falling a bit behind. It's also one of the few practical languages that has a great multi-paradigm support. The main advantage of Clojure is implementing lots of modern functional programming ideas. It's main disadvantage is being excessively tied to the JVM. That allowed initial rapid growth, but it brings some side-effects such as ugly stack traces. Aside from JavaScript, there are no alternative platforms. Racket will now run on top of Chez Scheme. That's another major Lisp worth considering. Lastly, Julia shows some of the multiple dispatch ideas in CLOS can lead to really efficient code generation when paired with LLVM or a similar backend. I wish someone put all these interesting ideas in a blender and implemented them on top of Common Lisp, or as a new language. Something functional, with great typing (like Shen), static analysis and an LLVM-like backend are really worth pursuing. We need better languages to address modern challenges, like merging symbolic and probabilistic AI.

patrec 8y ago

Common Lisp advantages: - "more interactive" resumable exceptions, better code reloading functionality - multiple values (cumbersome to use for superficial reasons, but with much better semantics than in e.g. scheme, for sure and probably also Lua) - compiler macros - readtable macros (although the design leaves to be desired) - more sophisticated pretty printer - more "target platforms"; with clojure it's basically jvm or, to a lesser extent, JS. If you dislike both you're out of luck - there's a treasure trove of old but interesting material that uses Common Lisp (like PAIP by Norvig) - much nicer for writing highly imperative code Common Lisp disadvantages: - Common Lisp has no eco system to speak off (but at least there's less churn than in clojure land) - the language is frozen/dead - career suicide, even compared to clojure - no high quality free implementations (for example sbcl has a rather poor garbage collector compared to java, go and other widely used languages) - single precision is de-facto the default floating point type - built around cons cells which are a terrible data structure: slow, cumbersome and brittle; there's OK support for vectors and slightly worse support for multidimensional arrays and hash-tables and very poor support for generic collection manipulation or efficient functional data structures - no out of the box support for laziness - no concurrency or parallelism abstractions - no good standard pattern matching library - brain drain: very few smart people doing interesting things left (most left by the 90ies) - often feels plodding and cumbersome compared to clojure (destructuring, basic string or sequence operations)

sedachv 8y ago
You have a lot of very wrong opinions on Common Lisp. > multiple values (cumbersome to use for superficial reasons How so? > Common Lisp has no eco system to speak off False. https://www.quicklisp.org/beta/ https://www.quicklisp.org/beta/ https://cliki.net/ https://cliki.net/ > the language is frozen/dead False. Extensions are being done through libraries and in the implementations. > career suicide, even compared to clojure I only ever get positive attention for having been a professional Common Lisp (and Scheme) programmer. Never had trouble finding freelance or full-time work. > no high quality free implementations (for example sbcl has a rather poor garbage collector compared to java, go and other widely used languages) How do you go from "SBCL's GC is slower than Java's" (which is a nonsensical statement, because different JVMs have different GCs), to "no high-quality free implementations?" There are three Free Software ones to choose from: SBCL, CCL, and ECL. > single precision is de-facto the default floating point type False. Where do you even pick up a ridiculous idea like that? http://www.lispworks.com/documentation/HyperSpec/Body/t_short_.htm http://www.lispworks.com/documentation/HyperSpec/Body/t_shor... > built around cons cells which are a terrible data structure Ignoring how dumb labeling the linked list a "terrible data structure" is, you do realize that data structures are something that you implement in a language, not something that you have to build into one? There are libraries for all kinds of data structures. > no out of the box support for laziness There is no reason to make it built in at the language level when you have closures. > no concurrency or parallelism abstractions That is handled by implementations and libraries. > no good standard pattern matching library Just a bunch of really great ones. > brain drain: very few smart people doing interesting things left (most left by the 90ies) You don't seem to know anything or anyone from the Common Lisp world. The best techniques for using the language (advanced use of closures, read macros, the condition system, and applications to domain-specific languages and transpilation) have only started coming out in the past 15 years, from people like Edi Weitz, Doug Hoyte, and Tobias Rittweiler. The only thing relevant from the 1990s is Paul Graham's On Lisp. Norvig's PAIP is very overrated.

kamaal 8y ago

One thing I tend to miss in Clojure is lack of TCO. Most people(like me), come to Lisp from SICP, The Little Schemer and PG's books. Where recursion is not just emphasized, you are actually trained to think recursively. I found lack of TCO to be a little like a stick in the neck when it comes to both Clojure and Emacs Lisp. It prevents you from thinking in the way you have been thinking in other Lisps. I understand Clojure depends on JVM and JVM doesn't do tail call eliminations yet, and Rich Hickey is right in thinking that method calls are too much a platform thing and we shouldn't be working around this limitation with a hack. However lack of TCO in Emacs Lisp is a little not easy to live with. From what I understand patches have been submitted to Emacs to make this happen but haven't made it to the upstream. TCO is very important for any language that sells functional programming these days. Apart from the performance advantages, Recursion is a thought framework. Limitations are not easy to live with. I hope some day Clojure and Emacs Lisp get TCO. On a tangential note, JVM is a great platform, its a also a widely used platform, so changes are going to come in very slowly. So I'm not holding my breath waiting for TCO.

lispm 8y ago
Most mainline Lisps either never did support TCO or only in some restricted way. The reason for that is that it clashes with other widely used language features in typical Lisps. There is a cost to supporting TCO - also a less nice debugging experience. Many CL compilers tend to support it with some restrictions - CL interpreters often not. Lisp Machines did not support it. CL on the JVM does not support it. https://0branch.com/notes/tco-cl.html https://0branch.com/notes/tco-cl.html I started with Scheme and Lisp (Standard Lisp, ZetaLisp, CL, ...) and wrote/used TCO a lot. I tend to view the use of TCO for basic iteration as a mistake, which makes code harder to read. I tend to like either higher-order iterative constructs or powerful iteration constructs like CL's ITERATE: https://common-lisp.net/project/iterate/ https://common-lisp.net/project/iterate/ I find the Clojure hack ugly.
- kamaal 8y ago
  >>I tend to view the use of TCO for basic iteration as a mistake, which makes code harder to read. I understand some one like you is far more experienced and has been around for a long time. So obviously you know better than I ever will. And you are right. Even with very minimal Lisp exposure, after using Scheme and Common Lisp, Clojure's TCO thing feels unacceptable. In fact after using Common Lisp, and I'm a novice, even some one like me feels Common Lisp to be a far superior language compared to other Lisps around. The issue is, like I said, I started learning lisp starting with Scheme, and I started recently. First book was SICP, second was 'The Little Schemer', third was 'The Seasoned Schemer'. At that point your brain is hard programmed to think in terms of recursion, and whenever I see loops my mind moves to recursion automatically. You have to trust me when I say this, when I read PG's ANSI Common Lisp book , I skipped the sections on iterations and loops, because I thought I would never use them anyway. I have to say those Schemer books do their job really well. May be I just need more practice, so I will develop more stuff in Clojure, now that its not even possible to do that Clojure, eventually that TCO addiction should go away. :)