The JVM already had three Lisps before Clojure arrived on the scene: Kawa, Armed Bear and SISC.
What gap does Clojure fill that was left by those Lisps?
+18
A:
"Clojure is a Lisp not constrained by backwards compatibility" (that's from the Clojure website). It's a fresh start. It's progress. Use the ideas that make Lisp/Scheme powerful but rethink them around the Java platform.
Clojure will always be the most recent Clojure. With any other language ported to the JVM, the JVM version might always be playing catch-up. If you don't need the Java Platform why use SISC over another Scheme? If you do, why not use the one Lisp (Clojure) that was designed specifically for it?
Designed with concurrency in mind.
z5h
2009-09-11 21:36:10
This seems to be contradictory to the other posts - either Clojure was designed around the Java platform and JVM - thread level concurrency with mutable objects and lock based synchronisation, and libraries based largely on getters, setters and event loops ( the opposite of functional programming style ) - or it's designed around ( some other form of concurrency ) and software transactional memory, which the JVM does not support natively.
Pete Kirkham
2009-09-12 19:56:55
Pete: It is designed for the JVM and for concurrency - these are not mutually exclusive and just because it is designed for the JVM, does not mean it has to do things the same way as Java does them, so long as it works well on the JVM and plays nicely with existing JVM libraries/code.
Dan
2010-08-05 02:36:52
+3
A:
I simply wasn't aware of those, which is a serious benefit for Clojure (that people made enough noise I found out). The biggest thing Clojure has that I didn't see in those you listed is Software Transactional Memory.
Clojure was also designed for the JVM, as opposed to being a layer for another language, so it's a little more "Java-y" that I imagine the others would be when you have to do interoperation.
MBCook
2009-09-11 21:36:47
+2
A:
The advantage of Clojure is that it gives you access to all the java libraries/code out there, and multi-threading support because it's based on the JVM. In addition it was designed with concurrency in mind, something not generally designed into lisp, although because of the mapping primitives it probably wouldn't be hard to design a lisp that would support concurrency well.
That being said, I tried Clojure and hated the syntax and the pain in the butt factor that seems to go along with anything Java-connected.
Larry Watanabe
2009-09-11 21:40:31
yes, but the question was in comparison to other Lisps on the JVM, which also have access to Java libraries.
Rainer Joswig
2009-09-11 22:35:56
They have access to Java libraries through a foreign function interface -- but with Clojure, since the code/data is compiled down to the JVM, the java code can also operate on the Clojure data structures. This gives a tighter and more seamless integration with Java. But, for me this is like having a closer and more intimate relationship with a girl that you don't really like or find attractive :) You can do it but what's the point?
Larry Watanabe
2009-09-11 23:27:35
Larry, these other Lisps are also running to the JVM and have direct access to Java libraries. No FFI. He listed Kawa, ABCL and SISC. These are running on the JVM. For ABCL is a Common Lisp that is also compiled to JVM instructions.
Rainer Joswig
2009-09-12 06:33:02
Rainer, if you read my next answer you will see that actually I think the main advantage of Clojure is that it is "new" and "different" enough to get some support behind a push for it's adoption. This is probably it's main advantage. As you pointed out, the technical disadvantages either are easily remedied or have been remedied.
Larry Watanabe
2009-09-12 19:08:38
+2
A:
If I were being cynical, I'd say it's because Clojure's got a nicer website and a sexier name.
ire_and_curses
2009-09-11 21:47:03
You could be right ... your response triggered some thoughts in my head leading to my response.
Larry Watanabe
2009-09-11 23:35:35
Clojure offers something very different from what CL and Scheme offer. Do either of you have experience in all three (CL, Scheme, Clojure)? Otherwise you'd both be making more informative commentary.
dnolen
2009-09-12 00:05:37
+33
A:
Kawa, ABCL, and SISC are reimplementations of existing languages that are quite long in the tooth. They are excellent if for some reason you want to use standard Scheme or standard Common Lisp on the JVM.
Clojure is a new language. It doesn't fill a gap. It adds entirely new possibilities. It favors a purely functional approach- Scheme and CL are both multi-paradigm. Clojure borrows heavily from the design of various FP languages (ML, Haskell).
And yes you could add concurrency support to other Lisps, but that's entirely missing the point. Clojure was designed from the very beginning as concurrent language. So much so that writing concurrent programs is trivial in Clojure - not rocket science as it is in non-functional languages (Scheme, CL not excluded). Look at this way:
People say that C lets you write fast programs by default.
Well, Clojure lets you concurrent programs by default.
dnolen
2009-09-11 22:10:08
I don't know why you are being downmodded. Your last sentence pretty sums things up. Clojure provides the only viable, non-academic way to write performant STM-programs for the JVM. Going back to lock-based concurrency is like going back to manual memory management: sometimes you need it, and it can be a nice challenge and does not need to be tedious, but overall it distracts from the core logic of the application, which is why you don't do it until necessary.
pmf
2009-09-12 11:59:55
He is downmodded because he did not even care to check the other Lisps mentioned: Kawa, ABCL SISC.The SISC documentation says for example: 'SISC provides a comprehensive library for executing Scheme code in parallel in multiple concurrent threads'. So you don't need to add concurrency to SISC, it has it already.
Rainer Joswig
2009-09-12 16:13:19
Almost every serious language implementation supports thread-based concurrency. The point is that practical STM-implementations are very rare.
pmf
2009-09-12 16:32:41
STM is not needed to write concurrent programs. Also, no, not every serious language implementation supports thread-based concurrency. Thread based parallel execution is widely supported. Concurrent execution is not that widely supported. dnolen does not even mention STM, he talks about that one 'could' add concurrency support in other language (when it already HAS done), etc. Also why is adding 'concurrency' to a language like Scheme missing the point? I thought Lisp like languages were famous for adding all kinds of paradigms, being some kind of language laboratory.
Rainer Joswig
2009-09-12 17:07:19
@Rainer, adding a concurrency library and a language being _designed_ for concurrency are not the same thing. Note that I said "So much so that writing concurrent programs is trivial in Clojure". SISC supports concurrency but it lock-based. This is notoriously difficult and painful.I didn't say that STM was needed to write concurrent programs. My points were that Clojure programs are by default concurrency safe (you don't need to import a library to get at these features) and that concurrent software was far simpler to write in Clojure (no locks because of STM).
dnolen
2009-09-12 21:40:41
A) SISC provides concurrency. You may not like that it is lock-based them, but they are there. People have been writing lock-based concurrent software for decades. B) I doubt that concurrent programs in any paradigm are 'trivial' when you try to solve the same problems. C) Basic use of locks is relatively easy in Lisp, thanks to linguistic support. In a web server for example, the threads share only little state, it is easy to write basic control structures that implement thread queues etc., queues that handle logging, etc. - all easy enough with locks in Lisp.
Rainer Joswig
2009-09-12 22:29:01
A) And people have also been writing without higher order programming for decades. This says and proves nothing. B) Have you tried using an STM? C) Have you tried using an STM? What if you need to write a highly concurrent program with shared state? How do locks help?Lock-based concurrency may be easy for you, but your viewpoint goes against the very large body of literature that says otherwise.Also, I don't think that STM is the only answer to this problem, for example, Apple's Grand Central Dispatch is different approach which doesn't require locks.
dnolen
2009-09-13 00:04:28
+3
A:
I should also add that Clojure is a relatively new language, implemented by one person, with good marketing skills and a lot of energy. He's investing a lot of time and hype into clojure ... sometimes, the hype is a self-fulfilling prophecy in that if you can convince enough people that it's the latest greatest thing, then you can get enough support and momentum to make it actually work.
I suspect the implementers of Kawa etc. don't have as much at stake, hence are not hyping their product. Besides, what's there to hype? "We've got a great language .. it's called Lisp" It's a harder marketing sell.
I think Java is a prime example of this. It had some very serious deficiencies, but because it was marketed and hyped so heavily it achieved a lot of momentum which meant support from hardware/software vendors, producers of tools, investment by industry, etc. Either way, it achieved a certain degree of success, although I hated programming in it. Clojure might achieve a similar success where other Lisps have not.
Larry Watanabe
2009-09-11 23:34:27
I don't think Rich Hickey puts much "hype" into the language. In fact he seems positively "anti-hype" and fairly restrained in his descriptions of the language itself. Personally, having used CL (lightly) and Scheme (SICP), I can say that Clojure benefits from having been developed post the year 2000 A.D and not by committee.And while I have no love for Java the language, there are many, many well designed libraries (Joda, JOGL, jSynth, Lucene, ...). I also believe that the engineers behind the JVM knew what they were doing having the experience of StrongTalk, Self (and having moved onto V8)
dnolen
2009-09-12 00:03:19
+1
A:
Clojure is "a lisp", it's not any lisp you already know. I've spent the last couple days reading the material and viewing the videos, and I'm impressed. Its premise is that functional programs (based on immutable data) are the best way to manage concurrency. Clojure implements a lisp-like system based on JVM to provide it.
ddyer
2009-09-13 19:53:47
+5
A:
The most simple answer I can come up with is, Clojure is not Common-Lisp. Clojure is not constrained by the history of other Lisps. It is a new language built for the JVM.
Rayne
2009-09-14 03:05:16
Holy shit. I just came back to this post after over a year, and it sounded snarky and assholy. I don't know why I came off like that, but I edited out the snarky.
Rayne
2010-10-20 16:13:20