68

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?

ssedano
  • 8,322
  • 9
  • 60
  • 98
uzo
  • 2,821
  • 2
  • 25
  • 26
  • 4
    there is a large amount of Lisp languages for the JVM: http://www.is-research.de/info/vmlanguages/lisp/ Some are used, some are not. – Rainer Joswig Sep 11 '09 at 22:34
  • 29
    As a good old-fashioned Lisp programmer, I can assure you we basically never do things for the sake of fashion. We've been accused of many things but I think we're safe from that. :-) – Ken Sep 11 '09 at 23:51

11 Answers11

113

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 write concurrent programs by default.

dnolen
  • 18,496
  • 4
  • 62
  • 71
  • 21
    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 Sep 12 '09 at 11:59
  • 11
    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 Sep 12 '09 at 16:13
  • Almost every serious language implementation supports thread-based concurrency. The point is that practical STM-implementations are very rare. – pmf Sep 12 '09 at 16:32
  • 9
    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 Sep 12 '09 at 17:07
  • 25
    @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 Sep 12 '09 at 21:40
  • 1
    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 Sep 12 '09 at 22:29
  • 17
    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 Sep 13 '09 at 00:04
  • 1
    @dnolen: I think that one of Rich's most brilliant ideas was to **not** try to implement an existing language (like CL or Scheme), but rather to invent a new one that is close. By not adhering to some existing standard, Rich is free to answer the question "Scheme does such and such. Why doesn't Clojure?" with "But Clojure is **not** Scheme". – Ralph May 15 '11 at 13:12
  • @dnolen One of the greatest things about Scheme and other Lisps is that you can extend the language via macros, or adapting the evaluator. So, if i want a more natural support for whichever paradigm, I can add that to the language. No libs necessary. Its pointless to say language A is better than Scheme, because it has such and such feature, when the philosophy of Scheme is (quote from r5rs "standard"): "Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear nec- essary." – Mali Remorker Apr 20 '15 at 10:05
34
  1. "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.

  2. 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?

  3. Designed with concurrency in mind.

Mark Bolusmjak
  • 23,606
  • 10
  • 74
  • 129
  • 2
    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 Sep 12 '09 at 19:56
  • 11
    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. –  Aug 05 '10 at 02:36
14

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
  • 31,473
  • 17
  • 86
  • 101
11

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
  • 14,424
  • 7
  • 37
  • 41
  • 3
    Clojure has good interop with the JVM but it is quite Lisp-y in terms of the language: the method call syntax is `(.method someopject param1 param2)` for example. The mosy Java-y part of Clojure is around setting up the environment (having a JVM, classpath, .jar files etc.) – mikera Apr 24 '12 at 01:25
11

If I were being cynical, I'd say it's because Clojure's got a nicer website and a sexier name.

ire_and_curses
  • 68,372
  • 23
  • 116
  • 141
  • 2
    You could be right ... your response triggered some thoughts in my head leading to my response. – Larry Watanabe Sep 11 '09 at 23:35
  • 6
    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 Sep 12 '09 at 00:05
10

The rationale page on clojure.org states:

Why did I write yet another programming language? Basically because I wanted:

  • A Lisp
  • for Functional Programming
  • symbiotic with an established Platform
  • designed for Concurrency

and couldn't find one.

Do the 3 languages you mentioned (Kawa, ABCL and SISC) meet these requirements? They are:

  • Lisps (either the CL or Scheme dialects) ✓
  • for Functional Programming ✓
  • symbiotic with an established Platform (the JVM) ✓

but they are not designed for (STM) Concurrency; however, to be fair and complete, there are at least 2 STM libraries I found for CL that have not yet been mentioned:

  1. STMX
    • Tested working on ABCL. Under active development.
  2. CL-STM
    • Dead? Last change was in 2007.

Hmm... So why create a new Lisp? Mainly because these are libraries. The rationale page on clojure.org continues (emphasis added):

What about the standard Lisps (Common Lisp and Scheme)?

  • Slow/no innovation post standardization
  • Core data structures mutable, not extensible
  • No concurrency in specs
  • Good implementations already exist for JVM (ABCL, Kawa, SISC et al)
  • Standard Lisps are their own platforms

It is a language concurrency design issue, as others have mentioned.

Furthermore, why stop at the JVM? Clojure CLR support is under active development.

Those are the 2 gaps it fills, from my perspective. You should use Clojure if it meets your needs. Don't worry about losing your skills if Clojure drops off the map. Your Lisp skills, but more importantly your way of thinking, will carry over to other Lisp dialects.

7

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
  • 10,126
  • 9
  • 43
  • 46
  • 23
    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 Sep 12 '09 at 00:03
  • 1
    Java was heavily hyped, but the single event that made Java what it is today, was when Netscape included Java support in their browser. If that had not happened, I do not think Java would have become mainstream. As witnessed by the current Google efforts timing is critical too - I do not think that any of the new Google languages will be supported in IE. – Thorbjørn Ravn Andersen Jul 07 '14 at 13:03
5

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
  • 10,126
  • 9
  • 43
  • 46
  • 1
    yes, but the question was in comparison to other Lisps on the JVM, which also have access to Java libraries. – Rainer Joswig Sep 11 '09 at 22:35
  • 3
    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 Sep 11 '09 at 23:27
  • 1
    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 Sep 12 '09 at 06:33
  • 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 Sep 12 '09 at 19:08
2

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.

Svante
  • 50,694
  • 11
  • 78
  • 122
ddyer
  • 1,792
  • 19
  • 26
2

We don't have to have one more answer (and I don't expect votes for this one), but here are some small enhancements to several other answers.

Newer is not necessarily better. Newer and poorly designed is not good, newer and not maintained is not good, and newer without a larger (or at least growing) user community is not good. (New languages come out regularly, but most of them fall by the wayside because of disuse.)

I love Common Lisp. Part of its beauty is its quirkiness, which comes from the fact that it was designed by committees with a goal of backward compatibility to several incompatible dialects.

I love Scheme. It's a beautiful, elegant language. Nevertheless, its development depends on committees, and perhaps that has slowed it down at times. In any event, its goals are different from Clojure's.

Common Lisp and Scheme have emphases such as tail recursion that are not well-suited to efficiency on the JVM. Clojure was designed from the start to map well onto the JVM, and to interoperate (fairly) well with Java. (I'm not sure what that means about the Clojurescript and CLR dialects.)

The fact that Clojure was developed, initially, by one person, Rich Hickey, and is controlled by him along with a small team, does not necessarily make it better than a language controlled by committees. If that one person made bad decisions, Clojure would not be a good language.

However, and this is the important point: Hickey designed a language that is well thought out, elegant, and that from the start included a systematically related suite of functions that make it easy to do a lot with a little. That goes for the basic JVM interop as well as the rest of the language. The folks who control Clojure continue to be strict about sticking to the language's goals, so far.

This is a big part of what I love about Clojure: It is well designed both as a whole and in its details. That means that once you get used to it, it's a pleasure to program in it.

It would only be a little bit of an overstatement (or understatment?) to say that Clojure has the power of Common Lisp with the elegance of Scheme. Common Lisp has lots and lots of what you need built into the language, but it's a mess (I say that with love), and when you need something more than what's in the language, there are sometimes several incompatible libraries with different tradeoffs. Scheme by design is small, although there are libraries available. Clojure has a growing body of standard libraries (unlike CL) that are more or less parts of the language. A nice illustration of this is the core.matrix project, which provides a common interface to several different matrix implementations. This is important, because there are different matrix implementations that are best for occasional use of small matrices, or for extensive use of huge matrices, for example.

None of this is intended to say that Clojure is better than Common Lisp or Scheme; it's not. The three languages have different virtues.

Mars
  • 8,689
  • 2
  • 42
  • 70
  • Addition a few years later: People interested in matrix libraries for Clojure might also consider Neanderthal, which has not been integrated into core.matrix, but seems quite popular. I have not used it. (This is a point against my last claim, I guess.) – Mars Aug 01 '19 at 20:05
0

It's new! Which means not a lot of old lispers will use it since the traditional lisp community is well, traditional, but it also means that people with no previous lisp experience will pick it up as the new thing.

Imho, Clojure is to older Lisps what Ruby was to Smalltalk. Not necessarily better, but good enough. And crucially, it's more acceptable to your employer because it has momentum and is viewed as a language on the rise, much like Ruby once was.

saolof
  • 1,097
  • 1
  • 15
  • 12