In 100 words or less, why is Clojure better than Common Lisp?

And anyway, in this world, by the time your ad execs throw together a monstrous
100 word sound bite, the competition has eaten your lunch.

I'm exploring Clojure for my simulation work.  The biggest plus for me
in my domain is Clojure's concurrency model: immutable data
structures, agents, STM, and NO USER LOCKS!.  This makes it very easy
to spread model calculations across cores without having to protect
against improper concurrent data sharing either with hard to develop/
debug locks or by "convention".  Even though Clojure has no built-in
distributed support, it'll eventually get one and until then, it
appears that one can use any of the mechanisms available through the
JVM.

The second big thing for me is the Java interoperability, as my domain
needs access to lots of different math and there's lots of math
libraries for Java that are accessible through Clojure's very nice
Java interop facilities.  Additionally, it's very easy to tell Clojure
what the types are of  data items (like various CL declarations,
although easier to use) which speed things up.  CL's numeric tower is
more featureful, but Clojure's is certainly adequate.  There's no
native complex number support, although you can do that in the Java
layer.  I haven't yet needed to use complex numbers in my work so
that's not a big deal for me but I have seen some postings of math
types who miss native complex numbers.  There's no problem with
Clojure functions being the callbacks for Java code, as Clojure
functions implement all the right Java interfaces to make that work.

The HotSpot JVM seems speedy enough for me and it has a JIT so things
that run a while automatically speed up.  For some micro benchmarks in
the areas that I care about, Clojure compares well with SBCL once the
JIT has had a chance to optimize things.  The last time I had done any
serious work in Java was in 1997 so I was very pleasantly surprised at
how far JVM performance has progressed.

I initially thought I was going to miss CLOS because my prior code
base heavily depended on CLOS, especially method combination to help
make a lot of boilerplate disappear (in addition to removing the rest
of the boilerplate with a very high-level abstract model definition
language implemented with macros on steroids), but the way maps
(hashmaps), multi-methods, meta-data, and ad-hoc hierarchies work
together mostly make up for the lack of CLOS.

The big step for me here was getting past "it doesn't have CLOS, how
can I model essentially object-oriented simulation models without
something like CLOS?" to "with what's available in Clojure, what's the
Clojure-idiomatic way of creating the model building abstractions I
need?"  Once I got past that hang-up, I was able to proceed quite
nicely and am happy with the result.  My user-level model building
code will be as nice, concise, and high-level as my CL version was
(this is all work in progress).

The other things I miss in Clojure in addition to the above mentioned
method combination are symbol macros, macrolet, and LOOP (!), but
there are ways around most of these things so their ommision aren't
too painful.  For day-to-day programming, LOOP is probably the thing I
miss the most, as any looping has to be done through recursion.
There's a language construct to make tail-recursive calls efficient on
the TCO-less JVM, but I do miss some of the more powerful features of
LOOP (yes, I'm LOOP-evil).  However, the Clojure community is very
active so I expect that over time these will be filled in with
libraries.

When I was doing my initial investigation last December, what really
cinched it for me was watching Rich's Clojure for Lisp Programmers
videos and the concurrency video.  They are very good and should
answer any questions about whether Clojure is suitable for any
particular task.  The concurrency video is particularly good and goes
into technical depth discussing Clojure's concurrency support, the
design decisions Rich faced and why he made certain choices, and an in-
depth code walkthrough of an ant-colony food gathering simulation
using agents.  Very cool stuff.  Even though the video wasn't
specifically about Java interoperability, he does show building up a
graphical UI to show the ants speeding around in the REPL.  Very, very
cool stuff.

My opinion after watching these videos is that Rich has *very* good
design taste.  Starting with the goals he wanted, in my opinion, he's
made the right decision every time.  It's obvious from the videos that
he has a deep command of programming language theory, which has led
him to choose a lot of semantics and implementation techniques that
fit together well, instead of that "groping in the dark" feeling you
get from say, certain languages.

In summary, I'm not going to say that Clojure is better or worse than
Common Lisp.  For my particular domain, I can do some things easier
than I can do in the Common Lisp implementations I have available to
me (an important qualifier!) so it's useful for me.  Your mileage may
and will vary.

Oh, I should add that I've purchased the beta of Stuart Halloway's
"Programming Clojure" book from Pragmatic Programmer's and it covers
the language nicely.  I was able to breeze through the book in several
hours and came away with a good command of the language.  Keep in mind
that it's more geared towards a non-Lisp reader than a CL expert.

Thx! You gave me ideas for a lot of questions. New survey soon (all of
which you have already answered).

(I think the rest are for anyone who will be using Clojure)

If Java access was a big factor, why not ABCL or AllegroCL?

What do you miss from Common Lisp (or whatever the "from" language was).

cross platform java libs, especially cross platform gui libs

integration with emacs/slime

active enthusiastic user community and much contributed code

mikel evins likes it!

built in ease of threading due to immutablility of clojure data
structures (i.e., pure functional semantics).

possiblility of easy web deployment via applets (though not currently
high on my list)

continue to use CCL because of excellent mac os x integration.

kt

Overall, the speed ain't bad, it's about 10x faster than perl, python,
ruby, but x10-x20 slower than most of the Common Lisp Compilers (SBCL,
CMUCL, LispWorks, ACL).

I'm using Lisp for heavy calculations, so I can't really use it, until I
learn to optimize it better.

My base benchmark was the pnpoly.lisp code (point-in-poly).

Other things that I'm missing from Common Lisp are some form of
"apropos" and some way of disassembling the functions - I'm doing this
regurarly with Common Lisp in order to learn the peculiarities of the
various implementations, and gather knowledge of best practices myself
(off course there are papers by Fateman, and others about single and
double floating points).

Another strange peculiarity is the tagging - sometimes you have to do
(#^Float number), sometimes (number (float 10.0)) - it seems not
consistent, but granted this is not where the language is shining.

I think it's not the language right now for my needs, but my become, as
soon as I start explore web development more and more.

The JAR file is rather small, compared to the ABCL (not fair comparison,
I know different things - but still to give you perspective).

spreading across cores makes sense if it speed ups things, right?
even if there are no apparent locks, STM etc., etc. might have its
overhead. and it might be possible that Clojure running on all 8 cores
works actually slower than SBCL running on single one.

i did not like it because it is not a Common Lisp!

Another general suggestion is to run things in parallel.
This makes of course only sense if your algorithms are parallelizable.

If they are not, and if you are using Clojure datastructures (such as
sets, vectors, hashmaps, ...) instead of Javas it can also be in some
cases a disadvantage. The Clojure versions simply have to do more work
under the hood. These datastructures are not only threadsafe, but also
concurrency ready, which is even more expensive.

And btw, (number (float 10.0)) produces an error, as the function number
does not exist. Did you mean number? maybe?
Type hints can be given very consistent with the reader macro #^
as in #^TYPE

Passing around small hashmaps is so simple.
(some-function {:a 10, :b 20}) vs

(let ((temp (make-hash-table)))
   (setf (gethash :a temp) 10
         (gethash :b temp) 20)
   (some-function temp))

And the other thing that Kaz said about interned symbols also makes sense.
For example Hans Hübner writes in his blog:
„Clojure wants to be a Lisp, but it explicitly does not try to be
backwards compatible. This opened a rather large design space to Rich
Hickey, and some of the choices he made really do make sense. He
specifies a reader, yet his reader does not intern symbols. That is a
big win, as it allows the reader to actually work with arbitary Clojure
source files. In Common Lisp, one needs to re-implement a full reader
which does not intern symbols if one wants to read Common Lisp source
files. This is kind of ironic, as the "Code is Data" mantra that we keep
repeating does not really reflect what is possible in practice.”
Soure: http://netzhansa.blogspot.com/2008/10/trying-clojure.html

No I'm not going away from it - rather I'm staying - i like the
interactivity of it, the funny thing about it running on JVM (for good
or bad, I can get this thing to run on almost any platform, because it
uses JVM).

Also Rich Hickey seems to know his stuff, and only following his
creation, is enough to grasp powerful ideas, even if I may not use his
language at the end professionally.

Definitely I'm staying, and I'm going to dabble into it even more...

Reducing the set of special characters used to write code let you
write it faster.  Keying in English is fast, because you only use
letters, and a very small number of punctuation, compared to keying in
popular programming languages.  If you resist the temptation of using
a lot of reader macros in lisp, then you can type lisp code as fast as
English text.

Also, it would be nice if the language didn't use all the characters,
and left some for user's reader macros. In Common Lisp, {}, [] , !?
and a few others are reserved to the user.  (Of course, with unicode
this is less of a problem).

(htable :a 10 :b 20)
--> #S(HASH-TABLE :TEST EXT:FASTHASH-EQL (:B . 20) (:A . 10))

But even with the current standard, the point is that reader macros
are not to be abused for lisp programs.  It's better in lisp programs
or embeded DSL to use normal functions or macros such as (htable :a 10
:b 20) than to use a reader macro such as {:a 10 :b 20}.  

Reader macros are designed to build user level DSL.

If you need to read a DSL source without "interning" it, then you
should use a normal parser.

That said, the whole reason I like and use the CL type of Lisp syntax
is
because my preferences agrees with yours on:

...

Another interesting approach to leveraging Java libraries is Jnil
(http://common-lisp.net/project/jnil/), which actually translates them
into Common Lisp. The maintainer could really do with some support.

1. It basically supports one major paradigm/style of programming,
    the functional one. CL too does support it, but CL also supports
    other styles, and it is even very idiomatic to do imperative
    programming in CL.
    People will disagree if offering a smaller number of programming
    style is better or not, but I like it better. It means that most
    developers will come up with more comparable/compatible solutions.
    Whatever one may think about the Java programming language, it’s a
    fact that it offers a very large set of libraries. This is due to
    the limits which are built in into the language. There is basically
    one way (few ways) to do it, instead of many ways, as in CL.
    So, I prefer to have one major style in Clojure. It happens to be
    the one I preffered since many years in CL too, the functional one.

2. Concurrency ready. I see basically 3 or 4 languages out of the
    many hundreds in use, that are seriously capable of doing concurrent
    programming: Clojure, Erlang, Haskell, and also going there, F#.
    While it is not impossible to do it in other languages, Clojure does
    make it really easy. It’s in some sense the argument that was in
    favour of CL in the past 15-20 years: „Yeah, mathematically speaking
    it is possible in other languages too. In principle one can solve any
    problem in Assembler. It’s just that it is much easier in Lisp, as it
    comes with powerful abstractions”.
    Clojure has gone the evolutionary step into the right direction (in
    my opinion), by providing standard tools for concurrency. Other langs
    like CL or Python can also do functional programming. But the problem
    is that they also offer an alternative way. As long that exists the
    devs have to program by agreement, and they need to be very strict.
    Currently not many languages have a good implementation of a STM with
    Multiversion Concurrency Control. I think for F# one is currently
    being developed. But this really should come with the lang itself,
    as this would be an integral part. If this is an addon lib, then
    other implementations may arise, which can (no doubt) also have ad-
    vantages, but brings back incompatibility.

3. Modernized syntax. It makes totally sense to me (you might disagree
    of course) to have some basic syntax support for the most common
    operations. The CL committee had the same idea in mind and intro-
    duced  '  #'  #+  #-  `  ,  ,@  which, again, makes very much sense
    to me. To make access to datastructures other than lists easier,
    Clojure went a step further, and provides reader macros for vectors
    (which can replace lists to a great part), hashmaps and sets, and
    of course strings (and regular expressions).
    I now hate it so much when I go back to CL that everything is so
    chatty. It does not buy me anything that I have to bloat up my code
    for typical tasks.
    Clojures datastructures are fully integrated into the macro system.

4. Lazyness. In many places Clojure is very lazy :)
    This is great. Not only does that improve performance greatly, no, it
    also allows new idioms and a more elegant programming style. It’s
    well integrated.

5. It runs on the JVM. Today many languages do run in a VM (like CL,
    Python, C#, ...). Why develop your own when you can have the most
    mature one?
    Chosing the JVM brings also tons of advantages:

    a) Operating system does not matter so much anymore. CLs are
       available for most plattforms too, though this does not always
       help. No recompilation needed. I can switch back between the OSes
       and continue coding. The devs of the same team have the choice of
       their OS. The employer would not have to force us anymore to use
       something we don’t like. The plattform in the end is always the
       JVM.

    b) Giant lib. Want a server for RESTful applications? Integration
       with SAP? The JVM can not do magic, but it really haves very
       much to offer, library wise.

    c) Will help to create much more Lisp jobs.
       I personally left two times my home city to get a Lisp job. One
       time I even left my country for it. As Java is the most popular
       programming language it is more likely to find interesting pro-
       jects in cities of my choice. Of course I don’t want to do Java
       programming, but there will always be Java companies (probably
       the not too big ones) that will accept you in their team as a
       Clojure developer. True, it potentially can bring in some diffi-
       culties if you are the only one who can read/write Clojure code.
       But some companies will weight that against the 2x - 20x boost in
       productivity that Lisp can bring over Java. Clojure brings me into
       the position that I suddenly can negotiate something with the
       company.

So, maybe a bit more than 100 words, but here you go.
The points that I listed will not be the ones that everyone else will
also find „better”. I however do.

    Speaking of evolution: Clojure learned from Lisp. So it is not a
    new language that started from scratch. No, it inherited the DNA
    of its parents. It took the efforts of research in the past 50
    years and continued to evolve from that point. So, it is the next
    step in evolution of Lisp.

user=> (mod -3 3)
3

oh yes, it is very healthy (for a functional language!) to have "recur"
special
operator instead of normal tail recursion because of JVM deficiency.

 AT>  In that regard, Clojure can be seen as even more mature
 AT>  than CL implementations.

platform maturity has nothing to do with language implementation maturity.
i have here a build labeled "2008-09-16", just few months ago error handling
was totally broken and weird as it was spitting java backtraces:

user=> (())(()))
java.lang.ClassCastException: clojure.lang.PersistentList$EmptyList cannot
be cast to clojure.lang.IFn
java.lang.ClassCastException: clojure.lang.PersistentList$EmptyList cannot
be cast to clojure.lang.IFn
        at user.eval__2290.invoke(Unknown Source)
        at clojure.lang.Compiler.eval(Compiler.java:3891)
        at clojure.lang.Repl.main(Repl.java:75)

If I should decide I need my app to run on the JVM at some point --
which is possible -- I would consider Clojure, but I would also
consider Scala.