6 ms·

I wonder why Clojurescript succeeded where Common Lisp hasn’t: compiling a lisp to javascript. Is Common Lisp particularly tricky in some way that Clojure isn’t

I wonder why Clojurescript succeeded where Common Lisp hasn’t: compiling a lisp to javascript. Is Common Lisp particularly tricky in some way that Clojure isn’t?

patrec 7y ago
a) Common lisp was already in undead state when Javascript became big. Semi-dead languages as a rule have worse tooling for "new" stuff. b) Clojure didn't really fully succeed, there were annoying differences between Clojure and Clojurescript last time I looked. There are compilers for incomplete subsets of CL to JS as well, although presumably much worse ones. c) There's some stuff in Common Lisp that's quite hard to do efficiently on top of most existing language runtimes. For example resumable exceptions and lua/CL-style optional multiple return values. In assembler or without concern for efficiency the last one is trivial, otherwise, not so much. d) Clojurescript could bootstrap existing fancy JVM platform stuff (closure compiler) to do quite a lot of heavy lifting.
- wtetzner 7y ago
  Related to a), Clojure is just more popular than CL, and has a lot of momentum pushing it into the browser.
- nextos 7y ago
  I like Clojure, but sometimes I dislike it's so heavily tied to the JVM and/or purely functional. I think a modern multiparadigm Lisp on LLVM would be great. Perhaps that's Julia, though.
- aidenn0 7y ago
  B & C are good points, but... A) Writing a new Common Lisp implementation is a major undertaking, but a new implementation was creates specifically for C++ interop[1], and that implementation is certainly post javascript being big. D) Anything targeting JS can run the output through closure; I've done so with Parenscript, for example. 1: https://github.com/clasp-developers/clasp https://github.com/clasp-developers/clasp
  - patrec 7y ago
    A) I'm well aware of clasp, and its a cool project (and post javascript, as well) but it's hardly anywhere near production quality right now (unlike say, clojurescript). So I don't think it's a counters my argument about the CL ecosystem (I'm sceptical that it would make much of a dent even if it becomes a technical success beyond Dr Meister's wildest dreams). D) Of course, but if you require some additional JVM based tooling for a JVM language like clojure, you lose 0% of your potential audience and introduce no additional friction, which is not at all the case for CL (nor would it be for, say C++ or Lua).
gowld 7y ago
Clojure is far more popular than Common Lisp, and it attracts people who like Lisp and interopability, not just Lisp, so its ecosystem is more developed.
- lispm 7y ago
  Common Lisp traditionally favors other forms of interoperability: with Assembler, C, C++, Objective-C, UNIX/POSIX, etc... For example one prefers to directly call old-fashioned GTK+, Cocoa or Windows - instead of calling via a Java UI layer or a Javascript library. Common Lisp has interoperability with the JVM in various forms (from FFIs to ABCL, a Common Lisp on JVM implementation), but it's not a popular choice. There are several CL implementations with deep C integration, for example by compilation to C. CLASP has deep C++ and LLVM integration. Some implementation can create shared libraries which are being loaded from other programs. CLASP: https://www.youtube.com/watch?v=8X69_42Mj-g https://www.youtube.com/watch?v=8X69_42Mj-g It's possible to bring Common Lisp on top of runtimes like the JVM or Javascript - but there is some larger mismatch, because Common Lisp (different from Clojure) a platform independent full programming language. For example Common Lisp specifies a numeric tower with bignums, some float types, complex numbers and rational numbers. JavaScript internally does only offer floats. Common Lisp also specifies its own object system, which does not map well on top of the JVM (single inheritance, non-dynamic) or JavaScript.
aidenn0 7y ago
Clojure is unique in that its definition is contingent upon a host VM (CLR, JVM originally, JS as well now). It's not hard to come up with code that will work in clojurescript but not Clojure/clr or clojure/jvm. For client-side I tend to use Parenscript[1] which doesn't particularly try too hard to look like Common Lisp, but does allow for macros to be written in Common Lisp. Since it's not trying too hard to look like Common Lisp, javascript interop is dead-simple, but since the metaprogramming is in Common Lisp, I find it to be a good middle-ground. [edit] If it's not clear, parenscript has design requirements that make it unable to ever be a full common-lisp on its own; the desire is that you could emit a webpage where e.g. the onclick property is generated from parenscript, and it will work, without any other javascript libraries being loaded. This obviously means you, e.g. can't have a lisp numeric tower available. 1: https://common-lisp.net/project/parenscript/ https://common-lisp.net/project/parenscript/
- deleted 7y ago
  [deleted]
kazinator 7y ago
I'm aware of CL-like lisps that compile to JavaScript which are likewise incomplete and incompatible. Oh look, a comment in this submission Github's item points to JSCL, for example.

I wonder why Clojurescript succeeded where Common Lisp hasn’t: compiling a lisp to javascript. Is Common Lisp particularly tricky in some way that Clojure isn’t?

patrec 7y ago

a) Common lisp was already in undead state when Javascript became big. Semi-dead languages as a rule have worse tooling for "new" stuff. b) Clojure didn't really fully succeed, there were annoying differences between Clojure and Clojurescript last time I looked. There are compilers for incomplete subsets of CL to JS as well, although presumably much worse ones. c) There's some stuff in Common Lisp that's quite hard to do efficiently on top of most existing language runtimes. For example resumable exceptions and lua/CL-style optional multiple return values. In assembler or without concern for efficiency the last one is trivial, otherwise, not so much. d) Clojurescript could bootstrap existing fancy JVM platform stuff (closure compiler) to do quite a lot of heavy lifting.

wtetzner 7y ago
Related to a), Clojure is just more popular than CL, and has a lot of momentum pushing it into the browser.
nextos 7y ago
I like Clojure, but sometimes I dislike it's so heavily tied to the JVM and/or purely functional. I think a modern multiparadigm Lisp on LLVM would be great. Perhaps that's Julia, though.
aidenn0 7y ago
B & C are good points, but... A) Writing a new Common Lisp implementation is a major undertaking, but a new implementation was creates specifically for C++ interop[1], and that implementation is certainly post javascript being big. D) Anything targeting JS can run the output through closure; I've done so with Parenscript, for example. 1: https://github.com/clasp-developers/clasp https://github.com/clasp-developers/clasp
- patrec 7y ago
  A) I'm well aware of clasp, and its a cool project (and post javascript, as well) but it's hardly anywhere near production quality right now (unlike say, clojurescript). So I don't think it's a counters my argument about the CL ecosystem (I'm sceptical that it would make much of a dent even if it becomes a technical success beyond Dr Meister's wildest dreams). D) Of course, but if you require some additional JVM based tooling for a JVM language like clojure, you lose 0% of your potential audience and introduce no additional friction, which is not at all the case for CL (nor would it be for, say C++ or Lua).

gowld 7y ago

Clojure is far more popular than Common Lisp, and it attracts people who like Lisp and interopability, not just Lisp, so its ecosystem is more developed.

lispm 7y ago
Common Lisp traditionally favors other forms of interoperability: with Assembler, C, C++, Objective-C, UNIX/POSIX, etc... For example one prefers to directly call old-fashioned GTK+, Cocoa or Windows - instead of calling via a Java UI layer or a Javascript library. Common Lisp has interoperability with the JVM in various forms (from FFIs to ABCL, a Common Lisp on JVM implementation), but it's not a popular choice. There are several CL implementations with deep C integration, for example by compilation to C. CLASP has deep C++ and LLVM integration. Some implementation can create shared libraries which are being loaded from other programs. CLASP: https://www.youtube.com/watch?v=8X69_42Mj-g https://www.youtube.com/watch?v=8X69_42Mj-g It's possible to bring Common Lisp on top of runtimes like the JVM or Javascript - but there is some larger mismatch, because Common Lisp (different from Clojure) a platform independent full programming language. For example Common Lisp specifies a numeric tower with bignums, some float types, complex numbers and rational numbers. JavaScript internally does only offer floats. Common Lisp also specifies its own object system, which does not map well on top of the JVM (single inheritance, non-dynamic) or JavaScript.

aidenn0 7y ago

Clojure is unique in that its definition is contingent upon a host VM (CLR, JVM originally, JS as well now). It's not hard to come up with code that will work in clojurescript but not Clojure/clr or clojure/jvm. For client-side I tend to use Parenscript[1] which doesn't particularly try too hard to look like Common Lisp, but does allow for macros to be written in Common Lisp. Since it's not trying too hard to look like Common Lisp, javascript interop is dead-simple, but since the metaprogramming is in Common Lisp, I find it to be a good middle-ground. [edit] If it's not clear, parenscript has design requirements that make it unable to ever be a full common-lisp on its own; the desire is that you could emit a webpage where e.g. the onclick property is generated from parenscript, and it will work, without any other javascript libraries being loaded. This obviously means you, e.g. can't have a lisp numeric tower available. 1: https://common-lisp.net/project/parenscript/ https://common-lisp.net/project/parenscript/

deleted 7y ago
[deleted]

kazinator 7y ago

I'm aware of CL-like lisps that compile to JavaScript which are likewise incomplete and incompatible. Oh look, a comment in this submission Github's item points to JSCL, for example.