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

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

Have you switched to Clojure? If so, from what?

On 2009-02-10, Kenneth Tilton <kentil...@gmail.com> wrote:

It has more kinds of parentheses. And symbols have to prove themselves
worthy before they are interned.

That constraint I can't deal with. I only ``do'' 25 words or less.

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.

NewLisp, mostly. In fact, I switched from NewLisp to Clojure about six times
just today alone!   Well, no four. One of those times I went to Scheme first,
then Clojure, and another time I was actually using Common Lisp and /thought/
it was Clojure, until I misspelled some names. The misspellings scrolled off
the screen, and so I didn't know what to unintern to get back to a clean state.
I ended up rebooting the machine.

This is why it's worse.

And 25 is not less than 100 anymore?

--
__Pascal Bourguignon__

On Feb 10, 12:30 am, Kenneth Tilton <kentil...@gmail.com> wrote:

I guess I've switched, from Common Lisp, mostly because I changed jobs
last November and I couldn't take my CL code base with me, so I was
able to examine Clojure from a fresh perspective.

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.

Glenn Ehrlich

<snip great response>

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

kt

What is your Clojure Status?
   - What is Clojure?
   - Never looked at it.
   - Looked but did not like because ___
   - Will use for some work because ___ but not all because ___ but
continue to use ___ for ___ because ____.
   - Will now use instead of ___ because ____
   - Other ____

(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).

Other _______

On 2009-02-10 05:31:27 -0500, p...@informatimago.com (Pascal J.
Bourguignon) said:

<http://en.wikipedia.org/wiki/Sarcasm>

--
Raffael Cavallaro, Ph.D.

On 2009-02-10 10:10:13 -0500, Kenneth Tilton <kentil...@gmail.com> said:

is clojure about to vault into the tilton pantheon?!

will use for some work but not all because of:

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.

maturity of the language. code from six months ago often doesn't work
because breaking changes are still being made to the language.

--
Raffael Cavallaro, Ph.D.

No, just curious. Thx for the survey response. Mikel is indeed a big plus.

kt

I'm syncing to the daily builds of clojure, and doing some minor
benchmarks. I'm trying hard to reach the speed of Common Lisp or Java
(I'm running Clojure with the -server option).

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).

It definitely looks useful, and can teach you how to write even more
functional code (still trying to prevent myself from imperative thinking).

 ge> I'm exploring Clojure for my simulation work.  The biggest plus for me
 ge> in my domain is Clojure's concurrency model: immutable data
 ge> structures, agents, STM, and NO USER LOCKS!.
 ge>   This makes it very easy to spread model calculations across cores
 ge> without having to protect

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.

so, all these features are sort of "cool", but totally meaningless
without proper benchmarking data. (if we're speaking about CPU-bound
applications.)

 KT>    - Looked but did not like because ___

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

plus, at time i was looking at it, it threw errors in Java backtrace format,
that is, you've misplaced paren, and it throws ton of bullshit at you.
very unpleasant. (it seems they've aldready fixed this)

Dimiter "malkia" Stanev schrieb:

In general one can suggest to give type hints to speed up things.
For a little test function that Rainer Joswig gave here in c.l.l some
weeks ago I got from x15 more runtime than sbcl to half the runtime of
sbcl with a few type hints.
But sometimes those won’t help. Currently the bignum lib from Java seems
to be pretty slow.
For Java 7 some drastic improvements are visible on the horizon:
http://markmail.org/message/7conncsespvrlazn

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.

So find-doc did not give you satisfying results?
It can also take a regex...

There are many Java tools that can support you.
Did you try jad to decompile .class files into .java files?
(in that sense Java is the Assembler for the JVM :))
But you can also use bytecode viewer.

As you can see, float is just an ordinary function, but does implicitly
give a type hint:
http://code.google.com/p/clojure/source/browse/trunk/src/clj/clojure/...

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

I hope you did not base this on the one result of your poly test case.
Although you know of course much better your needs. If that benchmark is
what you are basically doing all the time, then it’s very understandable.

André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/

Pascal J. Bourguignon schrieb:

The question at this point could be why this is worse.
Honestly, I see only advantages here.
The [] and {} give some hold to the eye, which I find nice.
One can of course argue that it is less consistent, and that a „real
Lisper” will only want to use (). But let’s not forget that () them-
self are reader macros. And if we want to argue with consistency in
mind, then those people should not make use of other reader macros in
CL as well, such as  '  #'  `  ,  ,@
I however see that a few handselected reader macros are a great thing.
They should exist for the most commonly used tasks.
Lists are mostly used in Clojure to write code :)
Vectors have taken more or less the place of the list.
One can „cons” elements to it (the function really is conj) and traverse
it with the same performance as lists. But random access is done in near
constant time. Also reversing a vector is much faster, though this is
less often needed, as conj adds elements at the end of the vector, not
to the front (as with lists).

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

André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/

[snipped a lot of useful information - keeping it for later to read]

Thanks Andre!

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

For example ARC did not leave me with that impression - to me arc
sounded like Common Lisp in Rap Lyrics/Slogan... And fact is Paul Graham
is still my favourite lisp person (I've read his stuff). Maybe I'm
missing something from ARC too - but that's another topic.

Let's say that it's a personal taste. (And indeed, I use (function x)
rather than #'x, and sometimes (eg for pedagogical reasons), I use
(quote x) instead of 'x.

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).

This is crazy.  Nobody write such a form!

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

We only need to add a CDR for a READTABLE-PARSE-TOKEN hook to be able
to read uninterned sources without reimplementing the reader.

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.

--
__Pascal Bourguignon__

On Feb 10, 10:06 pm, p...@informatimago.com (Pascal J. Bourguignon)
wrote:

I beg to point out that some folks can touch-type the non-letter
keys...
and although clearly farther away from home position and therefore
slower,
each non-letter used in a non-letter-rich syntax will generally
represent
many letters of lisp symbol.  non-letter-rich syntax can be an
effective
compression for 1) reading, 2) thinking, and yes also 3) typing, if
one
touch-types the non-letters.

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

On 2009-02-10 22:06:28 -0500, p...@informatimago.com (Pascal J.
Bourguignon) said:

This is not an issue for clojure:
from: <http://clojure.org/reader>
"The read table is currently not accessible to user programs."

Of course many common lisp users will think this more a bug than a feature...
--
Raffael Cavallaro, Ph.D.

On Feb 10, 4:10 pm, Kenneth Tilton <kentil...@gmail.com> wrote:

I'm using it to learn the Java libraries without having to use Java. I
don't think I'll be lucky enough to find another Lisp job soon:
finding IT jobs in Belgium with no Dutch is hard enough. So I'm
preparing for the worst...

Clojure in non-proprietary and has lots of interesting features built-
in, in particular, concurrency, abstract datatypes (collections,
mappings), lazy evaluation.

I haven't been using Clojure for long enough to miss much of Common
Lisp.

...

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.

cheers,
Tom

Kenneth Tilton schrieb:

The word „better” is nothing objective, so people can disagree on what I
personally rate as better.
My list of things that I like in Clojure better than CL
(in no particular order):

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.

Yes, switched from CL to Clojure.
And if it is not necessary, I would not want to go back.
But sure, if Clojure is no option then CL would always be my next
choice.

André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/

Francogrex schrieb:

I respect your opinion, however, I would like to mention two things:
1) The connection to Java can be seen by some folks as very healthy.
2) When you argue about matureness and evolution, then Clojure could
    be interesting. The language is much more simple than Lisp. And
    some core parts of a Lisp were already provided by the JVM. For
    example the GC, the Exception system and some tenthousand ready to
    use methods. In that regard, Clojure can be seen as even more mature
    than CL implementations. As Java is the most popular programming
    language it gets on a daily basis more man hours of testing than
    all CLs got in the past years. Billions were invested by the biggest
    IT companies into the JVM, and it went through an evolutionary
    process in which it got very mature.

    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.

André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/

Kenneth Tilton schrieb:

It is: I use it daily for professional work, but also nearly every day
for personal programming fun.
I use Clojure now instead of CL mostly, and will port my code.

Because those are CL implementations which come with clos.
I like clos more than the object system of Java, but this is just my
opinion. A fact however is, that those object models are not compatible.
It is very ugly to work with Java from within CL.
So, if access to Java would be a big factor, then one should definitly
use a language which was designed with that idea in mind.

 From CL I miss in principle nothing.
I am glad that Clojure has no object system, but instead goes the path
of functional programming.
What I miss though are features of specific CL implementations.
For example SBCLs type inference engine.

André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/

On 2009-02-12 19:23:41 -0500, André Thieme
<address.good.until.2009.may...@justmail.de> said:

Not really. This argues for the maturity of the *platform* on which
clojure is built (i.e., the jvm). Clojure itself is clearly still not
mature. There's a thread still running on how to fix mod:

user=> (mod -3 3)
3

So clojure, the language, not the platform it is built on, is still not
nearly as mature as common lisp.
--
Raffael Cavallaro, Ph.D.

 AT> 1) The connection to Java can be seen by some folks as very healthy.

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)

when considerable portions of implementation get reorganized in short
periods of time,
that is *not* called "mature"

On Feb 10, 7:10 am, Kenneth Tilton <kentil...@gmail.com> wrote:

I've looked at it, but I have a bunch of code in CL that I'm working
on and see no compelling reason to switch.

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.

-- Scott