
The Axis Of Eval: Why I ignore Clojure - Torn
http://axisofeval.blogspot.com/2010/04/why-i-ignore-clojure.html
======
jacquesm
What an interesting perspective on language development.

It's funny how the biggest detractors of clojure seem to be those that should
be cheering it on, the people that use LISP.

Clojure _is_ a lisp, like it or not, sure it's not common lisp or whatever
other dialect you prefer, but that shouldn't matter too much.

LISP used to be leading, now it is lagging and this person seems to be somehow
proud of the lag.

LISP is as much a way of thinking as it is a programming language and Clojure
is representative of that way of thinking. The implementation details are
really just that, details.

So ignore clojure - and any other modern attempt at bringing LISP in to the
mainstream - and decades from now you might wish that you had not, because you
lost your chance at shaping the future of the language that you profess to
love so much.

~~~
ohyes
We're detractors because we care...

I like Clojure, I've used it for a number of projects. I've given money to
rhickey. I think it is very promising.

It has a lot of good ideas and it is very refreshing to see people tackling
current issues in a dialect of lisp. It is also nice to see a lisp with market
traction.

That said, there are a lot of things that are 'unproven' about it.

It isn't clear that shared state immutability and transactions are 'the way'
to tackle concurrency.

It isn't clear that Clojure's macros are really better than Common Lisp's
macros.

It isn't clear that we really want to be tied to the JVM/NET architecture.

(Or that the concessions made to do so are reasonable... stack traces, tco).

I think I could go on if I wanted to.

A large number of features implemented in Clojure are still research topics...

It grates me when proponents of Clojure tout it as 'a modern dialect of lisp,'
implicitly asserting that other lisps are in some way decrepit, aging relics
from the 80s.

The truth is that Clojure is modern compared to almost ANY programming
language, calling it 'a modern dialect of lisp,' while potentially true, is
doing a disservice to Clojure, as well as to other lisps which are under
active development.

~~~
jacquesm
Why is naming something 'what it is' doing it potentially a disservice?

What arguments are there to say that clojure is _not_ a modern dialect of
lisp?

The JVM came about pretty recently (on the LISP timescale), software
transactional memory has been around for a while but afaik no mainstream lisp-
like language implements it, and so on. That all says 'modern' and 'new' to
me.

I'm not versed enough in Lisp _or_ clojure to make any statements about the
macro issues.

What bugs me about clojure is on a completely different level, all those 'x
done 'in clojure'' articles that really do nothing to advance the state of the
art, as though doing something 'in clojure' somehow makes it worth writing
about.

And then there's the 'one man show' feeling that is still very pervasive.

~~~
ohyes
It is the tight coupling of the terms that is doing the disservice.

It is a modern language. -> T.

It is a lisp. -> T.

However, I only hear, 'It is a modern dialect of lisp,' when I am being told
why I should switch from Scheme or CL to Clojure.

This is a non-argument (there is no spec for what a 'modern' language
includes). It also has the implication that whatever I am using is in some way
non-modern. (Which is an odd attribution for something which is actively
developed and I do my daily coding in). Is Java modern? How about Python?
Scala? Ruby? It seems like a weird non-category. When I boot up sbcl, it isn't
like i'm programming in lisp 1.5.

New would be cool, or saying it has modern features, also good.

Gonna make a new spec for Common Lisp, Common Lisp the Ancient Language.

------
zephyrfalcon
Most of us are not Ents. We don't have decades to wait and see how a language
feature "plays out". Rather, most of us have projects that we need to work on
NOW, and if a language comes along with features that help us solve hard
problems, it would be a good idea to take advantage of it. Who cares if "the
greater Lisp community" will approve of it or not?

(By the way, "Lisp community" is a bit of an oxymoron, IMHO; everyone seems to
be stuck on his own island.)

~~~
mfukar
Indeed, there is no Lisp community. The fragmentation was enough for me to
lose interest in the language and several of its dialects (heavily influenced
my switch from emacs to vim, too :(), as well as functional programming in
general. I wish the Lisp crowd (?) would seriously reconsider their views on
matters like this.

~~~
lispm
So you lost interest in Linux as well? There are probably more different Linux
distributions than Lisp dialects. Which shell do you use? How about a C like
language? C? Why not C++? Or D? ATS? You've decided on a scripting language?
TCL? Perl? Rebol? Python? Ruby?

~~~
jimbokun
Perl, Python and Ruby all have outstanding communities.

Would you care to argue that the Lisp community is better than any of these?

~~~
mahmud
Yes, _I_ would argue. It's refreshing to drop in #lisp and ask any technical
question, of whatever magnitude, and get answers immediately.

I recommend that place to any intelligent students, researchers, language
weenies, compiler hackers and system engineers. Just be informed and don't ask
opinionated, loaded questions.

Elsewhere? meh, I am left to think my present company has just been introduced
to computing by its $LANG_MANUAL.

There is also a lot of childish fucking around and casual piss-taking that
doesn't happen among Lispers. If you expect an standing ovation because you
pushed something to github, fuggedaboutit. No one will be retweeting wisdom,
no one will like you on facebook, you will not be blogged about ..

Ever wonder why Lispers, and most adult programming communities don't have
"Rock Star" celeb provocateurs?

~~~
randallsquared
_There is also a lot of childish fucking around and casual piss-taking that
doesn't happen among Lispers._

Maybe not anymore, but that stuff used to happen very regularly on
comp.lang.lisp during the years I paid attention to it (2003ish through
2006ish, maybe).

~~~
mahmud
CLL is the elephant graveyard of Lispers. It's where old hackers go to die.

It's a messy place to be, but there are some ivory treasures to dig up.

------
mark_l_watson
I have a perspective on this: I have been using Clojure for work over the last
5+ months but I am also setting up my laptop to finish writing a Common Lisp
book while I travel over the next month.

Using Clojure is definitely a nice experience and I am really excited by the
future of Clojure as the infrastructure for the language evolves.

However, after hacking Common Lisp for a few days, I have to say that the
tools are so very good.

I find myself preferring Clojure the language but prefer the tools and
programming environment of Common Lisp.

~~~
vdm
Are you talking about Emacs or non-Emacs environments, when you say you prefer
Common Lisp's?

I keep trying to tame Emacs enough to use it for Clojure and find I spend too
much time on Emacs and not enough on Clojure, which is what motivates me in
the first place.

~~~
parfe
After a few false starts with emacs as an IDE I finally learned it via other
uses.

I recommend using Emacs for a more simple task. I started reading my mail via
Wanderlust (wl-beta package on debian) and using ERC to connect to freenode
(Now running rcirc.)

I know how irc works so my attention wasn't split too much and I was able to
pick up the emacs stuff quickly. Now I've expanded it to be my python IDE.

------
lukev
I'm glad that so many people find Common Lisp useful and practical.

I just wish they realized that at this point, _nobody else ever will_. It's
showing it's age. It's incredibly idiosyncratic. Noone _new_ is _ever_ going
to start loving it.

Clojure may only be a blip on the radar in the grand, glacial evolution of
LISP, but it's really, really nice that there's a featureful, modern lisp that
a 21st century developer can actually pick up, use, and enjoy.

~~~
mahmud
Hopefully, no one will read the cutest programming book since Starting Forth,
Conrad Barsk's "Land of Lisp":

[http://www.reddit.com/r/lisp/comments/dfpmq/no_starch_press_...](http://www.reddit.com/r/lisp/comments/dfpmq/no_starch_press_releases_a_sample_chapter_from/)

~~~
lukev
It does indeed look like a great book - but it doesn't really change the fact
that Common Lisp is fragmented and dated.

~~~
lispm
Really, LispWorks has its IDE ported to GTK+ and looks very nice under
Windows, Mac OS X and Linux/FreeBSD. Got concurrency, too.

I'm also looking forward to see the ARM port of Clozure CL mature with the
alpha version already running on an iPad.

~~~
lukev
But the mere fact that you actually need to point out that it (can) have basic
cross platform compatibility and concurrency is _proof_ that it's getting
dated. Modern languages assume that.

And that's only in the commercial implementation.

~~~
lispm
If you compare the features of LispWorks or Allegro CL with Clojure you will
find that Clojure has a very long way to go to match those offerings. Clojure
1.2 can't even display errors without exposing its Java nature. For a start it
lacks the error handling infrastructure of Common Lisp and the tools that
implementations provided on top of that.

No, concurrency is also supported by free CL implementations - like CCL.

~~~
lukev
I fully admit that Clojure tooling isn't where it should be, yet. But it will
be.

But the fact is that _despite_ its lack of mature tools, Clojure is more
newbie-friendly than CL. That should give CL advocates pause.

As for running on Java, yeah, that's part of what it (currently) is. It's a
strength and a weakness at the same time.

Once Clojure becomes self-compiling, we might see that change. I'm actually
working on a toy Clojure->LLVM compiler for my own education. There are enough
people who love Clojure but have a distaste for Java that I expect we'll see a
native version of Clojure in the next few years.

~~~
Xurinos
> But the fact is that despite its lack of mature tools, Clojure is more
> newbie-friendly than CL.

As a newbie, I have to disagree. Clojure has a ton of syntax to get used to,
and to make it useful, you have to learn all the neat Java libraries on top of
it. I found more resources and nice explanations for aspects of CL, and when I
compare it against Clojure, I find I miss a lot of the nice functions and
tools for CL.

Here is a fun newbie point on it: In the first hour of playing with CL, I
learned how to debug it. Not so with Clojure. Trace? Step? Maybe I should be
using harder-to-find online tutorials for Clojure?

Anyway, it boils down to opinion as to what is "easier". I was looking for
something with batteries included that would compile to a distributable
executable and be super flexible; CL fit the bill with the sbcl
implementation. It successfully pulled me away from other fun languages, like
Erlang.

~~~
mahmud
If you're partial to the JVM, you can use ABCL:

<http://common-lisp.net/project/armedbear/>

I am in the middle of porting it to Android, but as is, you can use it to
write anything non-mobile/embedded, and it can call Java libraries just as
well as clojure.

------
masterponomo
The Lisp process to which the author refers is not as stately and merit-based
as he implies. In Scheme, the r6rs process was very difficult and divisive,
and many people voted in favor of it while very publicly holding their noses.
The r7rs process, if carried out as planned, will attempt to avoid the same
kind of damage and will result in two language: a sparse core language and a
featureful "practical" language. That larger more featureful language will be
the one that is more useful outside of language research, and it is also the
one that will change more over time, shielding the core language from the need
to change. Scheme purists can stick with the core. Non-purists can embrace the
featureful languages such as r7rs-plus (or whatever it will be called),
Racket, and Clojure. Anointing CL or Scheme (core) as the final arbiter of the
value of a language feature is tantamount (bucket list item #73: use
"tantamount" in a sentence; check) is OK if it works for you, but it certainly
wouldn't work for a lot of working programmers.

~~~
ohyes
[OT aside/ignore]

"Anointing CL or Scheme (core) as the final arbiter of the value of a language
feature is tantamount (bucket list item #73: use "tantamount" in a sentence;
check) is OK if it works for you, but it certainly wouldn't work for a lot of
working programmers."

<http://www.merriam-webster.com/dictionary/tantamount>

To check it off the bucket list, I believe that you have to use it properly.
It has to be tantamount to something.

~~~
masterponomo
Sheesh. I interrupted myself with my parenthetical expression and didn't
finish the tantamount thing. Worse, now I don't remember what it was
tantamount to.

------
fogus
I guess the thing that annoys me more than anything about this blog is that
the author often has great posts, but is a tangle of contradictions. For
example, Clojure is bad because it ignore Common Lisp (nevermind that many of
its features are inspired by CL). History is good and we should stop trying to
create new things. The blog author is _also_ creating a new Lisp. People
should stop creating minimal Lisp implementations (history is now bad?). The
more you read this blog the more these types of things pop up. However, I get
the impression that often he's taking the piss and that's why I continue to
read.

------
pwpwp
Don't take it too seriously. It's a kinda stupid rant. (I wrote it.)

~~~
hga
A very ... let me say, ahistorical rant, starting at the very beginning:

" _Lisp gets lexical scope right, for example, simply because we have a head
start of decades over the [line out]competition[/line out] others._ "

Case in point: LISP _didn't_ get this right in 1958 while apparently in the
same year (as I read Wikipedia) ALGOL did. This caused a _lot_ of grief which
wasn't resolved until 1983 when Common Lisp adopted Scheme's ALGOL inspired
lexical scoping. And Emacs Lisp and AutoLISP (AutoCad), two very big (in terms
of real world usage) Lisps are dynamically scoped.

Lisp has much to be proud of, but this could easily be the single worst aspect
of it historically.

~~~
lispm
ALGOL did, but it had it easy, because it was not providing closures and
garbage collection. When ALGOL had lexical scoping, these things were
unresearched. It took a while in the Lisp and FP community to solve this (see
the FUNARG problem).

~~~
hga
LISP wasn't providing closures at that point (1958), was it?

I've read that the LISP community was the only major part of the FP community
that had trouble with this and that the other parts were always confused about
why this caused such consternation with LISP.

~~~
lispm
No language had lexical closures in 1958. ALGOL had lexical scope, but not
closures. So their part was easy. On a language level all the consequences
were explored with Scheme in the 70s. Before that their were individual
solutions found to create closures.

Read the history of the FUNARG problem (1970).

FP languages came up later. The first ML appeared in something like 1972/1973.
I'm not sure if that had lexical closures. I doubt that. The Lisp community
was one active part of the FP community that detected the problem and
eventually found a solution. Scheme was the first language to demonstrate that
(1975). Other FP languages also went that route (ML, where the first ML was
implemented on top of Lisp, IIRC). The MacLisp branch took some time to adopt
lexical closures. First a special construct was introduced to create a
closure. In some other implementations the compiler was using lexical scope,
but not the interpreter. Common Lisp was then in 1984 the next major Lisp
dialect that settled for lexical scope (incl. closures) for both interpreted
and compiled code.

The Lisp community (other than Scheme) had substantial code at the end of the
1970s, so there was some reluctance to move to lexical closures. Lexical
closures also made the implementation a bit more difficult. The interpreter is
simpler without them. There were also performance issues to overcome.

------
mhd
This article makes it seem like Lisp is in a state of continuous evolution. In
which case I don't see a good enough argument why Clojure isn't part of that.

Even more so, it kinda reads like there's one huge mainstream evolutionary
branch of Lisp since time immemorial, and off-shoots are quickly reabsorbed
into this. Never mind the multitudes of lisps and especially the constant
Scheme-CL schism…

I understand perfectly why fans of Common Lisp won't switch, but considering
CL as the head of a constantly evolving Lisp with a capital L seems a bit
silly.

There's either no "Lisp", or Clojure is as much a part of it as CL is.

~~~
rwl
> This article makes it seem like Lisp is in a state of continuous evolution.
> In which case I don't see a good enough argument why Clojure isn't part of
> that.

That's because the author isn't saying that. The point is more like this:
Clojure is a series of new mutations, and they haven't been around long enough
yet to tell whether any of them will survive natural selection. We can't tell
Clojure's good ideas from its merely new ideas at this stage; we have to wait
for evolution to take place. That doesn't mean Clojure is doing something
_wrong_ (after all, "Everyone should be writing new Lisps!"). I think the
author is just saying it's not worth getting too excited about until we know
what it's doing _right_.

~~~
mhd
The problem with evolution in general is that it doesn't select the best
approaches, it selects the most popular ones. So if you ignore the current
'mutations', you're basically trust that the community will "do the right
thing". Which I regard as rather optimistic (as is the assumption that it
always did this in the past).

~~~
rwl
> The problem with evolution in general is that it doesn't select the best
> approaches, it selects the most popular ones.

Not sure what you mean by this. At least in a biological setting, natural
selection selects for `adaptive' features, i.e., those which best solve some
problem that an organism has. (OK, it's more complicated than that, but let's
take that as a working definition.) It does not select `popular' features.
Rather, features _become_ popular because they are adaptive and hence selected
for.

Now, programming language evolution may not always work like biological
evolution, and in both cases there may be other selection pressures at work.
But I don't see a reason to think that, insofar as programming language
evolution _is_ like biological evolution, the `natural selection' of language
features by the community would favor what's arbitrarily popular, instead of
what's best at solving a common problem.

------
kylecordes
I am not really sure whether this is an interesting critique from a broader
Lisp perspective, or a stunningly epic troll to get traffic by enraging
Clojure folks.

From my point of view:

* Other LISPs I have tried are not very amenable to practical usage in a modern software ecosystem. Not impossible, just a difficult fit. Could this be fixed? Sure. Why hasn't it been fixed? No idea.

* Clojure is a very practical LISP today, which drops very easily in to a modern software ecosystem.

~~~
fogus
> or a stunningly epic troll to get traffic by enraging Clojure folks.

You'll be forever wanting if your goal for website traffic revolves around
enraging Clojurians. First of all, there are not enough of us (yet), and
second we tend not to get drawn into these types of arguments. I guess we're
too busy trying to build a great programming language. ;-)

------
mahmud
The entire article rests on the false premise that Clojure is not a Lisp.

~~~
lispm
Depends on what you define to be Lisp.

If Lisp is the line of Lisp, Lisp 1.5, MacLisp, Lisp Machine Lisp to Common
Lisp, then Clojure is not in that line. In Common Lisp I can run 50 year old
code with relatively little change. CAR, PROG, ..., are still there.

If Lisp is the larger family of widely incompatible languages like Logo,
Dylan, Racket, Arc, NewLisp, then Clojure is a part of that family. But they
share very little - not even the syntax. Clojure is completely incompatible to
any of them - but that's true of each other.

~~~
mahmud
Yeah, I am a big-umbrella Lisper. I am confident any Lisp programmer can pick
up Clojure and be productive in it within a week.

Dylan, Logo, Racket .. used them all three. Arc, I use it several hundred
times a day, but never wrote a line in it. Clojure, a good Lisp.

NewLisp? No thanks.

------
shawndumas
A lot of programmers are either inapt or inept at making their own
"batteries"; let's call them b-group programmers. Clojure's main draw over
lisp (as I see it) is the JVM and all of the work that a-group programmers
have contributed. It's lisp, with most[1] of the allure of an almost
mystically powerful succinctness, but with batteries included.

I contend that while batteries are, in the short term, a big help to the
b-group it would be better for _the programmers_ to look into whether or not
they have what it takes to move into the a-group. One will never fail to learn
a ton walking the hallowed halls of the a-group's code trying to figure out
how that formerly black box does it's magic.

Where I currently work, for better or worse, the micro-development manager has
forbidden the use of JavaScript libraries. The net effect has been that some
developers have left/been let go and the ones of us that have stayed have had
to learn to roll our own.

pg said it best: "Powerful libraries are a cheap way to make a new language
the language du jour. (Think Rails.) They're not the critical ingredient if
you're trying to make something to last; they may even hurt."

[1]: no CLOS, no Tail Call Optimization, etc...

~~~
jacquesm
> Where I currently work, for better or worse, the micro-development manager
> has forbidden the use of JavaScript libraries. The net effect has been that
> some developers have left/been let go and thous of us that have stayed have
> had to learn to roll our own.

I don't think that kind of 'NIH' is very productive in the longer term but it
must be a great place to work if you're _encouraged_ to re-invent the wheel.

Most places would try to avoid such a waste of resources. Maybe there would be
a way to convince him of rolling your own company specific OS?

~~~
shawndumas
As we are now discussing my current employer and boss's decisions third party
-- and given the accessibility and permanency of the web -- all I am
comfortable saying is that, in the long run, having stronger developers that
throughly know their code-base _can_ be a huge win.

~~~
jacquesm
Yes, I agree, it can be. It very much depends on the circumstances though, for
most companies rolling your own ORM, framework, javascript libraries, database
and so on are simply not an option, they'll be hard pressed to keep up with
the demands of running their business.

Great stuff can come from that though, for instance, Django.

~~~
shawndumas
Maybe that's why a lot of things like 20% projects, in-house text processing
capabilities (troff), and PARC projects come from large, established
companies.

------
fauigerzigerk
Well, I'm just going to wait and see how that entire new fangled computing
thingy plays out over the coming centuries. If it's any good, it will become
part of evolution and our genes will use it eventually ;-)

------
prototype56
Feels like a rant. Which doesnt even point out what exactly is wrong and how
could have been done right.

