Eclipse Common Lisp(github.com)
github.com
Eclipse Common Lisp
https://github.com/blakemcbride/eclipse-lisp
6 comments
Here is the original Eclipse release announcement from almost 19 years ago: https://groups.google.com/forum/#!search/eclipse$20common$20...
I'd like to hear the story how it turned up on github. This is a pretty good lisp from 1998 which compiles to C.
I know Elwood from my former background in the automotive industry, and I read they also created and produced a successful micro computer, the Mini Micro III.
I know Elwood from my former background in the automotive industry, and I read they also created and produced a successful micro computer, the Mini Micro III.
Pretty cool seeing yet another CL implementation popping up from the past. In my opinion its absolutely essential for a programming language to have as many implementations as possible. Its really the only way to truly put the language standard to test.
I see Clojure described as a Lisp.
What advantage would I gain learning Commons Lisp over Clojure? Clojure seems to be fairly well respected, has tooling and libraries available. I have no real idea about the situation for Common Lisp
What advantage would I gain learning Commons Lisp over Clojure? Clojure seems to be fairly well respected, has tooling and libraries available. I have no real idea about the situation for Common Lisp
> What advantage would I gain learning Commons Lisp over Clojure?
You'd get to learn a standardized language with good support on many platforms (including the JVM, see ABCL) that has stood the test of time very well. I'd argue you'd get a bigger picture of the Lisp world than Clojure can offer, which is rather a specialized offshoot that breaks with many traditions.
Common Lisp is also a rather nonopinionated, it supports almost all programming styles out of the box, and new paradigms can be implemented on top gracefully. It doesn't push you into one way of doing a certain thing, unlike Clojure which has some strong preferences.
Clojure will bring you an opinionated concept of parallelism/concurrency, and a standard library geared very specifically to its conceptual design. Some problems will already be solved for you, but in turn you miss out on many Lisp-ism that didn't make it into Clojure.
I'd imagine Common Lisp is fairly well respected, too. :) I have always considered it the mother of all programming languages since 1990. From my experience (1 year ago) CL tooling is much better established than Clojure tooling. CL has tons of libraries available through Quicklisp. The quality of libraries is generally very high, but I can not really compare it to the Clojure landscape.
You'd get to learn a standardized language with good support on many platforms (including the JVM, see ABCL) that has stood the test of time very well. I'd argue you'd get a bigger picture of the Lisp world than Clojure can offer, which is rather a specialized offshoot that breaks with many traditions.
Common Lisp is also a rather nonopinionated, it supports almost all programming styles out of the box, and new paradigms can be implemented on top gracefully. It doesn't push you into one way of doing a certain thing, unlike Clojure which has some strong preferences.
Clojure will bring you an opinionated concept of parallelism/concurrency, and a standard library geared very specifically to its conceptual design. Some problems will already be solved for you, but in turn you miss out on many Lisp-ism that didn't make it into Clojure.
I'd imagine Common Lisp is fairly well respected, too. :) I have always considered it the mother of all programming languages since 1990. From my experience (1 year ago) CL tooling is much better established than Clojure tooling. CL has tons of libraries available through Quicklisp. The quality of libraries is generally very high, but I can not really compare it to the Clojure landscape.
SLIME is awesome. There's nothing like it really (Lighttable maybe? Haven't used it). No dependency on Java, compile straight to machine code. The language features like CLOS, conditions and so on give you a lot of flexibility. I found some of the libs not to be as robust as I hoped, but since you can monkey-patch everything it's not much of a problem.