Thumbs Down for Clojure
Historical note (Jan. 7, 2014) - This ancient post still gets several hundred to a thousand page views per month! And, unsurprisingly, the Clojure community still replies to the criticisms therein with... only insults. This is what comes of a product fundamentally brain-damaged at birth.
I find Clojure revolting.
It is the most explicit to date abandonment of the age-old Lispers' Dream, "Lisp All The Way Down." Clojure is the antithesis of the Lisp Machine. Instead of a crystalline pyramid of comprehensible mutually-interlocking concepts, behind every Clojure primitive there lurks Black Magic. The Clojure user who is missing some routine or other will run crying to Java for help, rather than implementing the feature himself correctly - that is, as a natural part of the entire language, built on the same concepts. Clojure pisses on everything I've ever loved about Lisp. It rejects even what little consistency and intellectual rigor there is to be found in an abomination like Common Lisp.
Clojure is the False Lisp, which Reeketh of the Cube Farm. A Lisp unworthy of the name; one which encourages users to pepper their code with calls to opaque routines having no underlying Lispiness. A Lisp which barfs Java stack traces. It promotes - no, mandates - the use of undigestable foreign matter in Lisp code: primitives on which you cannot pop the hood to reveal intelligible innards.
I don't care if everybody really is more productive in Clojure than in Common Lisp. The latter is not my standard of comparison (Symbolics Genera, the state of the art, is. Or, if you want something that is distinctly inferior but is currently available on the market: Mathematica.) Clojure is the gutted and zombie-reanimated corpse of a dream.
The cult of Good Enough which seems to pervade all of modern computing has finally chewed its way through to the Lisp community, with Clojure as the result. I am tired of this abomination being hailed as the future of Lisp. Aficionados of real Lisps, such as myself, will keep hoping, dreaming, and working on systems which do not betray the original virtues of the language.
Symbolics Genera remains the gold standard of programming systems. Though largely forgotten, it can never be un-created. My standard of comparison for any technology will always be everything previously achieved by mankind, rather than what is available on the market today.
Edit: Update.
[...] Clojure introduces new problems(ok ‘challenges’ if you will) having discarded enough of the last half-century of Lisp progress. Sure, Common Lisp has it’s problems but hailing Clojure as it’s future is a new low in the community. Another lisper put it so bluntly : “Clojure is the gutted and zombie-reanimated corpse of a dream.” [...]
Posts like these are the reason I was never interested in being a part of the CL community. If you want this dream to come true, start playing the fucking game.
Dear Kevin,
And which game would that be? The one where people compete to see who can write a more pathetic cheap imitation of Common Lisp?
Yours,
-Stanislav
No, it's the one where you make Common Lisp libraries that solve real problems.
Common Lisp is amazing. I too wish it were better, but most of its libraries are undocumented, half-implemented hacks that take more effort to use than the imperative counterparts that they are mimicking.
I can't build usable software in CL in anywhere near as short a time as I can with Java, let alone Clojure, and that may speak little for my programming skills, but we can't keep point at twenty years ago saying, "Look, Lisp is better" when it hasn't actually done anything within the last five.
Dear Daniel,
> most of its libraries are undocumented, half-implemented hacks...
This has not been my experience. Not in the last five years, anyway.
> I can’t build usable software in CL in anywhere near as short a time as I can with Java
Common Lisp is a Stradivari violin, not a kazoo. It simply isn't for you - you have just admitted as much. Go learn a different respectable trade, where you might be able to fully appreciate high-quality professional tools.
> [Lisp] hasn’t actually done anything within the last five.
You know, your problems might stem from the fact that programming languages are not actually alive, and cannot do anything on their own.
If you want to know why Lisp doesn't win around you, find a mirror.
Yours,
-Stanislav
Stanilas,
I do not know your age but I can tell that you live in the past. Symbolics Lisp machines were still
around when I started to work (after I spent a few years on the school benches).
They eventually disappeared, superseeded by ( I agree 100%) "low" quality solutions,
sorry but that's a fact of life.
I tried several times to get a product to market using Lisp in the last 10 years, being fed up of
Java and alikes.
The library issue in Common Lisp especially has been a pain in the ass during all those years, facing
either non existent non existent librarieis or in the wrong "dialect".
There was always mising pieces, fixing all of these within a product delivery cycle just
shut the business case down.
Now we have a product up in Clojure running happily since Jan. 2009. It solves a complex
problem in a minimum code base. Libraries ? Java has plenty and investing to recode this low level
stuff is not worth it. Using them from Clojure is a charm. We have a one to ten code line ratio
compared to other solutions and the remaining code is much more powerful than it's Java or
similar equivalents.
We can focus on the important features that boosts the product value up and leave the mundane
stuff out of the task grid.
Over the last 30 years, I focussed on delivering working solutions using a variety of languages and
solutions. I got my frustration out this way and it's been paying off through all these years.
You seem to be stuck in some purgatory from what I can see in your posts.
Maybe you should change your assumptions instead of sticking to fossilized tools.
Jurassic Park is science-fiction...
Luc P.
Dear Luc P.,
> I do not know your age but I can tell that you live in the past. Symbolics Lisp machines were still around when I started to work
I'm 29. My Lisp machine is second-hand.
> They eventually disappeared, superseeded by ( I agree 100%) “low” quality solutions, sorry but that’s a fact of life.
Fuck your so-called "facts of life." Superior mind-amplifying tools existed and will exist again.
> The library issue in Common Lisp especially has been a pain in the ass during all those years, facing either non existent non existent librarieis or in the wrong “dialect”. There was always mising pieces, fixing all of these within a product delivery cycle just shut the business case down.
Yiddish saying: "the bad dancer is hindered by his own arse."
"If you want to know why Lisp doesn’t win around you, find a mirror."
> Now we have a product up in Clojure running happily since Jan. 2009.
Good for you.
> You seem to be stuck in some purgatory from what I can see in your posts. Maybe you should change your assumptions instead of sticking to fossilized tools.
Common Lisp is paying for my dinner and the roof over my head. And has been for a while. Go shove your assumptions into the place where they belong. It is your tools - the quasi-static, batch mode (anything other than Common Lisp + SLIME, or possibly Mathematica) languages which are really fossils.
Yours,
-Stanislav
29 years old ? That explains a lot, weak notion of history => bad perception of future trends.
Funny that you are crazy about a language that I was using while you were crawling around
wearing diapers... and I mean really crazy 🙂
You are fossilized in time around the end if the 50s and you were not even born ?
Bad karma ? Reincarnation hell ?
Wether you like it, Clojure is a Lisp and offers much more than Lisp used to offer in the past.
I doubt you will ever undestand that however, your horizon is the same as a fly,
three feet wide and you seem to be unwilling to enlarge it.
Have a nice life in your mental dungeon...
Dear Luc Prefontaine,
> 29 years old ? That explains a lot, weak notion of history => bad perception of future trends.
If I tell you that I have studied (and used under emulation, when available) nearly every major historic Lisp system, would it make any difference?
You have already decided to prepare an insult, and you wished to know my age so that you could decide whether to call me a doddering senile vegetable or an ignorant child.
My impression is that you came better-prepared for the "doddering vegetable" scenario. My apologies, then, for catching you with your pants down.
As for trends, why should I be concerned with them? The fact that you mention trends at all is rather telling. It would appear that the world as you see it contains no sentient beings able to go off on their own paths, but only ants who follow the pheromone trails of other ants around in a circle forever. That is the world of YCombinator types and other trendoids: an idiotic fashionista hell.
> Funny that you are crazy about a language that I was using while you were crawling around wearing diapers… and I mean really crazy 🙂
The dishonest implication here is that you moved on to something better, rather than accepting an inferior substitute for the truly-interactive computer which once existed, and then lying to yourself (and others) about it. Take heart, for you are in good company. See, for instance, this great luminary's cowardly surrender to cultural decay:
"6.001 had been conceived to teach engineers how to take small parts that they understood entirely and use simple techniques to compose them into larger things that do what you want. But programming now isn’t so much like that, said Sussman. Nowadays you muck around with incomprehensible or nonexistent man pages for software you don’t know who wrote. You have to do basic science on your libraries to see how they work, trying out different inputs and seeing how the code reacts. This is a fundamentally different job, and it needed a different course."
Or better yet: Dan Weinreb (one of the original designers of the MIT and later Symbolics Lisp machines), in his old age penned this masterpiece of idiocy about the OLPC being "the next Lisp machine." I can't really blame Weinreb for his wishful thinking: his life's work had been destroyed by morons. Even having become a millionaire at ITA cannot compensate him for this. But what is your excuse?
> You are fossilized in time around the end if the 50s and you were not even born ? Bad karma ? Reincarnation hell ?
It is the users of batch-processing (edit, compile, pray, debug cycle) programming systems who are fossilized. Interactive, fast computers now exist, and virtually every programmer seems to remain unaware of this.
> W[h]ether you like it, Clojure is a Lisp and offers much more than Lisp used to offer in the past.
Which Lisp, and which past? Have you ever seriously used an MIT, Symbolics, or TI Lisp machine? Xerox Interlisp? Current SBCL with SLIME?
> I doubt you will ever unde[r]stand that however, your horizon is the same as a fly, three feet wide and you seem to be unwilling to enlarge it.
If you and the other Clojure enthusiasts were content with narrowing your own mental horizons (accepting a Lisp which barfs Java stack traces, encourages the use of Java's static data structures, introduces questionable pseudo-innovations like immutable data, etc.) I would care not a whit. You will not find a "Thumbs Down for Python" essay in this blog, because Python users make no attempt to peddle their crock of shit as "the future of Lisp." I have no quarrel with users of Python, Ruby, Dylan, and other shoddy "infix Lisps." Because they are honest.
It is the lying of Clojure users which upsets me, and their deliberate attempts to rewrite history, to make people forget that truly-interactive, advanced Lisp systems once existed.
I understand making technological compromises. I understand driving a "junkyard wars" vehicle when a Toyota cannot be had for whatever reason. But don't lie and call your rattling heap of junk "a modern Toyota."
Do you wonder why this thread is still active after three years? Why it is often found among the top Google hits for the word "Clojure" ? It is because everything I said here is true, and the Clojure enthusiasts know it. The truth hurts, doesn't it? You know, I don't actually care what kind of lies you have to tell yourself to stay sane. But don't lie to children and other neophytes and tell them that Clojure is a "modern Lisp." It won't work, if only because I intend to personally see to it that everyone finds out just what a modern Lisp looks like.
> Have a nice life in your mental dungeon…
I will have a nice life in my mental palace.
And Clojure is still a turd, though you call it sausage and eat with relish.
Yours,
-Stanislav
This is, indeed, the heart of the issue--the dogma spreads to represent communities they are not a part of
On a similar note; I am currently working on a specification for a future Lisp dialect, which, if I am worthy, I hope to eventually implement (and I am willing to take criticism). I would like to share it with you, Stanislav, but I do not know your email address. Could you send it to the email under my name here?
Dear Cosman246,
Here.
Yours,
-Stanislav
"No true Lisp would ever be built on top of something else."
"No real Lisper would ever use something so tragically impure."
Reminds me of this.
Your last post shows how little you know about Clojure.
It's dynamic, we rarely restart a JVM when coding/testing. No incessant redeploys...
There is no edit, compile,debug,... cycle. The fact that the Clojure is compiled on the fly
to byte code has no impact on how you work.
Our app loads code on the fly according to the current configuration and it's all evaled on the fly.
So far for your assertion that Clojure is a static world. If you thunk down to Java, of course
you end up with the Java limitations. They have nothing to do with Clojure. If you avoid coding
in Java you avoid these issues. Using Java libraries from Clojure is not a problem most of the time except
a few that have been ill defined from the start.
Debugging has improved a lot either through IDE standard JVM debuggers or more Clojure oriented ones.
Stack traces can be filtered out so they look a bit more friendly. I agree some improvement
would be welcomed here (albeit some Clojure libs exists to prune these a bit)
but after a while you get familiar enough to find the root of the problem quickly enough.
As of persistent immutable structures, it's obvious that you did not code enough multithreaded
applications to understand the value of having mostly immutable data in your code.
This last post from you indicates clearly that your horizon is limited and you are allergic
to new ideas and cannot bring facts and rationale to your statements.
It's fine to criticize if you can bring some rational reasonning at the table.
Right now you look more to me as a Taliban than nothing else. Dogma, dogma, dogman and no
inclination for facts.
I stop here, I have other things to carry this week and I think your need to slack your horse
blinders a bit before any significant discussion can happen.
Luc P.
Dear Luc prefontaine,
> Your last post shows how little you know about Clojure.
Your arguments show how little experience (or memory thereof) you have with genuine, interactive, conceptually-consistent Lisp systems.
> It's dynamic, we rarely restart a JVM when coding/testing. No incessant redeploys... There is no edit, compile,debug,... cycle. The fact that the Clojure is compiled on the fly to byte code has no impact on how you work.
Take ten minutes to watch this video of Symbolics Genera. That is what actual dynamicity looks like. But if you still want to abuse the word and apply it to environments where one must edit an ASCII text file and feed it to a compiler after each change is made, go right ahead. Perhaps you can fool someone else, but you won't fool me.
> Our app loads code on the fly according to the current configuration and it's all evaled on the fly.
> So far for your assertion that Clojure is a static world. If you thunk down to Java, of course you end up with the Java limitations. They have nothing to do with Clojure. If you avoid coding in Java you avoid these issues. Using Java libraries from Clojure is not a problem most of the time except a few that have been ill defined from the start.
It is quite impossible to work in Clojure without having any contact with Java and the JVM. You know this well. Clojure barfs Java stack traces. Clojure errors produce no meaningful Clojure-related information! Clojure does not even have a condition and restart system. And, the way it is designed, it appears that it is fundamentally incapable of being retrofitted with such systems.
> Debugging has improved a lot either through IDE standard JVM debuggers or more Clojure oriented ones.
Let me know when a Clojure system which halts on an error does something other than crash and spew JVM crud at me.
> Stack traces can be filtered out so they look a bit more friendly. I agree some improvement would be welcomed here (albeit some Clojure libs exists to prune these a bit) but after a while you get familiar enough to find the root of the problem quickly enough.
You are now comparing "filtered" Java stack traces to Common Lisp's condition system? Fine... I will dine on chocolate ice cream while you eat "filtered" liquid shit.
> As of persistent immutable structures, it's obvious that you did not code enough multithreaded applications to understand the value of having mostly immutable data in your code.
Having spent some years working on massively-parallel scientific computation projects, I am finding this conversation hilariously funny.
> This last post from you indicates clearly that your horizon is limited and you are allergic to new ideas and cannot bring facts and rationale to your statements.
Pray tell, just what are the "new" ideas in Clojure? The idea of setting up an ersatz Lisp on top of the JVM is not the least bit new. Neither is immutable data.
> It's fine to criticize if you can bring some rational reasonning at the table.
Neither you nor the other Clojure enthusiasts appear to be interested in rational discussion. This is because a rational analysis of Clojure (vs. Common Lisp on an x86 PC, not even talking about ZetaLisp or InterLisp) would leave the Clojure users crying and hating their lives within five minutes.
> Right now you look more to me as a Taliban than nothing else. Dogma, dogma, dogman and no inclination for facts.
Look in the mirror.
> I stop here, I have other things to carry this week and I think your need to slack your horse blinders a bit before any significant discussion can happen.
Exactly why are you here, on this site? There is such a variety of other things to read.
Yours,
-Stanislav
Bonsoir Stanislav !
Permettez-moi d'employer le français, je parle très mal l'anglais.
Votre position m'intéresse beaucoup, vous semblez très bien connaître le sujet !
Je recherche un vrai bon Lisp, Mais, plus je cherche et moins je sais vers quel Lisp me diriger ?
Pouvez-vous me conseiller et m'indiquer une adresse de téléchargement d'un vrai bon Lisp ?
Merci pour votre réponse.
Lydia
Dear Lydia,
SBCL.
Yours,
-Stanislav
All of the arguments above have basically been idealism vs pragmatism.
Yes lisp machines are epic, no one disagrees. However clojure makes more sense in the context of legacy software. No matter how shitty it is, we have a decade's worth of java libs which can't just be thrown away. For many java guys clojure is a godsent because it's a way out.
Your position seems to be "my lisp or no lisp" which is quite childish.
Dear ilia,
> No matter how shitty it is, we have a decade’s worth of java libs which can’t just be thrown away.
We also have four decades of COBOL code which can't just be thrown away. When do we get COBOLISP, the marvelous Lisp of the Future built on top of and freely intermixed with COBOL? I'm waiting eagerly.
Why no hype over Armed Bear Common Lisp, which predates Clojure and interoperates with Java in a similar way? The answer is simple: ABCL had no hype-master to push it, and thus no hipster community to mindlessly take it up.
> Your position seems to be “my lisp or no lisp” which is quite childish.
My position is that lying is wrong, and that a turd is still a turd even when you call it sausage and eat with relish. Clojure is being pushed by its enthusiasts as "the new, modern Lisp," which is a bold-faced lie. See this.
Yours,
-Stanislav
> We also have four decades of COBOL code which can’t just be thrown away. When do we get COBOLISP, the marvelous Lisp of the Future built on top of and freely intermixed with COBOL? I’m waiting eagerly.
Lets imagine a cobolisp *shrug* had existed and recieved as much attention and acceptance as clojure is currently getting (work with me here). Functional programming/lisp might have been mainstream by now. No matter how much I cringe at the idea of such a disgusting crossbreed, it would have been worth it. I hate memes, but I think this one conveys my opinion perfectly http://axisofeval.blogspot.ca/2012/07/when-somebody-says-but-clojure-will.html
Either way, COBOL has been around much longer than it should have due to legacy codebases. It's a problem that didn't get solved and I see clojure as a pretty good attempt at tackling the identical situation that currently exists with java.
> Why no hype over Armed Bear Common Lisp, which predates Clojure and interoperates with Java in a similar way? The answer is simple: ABCL had no hype-master to push it, and thus no hipster community to mindlessly take it up.
I'll be honest and say I didn't know about ABCL. But I think 'hype-masters' (or evangelists as some like to call them) are pretty essential for any new language.
I do partially agree with you on this one, but at the same time I'd rather have fad obsessed hipsters pick up a lisp (no matter how big of a 'turd') than the next imperrative counterpart. Crappy lisp is better than no lisp and if you disagree we're back at idealism vs pragmatism.
> My position is that lying is wrong, and that a turd is still a turd even when you call it sausage and eat with relish. Clojure is being pushed by its enthusiasts as “the new, modern Lisp,” which is a bold-faced lie. See this.
There's a big difference between lying and having a different opinion. But I don't really see the problem, I don't hear people claiming that it's a "new BETTER lisp". Modern is a very subjective and ambiguos term.
I did initially share some of your feelings toward clojure. It felt fake, as if I was using some type of nasty hack. But I've come to like it very much.
Dear ilia,
> Functional programming/lisp might have been mainstream by now.
Why do you assume that I believe this to be a positive thing? It isn't, in my view. Professional tools, placed into the hands of idiots, inevitably degenerate.
> Crappy lisp is better than no lisp
This is where we disagree. When an inferior substitute for a given technology is passed off as the real thing long enough, the genuine tech is slowly forgotten. It gets, if you will, "un-invented." I see no reason to cheer this process on with regards to Lisp.
Yours,
-Stanislav
I have to say, although I like Clojure, you have a very good retort to Luc's rather moronic criticism. I can't stand age-based criticism; it's a weak form of arguing.
Hi Nick,
it's not about age, it's about experience.
I was using Emacs and Lisp on DEC-10/20s while Stanislav was not even crawling around wearing
a diaper.
I went through several evolutions in the software industry. I think I know a bit what changed,
what failed and what succeeded. I coded complex systems during all these years using a dozen
different languages and several platforms. I still code actively everyday.
I worked with Cobol. Fortran, Pascal, C/C++, several assemblers, ...
Today, I work with linux, Ruby, Clojure and Java (less and less btwy).
I am an implementer, I appreciate tools for their net worth. Theories are great and necessary
but ultimately, implementations are the only metric by which we can judge merits.
Lisp machines are dead, Lisp has not been catching up on the market (which I regret),
being nostalgic about Lisp's "perfection" is not getting the software industry anywhere and
does not help address the next evolution step.
If Clojure is an imperfect implementation according to some theorists but still gets people on board
and solve real world problems more efficienctly than other main stream tools then why not ?
Clojure is a practical answer to real problems and presents an affordable learning curve to
this bunch of people that Stanislav seems to qualify as morons. They will eventually be exposed
to concepts that are now alien to them and it may save some from hell. The fact that Clojure
blends such concepts in a smooth way makes them much more worthy than when these features are
singled out. I never said that Clojure implemented new concepts, it's the recipe that makes this
interesting from an implementor's point of view.
I did not want to critic based on Stanislav's age, I wanted to emphasized its lack of various experiences.
I consider Clojure a significant step based on practical experiences not based on some
religious fanatism.
With "aging" comes questions like how do you maintain your edge, your interest and your efficiency ?
How do you make this time left worth more than the time behind you ?
The choice of tools becomes more important as you age. Lisp could be great but it's not an option
for an implementor these days except in rare circumstances.
Live long enough, try different tools in big projects (essential) and do some introspection along the
way. Eventually you will understand that reality always catches up.
Luc P.
[...] Loper is not happy: Clojure is the False Lisp, which Reeketh of the Cube Farm. A Lisp unworthy of the name; one which encourages users to pepper their code with calls to opaque routines having no underlying Lispiness. A Lisp which barfs Java stack traces. It promotes – no, mandates – the use of undigestable foreign matter in Lisp code: primitives on which you cannot pop the hood to reveal intelligible innards. I don’t care if everybody really is more productive in Clojure than in Common Lisp. The latter is not my standard of comparison (Symbolics Genera, the state of the art, is. Or, if you want something that is distinctly inferior but is currently available on the market: Mathematica.) Clojure is the gutted and zombie-reanimated corpse of a dream. The cult of Good Enough which seems to pervade all of modern computing has finally chewed its way through to the Lisp community, with Clojure as the result. I am tired of this abomination being hailed as the future of Lisp. Aficionados of real Lisps, such as myself, will keep hoping, dreaming, and working on systems which do not betray the original virtues of the language. Symbolics Genera remains the gold standard of programming systems. Though largely forgotten, it can never be un-created. My standard of comparison for any technology will always be everything previously achieved by mankind, rather than what is available on the market today. Source [...]
https://groups.google.com/forum/?fromgroups=#!topic/clojure/BJQ3l6dL4V8
Not to hate on Clojure (as I'm trying to learn it) but this struct me as odd when I read it. As a hosted language some "unspecified" behavior depends on the host. So in the JVM (+ 1 "er") and (+ "we" "er") returns errors but in Clojurescript it returns "1er" and "weer". And what surprised me the most was the position of Rich Hickey:
"(+ "we" "er") is a user error.
We rely on the runtime type system of the host to efficiently detect
type errors. ( ...) Nowhere does Clojure promise that all user errors will become
exceptions, and it is a constant balancing act to add more checks
without compromising the performance of correct programs."
Just my 2c.
you're post is high on google, because it is interesting and controversial. I was laughing as i read this thread. thanks for entertaining me.
I do not have much experience with lisps (yeah, i read some clojure things, still trying to set that up. might help save time in the long run). I do have some with mathematica. It is a computer algebra package. it may be a programming language, technically. but If mathematica is a programming language, then superlogo is too. superlogo is also a kids' toy 😉
mathematica is a very useful tool for mathematicians. and it's a great program. finally something that allows you to enter a formula, view it and evaluate it, solve it, whatever.
if you like it so much and prefer it over common lisp, maybe you could find work in it. every student knows mathematicians hate to do computer work . they haven't even discovered the benefits of microsoft powerpoint yet. I guess they could use an assistant.
Dear Tim,
Re: Mathematica: I used it professionally for a rather long time. And then quit. To learn why, see: this and this.
Yours,
-Stanislav
Wow. This is absolutely hysterical. Sorry dude, Clojure won. Get over it.
Dear Michael Ellis,
Actually, PL/I won. That is to say, it is more widely used than Clojure, and I personally know of people earning six-figure sums (U.S. dollars) solely because they are willing to program in it.
But if you were speaking of the idiot trendoid crowd, yes, Clojure "won" there. That's what prompted this article. Now kindly return to your heathen-pit.
Yours,
-Stanislav
Well, I read this post a year (or more) ago, and now I disagree with it even more.
First of all, the fact that Clojure compiles to JVM bytecode isn't unlike how every language implementation produces some sort of bytecode or compiles down to machine code. Second, while Java may suck, the JVM isn't bad - it's fast, good for concurrency, reliable, and runs everywhere. OpenJDK also has the patronage of Oracle, IBM, Red Hat, Apple, SAP, and others...
Also, I'm just looking at the tools available to Clojure programmers. Emacs with Swank, Light Table, Catnip - all interactive REPLs that enable you to edit code on the fly. I use Catnip myself - it's open-source, dead simple to setup (unlike Emacs), and just works. Leiningen is also easily the best build tools I've ever encountered - it sets up a project, has a bunch of useful commands, REPLs, and it's dead simple to package your app into a single, self-contained .jar file.
While Clojure isn't as idyllic as the Lisp machines we love to reminisce about, it offers all the same practical benefits, and more. We have a language with which we can target literally any platform. The few places you can't use the JVM you certainly can use ClojureScript, which compiles to JS. And right now someone is writing a C implementation of Clojure.
Fact is, people are actually building stuff with Clojure. I can make desktop apps with Swing, games for the desktop or Android (there's actually a Clojure game published on the Google Play store, and it's very professional and fun!), or I can make web apps with Pedestal (which also uses a Datomic database, which itself is a product of Rich Hickey - Clojure's creator). Financial institutions and hedge funds use Clojure, and a diverse range of startups and individuals. Thankfully, it also seems like most of the hipsters moved on to Nodejs.
By the way, I wouldn't mind if a 'real' Lisp became the de-facto standard and your Loper OS took off. That would be fantastic. But right now, I need to eat, and program to get things done, and Clojure simply has a more compelling set of features and tools.
Evaluating (+ 2 "e") pukes some shit about casting to java.lang.Integer and clojure.lang.Numbers.add. It bukakkes you with Java errors that have no meaning and relation to the code you actually wrote.
No matter how practical or accepted, the language is still shit. And it's dangerous, since, with each passing blogger touting this monstrosity as the future of LISP, it actually will become the future of LISP. A bleak future, a future where LISP means Clojure and the marvel and beauty of true LISP environments is finally irreversibly forgotten.
More important i think is why everyone is hard to start programing languages its their crazy style.
Imagine (n = 1) in math 12 school years young peoples life it was a way of thinking.
In programing language it somehow became stupid (= n 1) wtf? in math it will be error! how you want teach kids of programing then language dont care of even basic math rules! and way of thinking? to learn another 12 years??
n = 1 has a very different meaning in Math from most programming languages. In most so called Imperative languages (note I despise the word) n = 1 assigns the value 1 to the memory location denoted by n, to do a comparison you need to use ==, in the so called functional languages n = 1 is a comparison, i.e. n = 1 tests whether n = 1 again this not in line with the Mathematical definition.
In Mathematics in 'n = 1', is not an assignment or even a comparison, it is a statement of a fact depending on the context it could mean introduce the symbol n with the value one or in the constant of an equation it states that n IS equal to one which depends on the context, if the equation is not proven it states that n possibly equals one. None of this correlates to the n = 1 or n == 1 in programming language except for Prolog where you are indeed stating a fact.
This I see no problem with (= n 1) furthermore you can chain comparions and do something like (= n x y z d) how would you do this in other popular languages with infix notation (n == x) && (x == y) && … how does that correlate to math?
You must really love lisp, judging from your well-written responses. I however am but a budding Lisper. I can't say whether Clojure deserves to be called a Lisp(your reasons, however passionately presented don't convince me enough). If there's one thing that would make me give Clojure, it would be, like you said, the Java stacktraces. It makes Clojure look half-baked and plain unintelligent. Why doesn't it have it's own error messages. When I look at those error messages, I can't but think that the Clojure compiler translated the the code to java, wrote a .java file than ran the equivalent of system("javac file.java");
Regarding to your rant, I thought Lisp had a compiler that works pretty much like any other language's, i.e in batch mode?
Dear Slevin,
Re: Clojure: Don't take my word for it; see for yourself how it is implemented. (As a thin layer on top of the JVM. Although several people have attempted saner stand-alone implementations, these are still stuck with the overall inescapable lameness of the language features, such as immutable data.)
Re: compiler: ANSI Common Lisp, interestingly, does not specify the exact behavior of the compiler. However, in a well-designed implementation (e.g. SBCL, my favorite) the compiler is present at runtime, and input to 'eval' actually gets compiled prior to execution.
Yours,
-Stanislav
I get that you wouldn't want to muck around with Java while you're trying to use Lisp, but if you're using Common Lisp then don't you still have to mess with FFI code and sometimes even the code you're using the FFI with? Is it just less common?
Stanislav, amazing post. Amazing responses to a wonderous amount of idiots.
It is such a welcome breath of fresh air to see someone put their foot down and call mediocrity for what it is ... enabling of nothing more than more mediocrity.
We too have new products based on Common Lisp and are quickly moving to Common Lisp being our defacto standard.
Hear hear.
I'm a clojure dev and I came back to this post after a year and I still find it quite refreshing. It makes me think about what else is out there. I came to lisp through clojure and I'm addicted - I'm looking at chicken and picolisp and loving what they do. Common Lisp still scares the crap out of me so I may take a look at that when I have more experience. I completely agree with many points in the post because those are shortcomings that could have potential solutions. my question is: is clojure fixable and how would you go about it?
Why does Common Lisp scare you? Its a big language, but other than that it is quite forgiving.
No, Clojure is not fixable. The whole design is bad, from bottom to top. When I first watched a talk by Hickey I liked some of his views. Since I work with Clojure I am quite angry with him. Every single design decision in Clojure is wrong. The good parts are those where Hickey was lazy and just copied standard Lisp behaviour.
I believe Hickey is a master troll and messed with us BIG TIME. Why? I don't know.
Hey, what do you think about red a dialect of rebol(similar to LISP)...
http://www.red-lang.org/ (read the contributions section)
The idea is to be red all the way down, what do you think?
Dear Jacob Goodson,
'All the way down?' Appears to mention 'Android'...
Yours,
-Stanislav
It mentions being useable on the android, you should not dismiss it because you saw the word android. It will use a bridge to work with the dalvik, other than that you don't need a jvm or eclipse to work with android at all while programming in red.
While I don't entirely disagree with the notion of purity that you seek in a lisp language, I do want to point out that I have never written any Java code, and this continues to be the case, even after using clojure now for several months to create some pretty fun software. So the notion that you must somehow incorporate java into clojure code is simply incorrect, you can do a tremendous amount with the powerful library built into clojure, that is written in clojure itself. No one should be turned away from clojure simply because of the notion they must also write or use Java code. Just wanted to point that out, as readers of this page should not be misled on that regard.
All other issues aside, one particularly useful feature of clojure is its default immutability, which I do believe natively encourages better program structure, reduces bugs, and makes the language easier to learn.
Well, I believe using Java is not really the problem, the problem is the fact that if you run into an error sometimes the program crashes with page loads of stack traces. The errors in clojure are contrasted to CL which are much easier to deal with since CL has a much better error handling systems.
Haha, this is hilarious! I always thought the Lisp fundamentalism was a myth, but now I know better. I hope the Clojure community will keep offend you with awesome software.
Dear Andreas,
I keep hoping to be 'offended with awesome software,' but instead I must settle for being bored with the tediously buggy variety.
Does your runtime still barf JVM stack traces?
Yours,
-Stanislav
Bugs counts are surely relative. If Clojure's JVM hosting was really that confusing for its practitioners, findings such as this: http://deliberate-software.com/safety-rank-part-2/ which show Clojure has the fewest bugs per commit of several major languages would be inexplicable. I'm not saying that Clojure is better than Common Lisp, simply that Clojure yields relatively reliable software.
Are there any ideas in clojure worth recycling, or is it exclusively an amalgamation of terrible ideas?
Dear Will Swiss,
If you ask me - the latter.
If you ask the users - the turd can magically turn into a delicious sausage if everyone gets together, pinches their noses, takes a deep bite, and plays 'weeaboo' like good prosocial kids...
Yours,
-Stanislav
Hey,
I really like your blog. Especially the posts on Engelbart's violin and on Symbolics are insightful.
Also, I am interested in Common Lisp since it seems like 'the right thing' and I like being consequent. Maybe I am pedantic, but I cannot quite understand why the naming of functions is comparatively inconsistent compared to Scheme or Clojure (in addition to some other inconsistencies listed here:
http://langnostic.blogspot.de/2014/01/what-lisp-should-i-learn.html ).
If Common Lisp is all about being consequent, wouldn't it make sense to streamline it a bit more?
Would you care to elaborate on why immutable data structures are such a bad idea?
I agree the java stack traces suck, but you really need to explain with more concrete examples of the horrible design decisions you claim exist in clojure.
The crux of the issue seems to me that the complaint is clojure (or perhaps even ABCL) is not a GOOD port to the Java VIRTUAL MACHINE. Is it that the JVM is just a really horribly designed machine that NO ONE could port to? Perhaps a better tack might be to develop a virtual machine to a lower level that takes advantage of some of the good things/otimizations that JVM has done and have a virtual instruction set that both the lispers (and clojureans) can live with, as well as the Java coders. In fact, perhaps a few other languages targeting that machine could be improved as well.
Virtually anything other than a lisp machine probably falls short of the perfect enviornment for lisp. I recall back in the day programming in PolyForth on LSI 11/23's (which was about as close to Forth in silicon as one could get at the time) being horrified at how many more instructions it took for simple instructions like "OVER" to be coded in Intel x86.
If the biggest complaint is the error messages JVM spits out, then IMO, the port is as incomplete as if the error message was "overflow of the BX register" on an x86. There is really no reason why clojure can't, and isn't, being fully ported to other backends (including generating assembly/machine code for various different processors).
What concerns me more about clojure is changing the syntax which just complicates the reader and might make extending/understanding it more difficult. Coming back to Forth, the reader is literally "search for a space, end of line, or buffer, look the token up in the dictionary. If not found, try and convert it to a number. If not a number, display an error message. Start over." Can't get much simpler than that with the byproduct that the programmer feels totally confident extending or utilizing it as yet another tool in his tool chest to deliver robust software. After considerable study (but admittedly not much actual hands on), there are still some things about the clojure syntax I don't quite understand whereas I had lisp syntax down pat virtually from the git go. Also, and more importantly, I still don't understand the NEED to make these syntactical changes.
I will have to admit though that I throughly intend to make a lot of money in apps targeting the JVM and Javascript enviornments through clojure. It sucks that these algol based langauges dominate the cyberscape. Hopefully, eventually, competiton will force the industry into more efficient, elegant, designs, and when they do, the lisps and forths should still be there waiting, so I'm still hopeful.
Hello,
Funny thread and articles, a lot of passion and emotion for a technical topic!
I share Stanislav's point of view, I think it is sad to present Clojure as the future of Lisp. I am a Schemer and I like power based on simple concepts. Clojure is full of unnecessary syntax patches and "features" hacks.
Clojure may be productive thanks to the library offered by the Java platform, but it doesn't mean it is the way to go from a language perspective.
For example including immutable structures in the language make no sense since they can be built upon functions.
Rather than that, why not implementing some TCO or including continuation capture?
Productive doesn't mean good, it means quick, if our society was not all revolving about money we could think on the long term and make better software.
I think that one of the main reason LISP and LISP systems declined is that they need smart people, and smart people are expensive, at the time company were ready to pay for it, and actually they didn't have the choice, now there are plenty of untalented PHP, Java, .NET programmers & co at a low cost. It is easier to think when the number of allowed keywords in the language is fixed, but if I give you two parenthesis and I tell you are free, it is an other story.
Clojure is a denatured LISP to seduce those programmers.
After discovering lambda expressions in Python or Ruby they think they finally discovered the Grail.
Not forgetting history is then indeed important.
- Dorian
semi-related point: doesn't SBCL remove the interpreter and just compile, even at the REPL? sure it might be fast as fuck, but it's still compiled.
> "Clojure does not even have a condition and restart system. And, the way it is designed, it appears that it is fundamentally incapable of being retrofitted with such systems."
FYI, Clojure has several existing restart systems now. Including both CL based and Clojure-specific ones. (like hara.event)
So it's fundamentally capable of doing so! It's basically a Lips, therefore can do anything Lisp can do!
Where to begin...
"behind Clojure primitive there lurks Black Magic."
What does "Black Magic" even mean? Is that some technical term? What are you even saying?
"The Clojure user who is missing some routine or other will run crying to Java for help, rather than implementing the feature himself correctly"
If the library already exists in Java, is known to be reliable, then a Clojure developer will usually write a functional wrapper over it. It's called "don't reinvent the wheel." Believe it or not, it's a huge idea in this field.
" t promotes – no, mandates - the use of undigestable foreign matter in Lisp code: primitives on which you cannot pop the hood to reveal intelligible innards."
Lisps typically have primitives.
If your issue is that Clojure has primitives, then I believe you are mistaken. Is it alright to have numbers in a Lisp? They can be represented with just function applications and lists, can't they? Wouldn't that be more semantically consistent? I wouldn't trade hardware represented numbers for software based numbers in a heartbeat, in the name of consistency or any other God. Clojure's embedded primitives (Sets, Maps, Vectors, concurrency data types) solve __real__ problems, and gets everyone using the same solution, reducing the inefficiencies of each developer creating his own set library.
On the whole, I found your post a whiny excursion into name-calling, completely devoid of any substance. You post no specific examples, instead lobbing accusations into the air and hoping that one sticks. I'd be interested to see if you have any actual facts which you base your analysis off of. This has to be the least technical bit of technical writing I've ever seen.
Am I supposed to simply assume that it's a "bad thing" in some objective sense?
I wonder what lurks behind cons cells and arrays in a modern CL implementation.
That's merely a criticism of a hypothetical "Clojure user".
Not much of an argument. For all we know, everything you've ever loved about Lisp deserves to be pissed on.
Feel free to back up these assertions.
I could make the same claim about CL. Arrays, system calls... sometimes I'm even forced to use the C FFI.
Making it easy to call "opaque routines" when necessary is not equivalent to encouraging it.
As far as I can tell, the language and community encourage people to embrace an idiomatic, functional programming style.
That's the only legitimate point you've raised so far.
Nobody's hailing it as the "future of Lisp" or claiming it to be superior to Symbolics Genera.
When people refer to Clojure as a "modern Lisp", the implication is that it's better suited to solving the problems
most software developers currently face. The quality of a solution is a measure of its effectiveness in solving the corresponding problem.
It seems like the root of your frustration is that you are fixated on a much broader problem than tools like Clojure intend to solve.
I suspect that the responses you get merely reflect the quality of your criticism.
I guess thats why it's called Clojure and not Lisp.
Clojure is to Lisp in the same way that Java and Visual C++ are to C++. Stallman's butt cheeks would disagree with you, they will GNUify you with their lazorz.
This analogy doesn't really hold. C++ is a programming language, while there is no Lisp language. Lisp is a family of languages, which Clojure is undeniably a member of. It doesn't make sense to say that "Clojure is to Lisp as Java is to C++."
Just stumbled across this so many years later. I thoroughly enjoy Symbolics' Portable Genera as the epitome of a fully integrated program development environment.
I know this is an old post, but you are absolutely 100% correct. The fiasco of false publicity surrounding "artificial intelligence" as in beating a go player or playing atari shows. These deep learning programs are essentially regression (as in linear regression) or basically pre-done Monte Carlo sims. There is nothing intelligent, a true perception of form, there at all. A human child sees the family cat labeled "cat", and the very next day is naming random cats in town. Furthermore, if present with a jpg or video from youtube of a cat, the very next day will name that too. I have two children, now grown.
A lisp program is a syntax. You build your language from the bottom up with macros, and your problem top down to meet your language. It would have animal, leg, not dog, and so on, as actually concepts to apply to many environments at once. Lisp programs have the potential to be truly approaching what we call intellect, the perception of form. Only if they are "all the way", up-to-down, lisp. Clojure is lisp-like bindings to java, really.
I just wanted to tell you, that after all this time, you are still 100% absolutely correct. You inspired me to download sbcl recently after stumbling across this post again. One of the best, historic, truest CS rants on the internet. Kudos. Strong work.
Stanislav,
Agree with you mostly. Just as you say, it doesn't irk me that Clojure exists. The main problem of Clojure is that it is being promoted as "The NEW, reinvented, corrected Lisp for the 21th century", when it isn't; it is at best a lisp-alike programming language that makes programming the JVM far nicer than using Java. But then, there is Armed Bear Common Lisp.
I don't know what to think about Clojure being popular. For one, it reduces the learning curve to proper lisps like Common Lisp; Clojure being able to do a small subset of what one can do with CL. Is it a gateway drug to uncut, real Lisp?
P.S: I feel surprising that you call Common Lisp an "abomination" and then in later comments you cast Common Lisp (SBCL impl) in a positive light. You imply "Symbolics Genera" is a better lisp, yet (as you know) Genera is an OS, and AFAIK the programming languages for Genera were mainly Common Lisp & ZetaLisp, which I'd guess aren't enormously different. What gives?