4 ms·

Is there any reason today to study Common Lisp instead of a more popular and evolving Lisp, like Clojure or Racket?

by sdfin 11y ago

mapcars 11y ago
Yes, they are _completely_ different languages, despite being lisps.
- sdfin 11y ago
  Thanks. Any suggestion about with which one to start? I don't believe that I'd use them for work or for many personal projects, but I've read about the advantages of learning FP. So I'd like to learn something that teaches me to think about programming in a different way and be able to apply those insights into the code I write in Java or other procedural or OO languages used at work.
  - mapcars 11y ago
    OCaml, Haskell and friends will give you best FP insights. Common Lisp is far beyond these categories =)
  - yenda 11y ago
    Clojure is definitely a perfect fit for you then, you can even interop with your Java code.
mapcars 11y ago
btw, your question assumes that Common Lisp is not evolving. This is not correct at all. Which improvements Clojure evolving consists of? Transducers? Cl got them too: https://github.com/aamedina/transducers https://github.com/aamedina/transducers Transactional memory? http://stmx.org/ http://stmx.org/ ClojureScript? http://davazp.net/jscl/jscl.html http://davazp.net/jscl/jscl.html These are only infrastructure things, Common Lisp has language features which are just impossible in Clojure while it based on JVM.
- coldtea 11y ago
  >btw, your question assumes that Common Lisp is not evolving. This is not correct at all. Which improvements Clojure evolving consists of? Traction for one. >Transducers? Cl got them too Pointing to some random libs that implement the same concept doesn't mean it's part of a languages culture/ecosystem/common practice as transducers are to closure. E.g. I could say "Rails? Well, language X has a rails like framework too", but that wouldn't mean you get the same benefits of using that framework over rails, when you include language adoption, community vibrancy, availability of programmers to hire, tooling, books, etc.
  - mapcars 11y ago
    They should not be a part of language, what for? Everything else you mentioned is about community only, and doesn't apply directly to the language. E.g. if you have a good language without a community, community can eventually grow, but you can use the language anyway. If you have a bad language with great community - it doesn't reduce your suffering from the language itself.
    - catnaroek 11y ago
      Agreed. Clojure isn't overall a bad language, but it has annoying quirks in a lot of places, presumably because it needs to be compatible with Java. The ones that annoy me the most are (0) `nil` and `false` being different, and (1) wonky arithmetic that uses Java's numeric types under the hood, unless you explicitly ask it not to.
    - coldtea 11y ago
      >E.g. if you have a good language without a community, community can eventually grow, but you can use the language anyway. If you have a bad language with great community - it doesn't reduce your suffering from the language itself. My experience has been the inverse. I'd rather use a bad, or usually mediocre language WITH community, tooling, libs, books, programmers etc, than a better one where I'll be burdened by the lack of all of these. So, in a sense, community tramps inherent language qualities. After all that's the very basic message from Lisp and Smalltalk.
catnaroek 11y ago
Racket is not Lisp, and I mean this as praise, not as an in "boo hoo, not Lisp, ergo bad". Racket's macro system, in particular `syntax-parse` and `define-syntax-class`, makes it a joy to extend the language. When you use a Racket macro wrong, you get an error message in terms of the abstraction the macro provides, not in terms of what the macro expander compiles it to, which is an implementation detail you have no business knowing or caring about. `defmacro` doesn't even begin to get close to the level of abstraction that Racket macros provide.
diogofranco 11y ago
One reason is that there are projects/situations where language stability can outweight the benefits of language evolution. While this isn't the coolest view out there, the fact the the ANSI standard didn't need to be revised since 2004 can actually be a feature, not a bug. For an extreme example of my point, look at the state of the front-end JavaScript frameworks in the last couple of years.
- catnaroek 11y ago
  > state of the front-end JavaScript frameworks There's evolution and there's running in circles. :-p Few languages really evolve fast in a meaningful sense. The only examples that come to my mind are Haskell, Racket and pre-1.0 Rust. And the first two are research languages. Breaking changes (e.g. Python 3) to get rid of accumulated cruft can be a good thing, but nevertheless stability is a feature.
Grue3 11y ago
1. It's suitable for object-oriented programming. Common Lisp Object System is insanely powerful. 2. Depending on the implementation it can be really fast. 3. Depending on the implementation, support for typing and type inference. +more. It's a much bigger language with a kitchen sink of features.
- yogthos 11y ago
  Note that Clojure also supports OO style with rotocols http://clojure.org/protocols http://clojure.org/protocols and multimethods http://clojure.org/multimethodsp http://clojure.org/multimethodsp in fact stuff like Om https://github.com/omcljs/om/wiki/Quick-Start-(om.next) https://github.com/omcljs/om/wiki/Quick-Start-(om.next) is fairly object oriented in nature. Clojure is also very fast thanks to running on the JVM and it supports type hinting. There's also core.typed for static typing support.

Is there any reason today to study Common Lisp instead of a more popular and evolving Lisp, like Clojure or Racket?

by sdfin 11y ago

Is there any reason today to study Common Lisp instead of a more popular and evolving Lisp, like Clojure or Racket?

mapcars 11y ago

Yes, they are _completely_ different languages, despite being lisps.

sdfin 11y ago
Thanks. Any suggestion about with which one to start? I don't believe that I'd use them for work or for many personal projects, but I've read about the advantages of learning FP. So I'd like to learn something that teaches me to think about programming in a different way and be able to apply those insights into the code I write in Java or other procedural or OO languages used at work.
- mapcars 11y ago
  OCaml, Haskell and friends will give you best FP insights. Common Lisp is far beyond these categories =)
- yenda 11y ago
  Clojure is definitely a perfect fit for you then, you can even interop with your Java code.

mapcars 11y ago

btw, your question assumes that Common Lisp is not evolving. This is not correct at all. Which improvements Clojure evolving consists of? Transducers? Cl got them too: https://github.com/aamedina/transducers https://github.com/aamedina/transducers Transactional memory? http://stmx.org/ http://stmx.org/ ClojureScript? http://davazp.net/jscl/jscl.html http://davazp.net/jscl/jscl.html These are only infrastructure things, Common Lisp has language features which are just impossible in Clojure while it based on JVM.

coldtea 11y ago
>btw, your question assumes that Common Lisp is not evolving. This is not correct at all. Which improvements Clojure evolving consists of? Traction for one. >Transducers? Cl got them too Pointing to some random libs that implement the same concept doesn't mean it's part of a languages culture/ecosystem/common practice as transducers are to closure. E.g. I could say "Rails? Well, language X has a rails like framework too", but that wouldn't mean you get the same benefits of using that framework over rails, when you include language adoption, community vibrancy, availability of programmers to hire, tooling, books, etc.
- mapcars 11y ago
  They should not be a part of language, what for? Everything else you mentioned is about community only, and doesn't apply directly to the language. E.g. if you have a good language without a community, community can eventually grow, but you can use the language anyway. If you have a bad language with great community - it doesn't reduce your suffering from the language itself.
  - catnaroek 11y ago
    Agreed. Clojure isn't overall a bad language, but it has annoying quirks in a lot of places, presumably because it needs to be compatible with Java. The ones that annoy me the most are (0) `nil` and `false` being different, and (1) wonky arithmetic that uses Java's numeric types under the hood, unless you explicitly ask it not to.
  - coldtea 11y ago
    >E.g. if you have a good language without a community, community can eventually grow, but you can use the language anyway. If you have a bad language with great community - it doesn't reduce your suffering from the language itself. My experience has been the inverse. I'd rather use a bad, or usually mediocre language WITH community, tooling, libs, books, programmers etc, than a better one where I'll be burdened by the lack of all of these. So, in a sense, community tramps inherent language qualities. After all that's the very basic message from Lisp and Smalltalk.

catnaroek 11y ago

Racket is not Lisp, and I mean this as praise, not as an in "boo hoo, not Lisp, ergo bad". Racket's macro system, in particular `syntax-parse` and `define-syntax-class`, makes it a joy to extend the language. When you use a Racket macro wrong, you get an error message in terms of the abstraction the macro provides, not in terms of what the macro expander compiles it to, which is an implementation detail you have no business knowing or caring about. `defmacro` doesn't even begin to get close to the level of abstraction that Racket macros provide.

diogofranco 11y ago

One reason is that there are projects/situations where language stability can outweight the benefits of language evolution. While this isn't the coolest view out there, the fact the the ANSI standard didn't need to be revised since 2004 can actually be a feature, not a bug. For an extreme example of my point, look at the state of the front-end JavaScript frameworks in the last couple of years.

catnaroek 11y ago
> state of the front-end JavaScript frameworks There's evolution and there's running in circles. :-p Few languages really evolve fast in a meaningful sense. The only examples that come to my mind are Haskell, Racket and pre-1.0 Rust. And the first two are research languages. Breaking changes (e.g. Python 3) to get rid of accumulated cruft can be a good thing, but nevertheless stability is a feature.

Grue3 11y ago

1. It's suitable for object-oriented programming. Common Lisp Object System is insanely powerful. 2. Depending on the implementation it can be really fast. 3. Depending on the implementation, support for typing and type inference. +more. It's a much bigger language with a kitchen sink of features.

yogthos 11y ago
Note that Clojure also supports OO style with rotocols http://clojure.org/protocols http://clojure.org/protocols and multimethods http://clojure.org/multimethodsp http://clojure.org/multimethodsp in fact stuff like Om https://github.com/omcljs/om/wiki/Quick-Start-(om.next) https://github.com/omcljs/om/wiki/Quick-Start-(om.next) is fairly object oriented in nature. Clojure is also very fast thanks to running on the JVM and it supports type hinting. There's also core.typed for static typing support.