Earlier quoted context omitted.
Yes, they are _completely_ different languages, despite being lisps.
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.
Common Lisp Koans
11–20 of 24 posts
Re: Common Lisp Koans
#12I'm surprised to see that this is on Google's Github page. Do they have any projects (besides this) that use Common Lisp?
Re: Common Lisp Koans
#13Is there any reason today to study Common Lisp instead of a more popular and evolving Lisp, like Clojure or Racket?
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 Transactional memory? http://stmx.org/ ClojureScript? 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 o…
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.
Re: Common Lisp Koans
#14Is there any reason today to study Common Lisp instead of a more popular and evolving Lisp, like Clojure or Racket?
Re: Common Lisp Koans
#15Earlier quoted context omitted.
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 Transactional memory? http://stmx.org/ ClojureScript? 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 o…
> 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 framewor…
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.
Re: Common Lisp Koans
#16Is there any reason today to study Common Lisp instead of a more popular and evolving Lisp, like Clojure or Racket?
Re: Common Lisp Koans
#17Is there any reason today to study Common Lisp instead of a more popular and evolving Lisp, like Clojure or Racket?
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.
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.
Re: Common Lisp Koans
#18Earlier quoted context omitted.
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 Transactional memory? http://stmx.org/ ClojureScript? 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 o…
> 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 framewor…
Yes, this approach is not the best approach to getting mass adoption, and there are benefits to mass adoption — people can help you, there's a bigger pool of people to hire, etc (I think its much more important to companies than individuals). But mass adoption isn't always the goal. I suppose you can consider Ruby analogous to Ubuntu while common lisp is like a *bsd distribution (or arch, gentoo, slack...). Ubuntu is great, all Ubuntu installations start from the same starting point, and the potential for customization is limited (try changing Ubuntu's init system), so you can just ask a question on stack overflow and get an answer with instructions specific to how your system works. And companies are more likely to pick Ubuntu than gentoo, because its better supported and supposedly more stable. That doesn't mean that people consider the distributions where the user can pick and choose exactly what their system does (like a common lisp programmer does by picking out libraries of macros) to be any worse of a distribution. Quite the contrary, the mythos seems to consider these distributions better in some way, like they're a better tool for a more skilled practitioner, a sentiment which has also found its place around common lisp.
Re: Common Lisp Koans
#19Earlier quoted context omitted.
> 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 framewor…
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.
Re: Common Lisp Koans
#20Earlier quoted context omitted.
> 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 framewor…
The whole point of common lisp, the reason it has survived since the beginning of time, is that the language was designed so that language innovation happened by people developing libraries for it. Complaining that common lisp hasn't evolved is like complaining that free-software posix systems haven't evolved. True, the posix standard hasn't evolved much, but its not meant to, it's meant to be evolved by the userspac…
And that "whole point" hasn't worked very well as to the availability of a rich library ecosystem and/or adoption. So, while it's a nice trait to have, it's perhaps too much of a burden.
>But mass adoption isn't always the goal.
True, but it's not like CL was designed like some researchy or experimental project that doesn't care about mass adoption.