The Axis Of Eval: Why I ignore Clojure
axisofeval.blogspot.com
axisofeval.blogspot.com
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.
I'm not sure if I should recommend anybody to go the same route (since I'm still very much a FP/Lisp newbie, so my words carry little to no weight at all) but it worked well enough for me that stuff made more sense after doing that.
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.
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.
The JVM does not bring that much new to the Lisp world. What is new in the JVM nowadays is the concurrent GC and the JIT. Lisp runtimes prefer precompiled code. What the JVM lacks for example is easy code loading (think class loading in the JVM), instruction set optimized for Lisp and dumped images.
Clojure combines STM, concurrency etc. in a clever way and with the focus on pure FP. It's not that elements of that did not exist before, but the combination in Clojure seems to be novel.
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.
Lisp has a smaller community than other languages, but it's still a big, diverse community.
(By the way, "Lisp community" is a bit of an oxymoron, IMHO; everyone seems to be stuck on his own island.)
Would you care to argue that the Lisp community is better than any of these?
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?
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).
It's a messy place to be, but there are some ivory treasures to dig up.
And most adult programming communities have something worse than the "Rock Star" stereotype: the "Authority". For Lisp in particular, there are plenty who struggle for that title.
PS. Indeed, "I pushed 20 of my projects to Github"...who cares, is anyone of them any good?
- C has a very strong community, and people who don't like C go out there and create their own dialects or substitutes (like Go) without constantly harassing on each other. I won't go as far as saying nobody would insult me there as you're doing here, but at least there's some mutual respect that is driven by the interest for the language. The same could be said for the Python or Ruby (and no, I haven't decided and I won't, I use the right tool for the job) communities, but I have not had that experience with Lisp/Clojure/Scheme fans.
- The various communities around Linux distributions similarly bash on each other, but thankfully I'm not in as much of a loss there as I were back in high school with no clue about what Lisp even was. I can safely ignore their rants because in that context, I can judge for myself. When it comes to Lisp dialects, I don't know my way around and the community made it hard for me to learn anything concrete.
See, in many a case, it is difficult to get into a discussion without encountering some bizarre religious argument about "which shell do you use" or "why not C++?", similar to several recurring themes here in HN (see the recent "C is a macro assembler" arguments). Not only are such arguments unhelpful, but they're a waste of time for anyone who wants to delve into a subject. While the above may be anecdotal evidence drawn from personal experience, I see others share my view, and I don't believe in coincidence.
I think the difference of perspective comes from the different nature of the work Lisp is being used for.
If your job is to create the next version of Lisp, it makes sense to watch how that new feature of Clojure plays out.
On the other hand, if your job is to deliver a nice application to users who need it, you don't really care about how that feature will look 20 years from now - you use it if it makes your problem simpler to solve.
That said, I wish application developers were less susceptible to language/library/framework fashion. I dread to support (and enhance) Java apps that rely on a stack of frameworks like the developers were playing some buzzword bingo game with the product.
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.
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.
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.
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.
http://www.reddit.com/r/lisp/comments/dfpmq/no_starch_press_...
I'm also looking forward to see the ARM port of Clozure CL mature with the alpha version already running on an iPad.
And that's only in the commercial implementation.
No, concurrency is also supported by free CL implementations - like CCL.
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.
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.
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.
What does it make Newbie friendly? I was just seeing a video of Robert C Martin explaining Clojure - he looks like a Lisp newbie to me. Half of the time he was spending in a primitive REPL in a Terminal. Is that Newbie friendly? Maybe because one does not get distracted with slightly better REPLs, a SLIME REPL or even one of the other advanced REPLs? Then he was using Intellij. Is that more Newbie friendly? Perhaps to developers coming from Java?
I wonder how many of you are using Clojure like a Lisp (with its interactive development tools), and how many are using it like typical scripting language?
Anyway, I expect Clojure to improve on that front over time. But, as time goes by and the compiler is written in Clojure, the REPL gets improved, it has some better error handling, it gets real error messages, etc etc. ... it then will no longer be the sexy small Lisp which you have seen grow up. It will be a Lisp implementation like many others with all its complexity.
This is very fuzzy terminology. What defines newbie-friendly? I can get an "enterprise-quality" Common Lisp environment and language for free. Likewise, the CL standard is also freely available and meticulously cross-indexed. As an added bonus there are countless Common Lisp books available on every imaginable topic. There are also numerous package managers (including the exciting http://quicklisp.org) at my disposal. And for the cherry on top there are luminaries like Ranier Joswig and Xach Beane willing to take their free time to answer my idiotic questions.
This, to me, is the very definition of newbie-friendly.
There are bordeaux-threads and portable-threads, and they mostly work, but I usually just fall-back on limiting my threading calls to a small number of functions and then manually adding #+ stuff to get it to work when I want to port to a new CL.
People really expect some form of threading/concurrency to be standardized across implementations.
The CL community has been occasionally successful in making new de-facto standards (Gray streams, ASDF, and to a lesser extent MOP), so there is hope.
"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.
(By "such a rant", I mean the tradition of rants which purport to turn Common Lisp's negatives into positives, where the smugness is joyously dialled up to 11.)
* It typically subsumes Scheme, Interlisp, etc into "Lisp". (Regardless of whether, in other contexts, the author argues they're not Lisps.)
* Others are dismissed as "unwashed masses", while the "so many smart people" in the Lisp community obviously thought of your new innovation and either dismissed it or had other things to do than implement it.
* It purports to turn a commonly-believed negative into a positive.
* Uses questionable but nuanced logic.
* The author seems to at least partially believe in the rant's gist, as far as anyone can tell.
I'm not necessarily arguing it's a bad thing, just a tradition that people might want to keep in mind with a dose of humor.
EDIT: I guess I have terrible humor ;p Moving it to reddit
"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.
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.
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.
Common Lisp seems to be missing a number of things I like in Scheme for this sort of thing; my impression is that for understandable reasons the introduction of lexical scoping to mainline Lisp in Common Lisp was done with an eye towards minimal breakage of all that great software that had been developed in the previous 25 years.
This is very different to my perspective. I like Clojure for two reasons:
1) It's a Lisp (and I rather like many Lisp features) 2) It's an accessible Lisp. I found it to be easier for me to learn get stated with than Comon Lisp which I had previously tried to learn and had not gotten far with.
One consequence of 2) may be that Clojure will turn out to be rather significant, regardless of whether any of its individual features are all that great. Clojure may succeed because it is an accessible Lisp.
http://axisofeval.blogspot.com/2010/04/dylan-and-lisp-family...
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.
There is Scheme, where there is still some research and evolution going on. See the work on R7RS and implementations like Racket.
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.
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.
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.
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. ;-)
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.
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.
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...
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?
Great stuff can come from that though, for instance, Django.