ABCL is older, yes. I can't look up the dates now, but it started as an embedded interpreter for the J editor surely more than a decade ago, and even when it became a standalone project I think Clojure was still in Rich's head at best. That said, ABCL never had even .1% of the community Clojure has, which is a pity. ABCL is far from perfect, but with a solid open source community contributing to it, it could do everything Clojure does. Many of Clojure's core features are just a library away:
- immutable data structures -> FSet - concurrency primitives -> LParallel - STM -> CL-STM (I think) - ClojureScript -> Parenscript
etc. The only things that are still missing from ABCL proper are the ability to generate Java classes from Lisp and an easy to use ahead-of-time compiler (to produce libraries readily usable from Java and other languages). The ecosystem is missing more things, like Java IDE plugins and a Java/Maven savvy build tool (I'm sure ASDF could be hacked to become that tool). Clojure once didn't have those, too.
Besides ABCL, there are other Lisps for the JVM, most notably Kawa, a Scheme which has been existing for many years, it's older than ABCL I think.
I don't want to start a war either, and I'm sure Clojure benefits from its clean room design and implementation, but it's sad to see so many wheels reinvented, so much effort wasted.
On 4 July 2016 at 23:17, Alexandre Rademaker arademaker@gmail.com wrote:
I though that ABCL is older than Clojure , am I wrong ?!
One big frustration for me was the error handling ! Errors in Clojure are exposed as Java errors, we don't have the amazing CL handlers.
Alexandre Sent from my iPhone
On 4 de jul de 2016, at 17:07, Tom Emerson tremerson@gmail.com wrote:
On Sun, Jul 3, 2016 at 7:25 PM, David McClain dbm@refined-audiometrics.com wrote:
My impressions from a few years ago was that Clojure was another
language
built for the heck of it, much like Python. Not particularly well
designed[...]
Rich Hickey didn't create Clojure just for the heck of it: he had very specific goals in mind and, IMHO, put a lot of thought into the design of the language and the decisions he made given the design space (running within the overall JVM environment) and the warts he saw in other languages, within and without the Lisp family. There are numerous presentations available online where Rich talks about the development of Clojure: if you're interested I think they would show you that his design
under the control of one individual[...]
I'm not sure you can compare Python's BDfL with Rich's position with Clojure. I don't have a concrete example, but Clojure feels less bound-up in its creator's blinders than Python. That can also be a side-effect of its Lisp-nature though.
with lots of cheerleading from the small audience.
Which isn't a bad thing. Any new language requires its evangelization. I would also posit that from outside the community, Common Lisp is viewed the same way.
[...]
And I know essentially nothing of the Java world, and whether or not it is a good
thing
that they are migrating to Clojure.
That's the crux of it: if you have to co-exist in a Java universe and want to write in a Lisp, your options are Clojure or Armed Bear Common Lisp. ABCL is relatively recent and does not have the community support that Clojure does. The tooling available for Clojure is quite good, insofar as its Emacs tools are excellent and support for the two most common Java IDEs (Eclipse and IntelliJ) is steadily improving, making the transition for Java developers much more friendly. The software that I'm writing in Clojure is seen by our operations team as "just another Java binary". It allows my software to integrate into their existing monitoring and logging systems without them doing anything different. I also have the entire Java/Scala library ecosystem available to me: if I need something that doesn't exist in Clojure I can usually find it in the Java world. The interop between Clojure and Java is cleaner, in my limited experience, than that between ABCL and Java.
While its a tired trope, cross-platform compatibility is good. I develop on Mac OS X, continuous integration and deployment on Linux, and my coworkers use generally use Windows. That's not uniquely a Clojure feature: SBCL, CCL, and LW all run on these different environments too.
There are parts of Common Lisp I miss when developing in Clojure, especially the conditions system. I sometimes miss CLOS, but Clojure has multimethod dispatch which is good enough for most cases.
I like both Clojure and Common Lisp, and see them as complementary tools which I select depending on my needs at any given time. However, there is a cognitive load in switching between them, and since most of my work of late is in a Java world, I tend to stick with Clojure even for nonce tools.
ClojureScript is amazing if you are creating tools or services that need a web-based UI, whether for primary interaction or diagnostics. The entire system can be written in Clojure, with the UI running on the client browser. You can share code across projects: I have a set of functions used to generate various sequence comparison statistics that I share between command-line tools and a single-page web application that is written in ClojureScript. Before moving to ClojureScript I had to maintain two versions of these, one in JavaScript and another in Clojure. I can even make these functions callable from Java, if I cared to do so.
Anyway, I don't want to initiate a religious war between Clojure and CL. I just wanted to give you some reasons why a (Common) Lisper may also use and enjoy Clojure.
Peace,
-tree
-- Tom Emerson tremerson@gmail.com http://it-is-what-it-is.treerex.net