For me the most important difference is Lisp-1 vs Lisp-2. I had tried my hand at Common Lisp a couple of times before trying Scheme. The latter immediately felt "cleaner" than CL.
My favourite implementation is Gambit Scheme and I have currently stumbled upon Gerbil (cons.io), a dialect built on top of Gambit. It's just fun to work with.
I am surprised by how many times the first hit of my google query is a stackoverflow answer which has been closed due to being “off topic”, “not constructive” or whatever. I’m not sure how they benefit by being so active with their topic policing.
I agree, but it should also describe what Scheme continuations are, compared to the delimited function object continuations that are used in practice elsewhere.
However, the notion is technically subsumed within the notion of a "simplified" language, as Scheme continuations are a low level operation quite often used to construct what other languages have out of the box.
Probably nobody had the time or knowledge to list all the features of the various important Scheme implementations, find the important ones and find out whether they exist in one of the various CL implementation or the 2..3 Clojure implementations.
I'm not surprised that the answers were not useful.
I was learning Clojure and OCaml last week (again) after doing a survey of a handful of functional languages. I still haven't seen a good way to spin up a really simple HTTP server like Sinatra or Express. Ones I did see either had a huge bug, were more verbose, or had no "getting started" documentation. The languages themselves are fun though.
And that's the problem. By picking these languages you're committing to building a lot of stuff yourself. Sure, I'd rather be writing anything other than JavaScript but you can't deny the Node ecosystem has solved a lot of problems.
It's not really a problem for Clojure since it is on the JVM, so you get all of those libraries for free. Java interop is very easy, especially due to macros.
I've never used Clojurescript. I'm not sure how easy that is with Node.
OCaml is rough, but Clojure has quite a few nice libraries for getting up and running with a simple HTTP server - Ring is fairly simple and there are libraries and frameworks that build on top of it. Was there something in particular you found missing or struggled with?
Compojure - https://github.com/weavejester/compojure#usage is a very close equivalent of Sinatra. Ring (which most, if not all web libraries build on top of) is directly inspired by Ruby's Rack (I think Python and Node have a very similar, middleware oriented design).
My impresson is that the language differences are actually minor, but that differences between platforms and runtimes matter.
Clojure supports concurrency very well, and being hosted n the JVM, it is somewhat tailored to web applications. My impression is that it is far less ideal for CPU-bound parallelism which does a lot of computation on primitive types, since when there are more than a few primitive function parameters, they need to be passed as boxed values, which interacts badly with the JIT compiler. In practice, the advantages from support for parallel computation seem to be out-weighted by that. Of course, for concurrent web applications, this does usually not matter.
In contrast, Lisp implementations like SBCL or Chez compile to native code, and they can be as fast as C.
Racket and SBCL are far better for scripting because they have a fast start-up time.
Clojure and Racket have the best Library support which matches the "Batteries included" slogan of Python to some degree. Clojure can access and use all Libraries on the Java platform. In contrast, Racket, SBCL and many other Lisps can access libraries written in C quite easily using the foreign function interface, which is important for numeric and scientific programming. For the latter domain, using the JVM is somewhat a disadvantage.
Racket can also execute Python code (a subset, I think) and call into Python libraries. According to the documentation, it can also call into Python extension modules. If this is correct, the difference in the number of libraries available to Clojure should matter little.
SBCL has less libraries. So far, I was thinking of SBCL as being powerful but a bit bare-bones, similar to C++ when compared to Java. However, one of the comments on stackoverflow mentions that the library situation has changed significantly in the last years.
I am also wondering whether the library aspect might be less important that it seems. Traditional OOP languages put a lot of focus on code reuse in the form of binary code reuse - including libraries which provide objects which can do a lot of things. Java libraries are a prima example for this, and are famous for their heaviness. Lisps, in contrast, and Lisp culture, seem to put more focus on source-code reuse, because they put more emphasis on functional programming. This seems to make binary code reuse somewhat less important.
18 comments
[ 3.2 ms ] story [ 46.5 ms ] threadMy favourite implementation is Gambit Scheme and I have currently stumbled upon Gerbil (cons.io), a dialect built on top of Gambit. It's just fun to work with.
> I always get confused about which post should go where.
There should be a stack Overflow site, not a faq but site, to discuss which stack Overflow sites are appropriate for a particular post.
although all the interesting and useful questions posted to that site would be flagged as inappropriate for that site.
However, the notion is technically subsumed within the notion of a "simplified" language, as Scheme continuations are a low level operation quite often used to construct what other languages have out of the box.
I'm not surprised that the answers were not useful.
I've never used Clojurescript. I'm not sure how easy that is with Node.
Clojure supports concurrency very well, and being hosted n the JVM, it is somewhat tailored to web applications. My impression is that it is far less ideal for CPU-bound parallelism which does a lot of computation on primitive types, since when there are more than a few primitive function parameters, they need to be passed as boxed values, which interacts badly with the JIT compiler. In practice, the advantages from support for parallel computation seem to be out-weighted by that. Of course, for concurrent web applications, this does usually not matter.
In contrast, Lisp implementations like SBCL or Chez compile to native code, and they can be as fast as C.
Racket and SBCL are far better for scripting because they have a fast start-up time.
Clojure and Racket have the best Library support which matches the "Batteries included" slogan of Python to some degree. Clojure can access and use all Libraries on the Java platform. In contrast, Racket, SBCL and many other Lisps can access libraries written in C quite easily using the foreign function interface, which is important for numeric and scientific programming. For the latter domain, using the JVM is somewhat a disadvantage.
Racket can also execute Python code (a subset, I think) and call into Python libraries. According to the documentation, it can also call into Python extension modules. If this is correct, the difference in the number of libraries available to Clojure should matter little.
SBCL has less libraries. So far, I was thinking of SBCL as being powerful but a bit bare-bones, similar to C++ when compared to Java. However, one of the comments on stackoverflow mentions that the library situation has changed significantly in the last years.
I am also wondering whether the library aspect might be less important that it seems. Traditional OOP languages put a lot of focus on code reuse in the form of binary code reuse - including libraries which provide objects which can do a lot of things. Java libraries are a prima example for this, and are famous for their heaviness. Lisps, in contrast, and Lisp culture, seem to put more focus on source-code reuse, because they put more emphasis on functional programming. This seems to make binary code reuse somewhat less important.
Quicklisp[1] has made a massive difference to how easy it is to download and manage sets of dependencies in a Lisp project. Try it out :)
[1] https://www.quicklisp.org/beta/