Clojure hate and Language Wars

[findinglisp]

Found this today when jumping through a path of links that was rooted at Reddit:
http://www.loper-os.org/?p=42

Anybody else have any thoughts? Personally, I'm slightly negative on Clojure, though I think it has a lot of neat ideas and I think Rich has done a really good job with it. My main beef is that it caters to the limitations of the JVM in too many ways, but if I had to run a Lisp on the JVM, I would seriously look at Clojure to fill that role.

The blog post above was interesting, though. It seems the poster was objecting to the contamination of Lisp with the Java base (that you had to call from Clojure to Java code too often to get anything done, instead of the world being implemented in pure Clojure). IMO, that's rubbish. Languages are languages. Purity is a phantom, IMO. Even Common Lisps have an FFI to connect them to the rest of the world. Short of the return of Genera, I don't see a "Lisp all the way down" system happening again in any significant way, ever. (Yea, I know about Movitz and things, but note that I said "significant way").

A personal pet peeve is people who take their favorite language (whether Lisp or Perl or Python or Ruby or C++) and create lots of duplicate work, and angst, reinventing the wheel in said language for no good reason. Note that sometimes there are good reasons to reinvent the wheel, but many times there aren't. For instance, it's hard to want to program web apps in Lisp and use Ruby on Rails as your web framework. You really need to rewrite a Rails-like system in Lisp. But to give you an example of where I think it's stupid, when I started LispForum, I had a few people gripe that it wasn't implemented in Lisp. Sheesh! Get over it already. It's a forum. It's already written. It works. There is no shame in running a forum about Lisp in forum software written in PHP. There is no shame in hosting a wiki about Ruby in wiki software written in Python or Perl. All these essentially the inverse of Paul Graham's story of Yahoo rewriting Viaweb in Java because Yahoo didn't like Lisp.

Thoughts?

[Unne]

I'm actually happy with the level of acceptance Clojure has received from the Common Lisp community overall. From reading c.l.l archives it seems that most new attempts at Lisp dialects are usually dismissed or flamed out of existence without missing a beat, but Clojure is getting at least some level of respect if not acceptance.

I think it's the same in the other direction; Common Lisp has a ton of good in it and Clojure guys seem happy acknowledging the good ideas and stealing them when necessary. They've got a port of Common Lisp's FORMAT and a CL-like condition system in Clojure now. I think there's room in the world for both communities and it's good that ideas cross-pollinate.

I do think there is a core of people who will never accept Clojure or any other new Lisp. You've got Common Lisp, a language that's decades old, and people have poured years of their life into learning and mastering and sometimes evangelizing it. I wouldn't expect everyone to easily give that up for something new even if the something new really is a technical improvement. The amount of knowledge and experience you have in an old tool can outweigh the small intrinsic benefits of a new tool. For a master of some tool, it may even be unreasonable to expect them to give it up.

But then there's another tiny group of people who think everyone who uses Perl or Ruby is mentally retarded, and even being in the same room as a JVM leaves them feeling dirty. Those people are so far off the deep end that I can't even pay attention to them. There's no reasonable justification for that kind of opinion; it's bigotry. Complaining that a Lisp message board is written in PHP may be a mild form of the same thing, in some cases. But I think some of those complaints were also probably people just wanting to prove that it could be done. I can understand that sentiment too. It's part of hacker mentality sometimes to try to do something because it's hard; the challenge is part of the fun.

Objections like those on the website you listed are more emotional than logical. I can understand having an aesthetic or emotional attachment to a skill (or art). I can see the appeal of a "pure" Lisp. I also see the benefits of practicality. There's a time for making something that looks nice and there's a time for getting work done, and there's a lot of room in between for a tool that's "pure" enough to be pleasant to work with, and still practical enough to help you be efficient. "The perfect is the enemy of the good", said Voltaire.

But yeah, I don't think there's a war. I hope not anyways.

[findinglisp]

...and even being in the same room as a JVM leaves them feeling dirty.

I don't think you were suggesting that I think this, but just to be clear, my objection to Clojure and the JVM isn't knee-jerk anti-Java bias. I actually think that as far a C-like languages go, Java is just fine. I also think the JVM is a fine piece of engineering... for running Java. My only real beef with the JVM is simply that it's not great for running anything else other than Java. Its operation and behavior make lots of assumptions that the code is Java, not anything else. For example, take a look at how class loading works, and even the notion that everything is a class at all. Rich started with the assumption that his new language needed a well-deployed "platform" like Java and then proceeded to do what he could to deliver the language based on that choice. Unfortunately, you see places where Clojure can't "do the right thing" because of a limitation in the JVM. The most glaring example is the lack of tail recursion in the JVM which forces the need for the "recur" construct. It's not fatal, but it definitely comes off as a hack to fit the limitations of the platform.

[Unne]

Sorry, no I didn't mean to imply that you were one of the JVM-bigots. There's a difference between a rational objection and a baseless emotional objection. On my blog (forgive the self-promotion) I wrote my own list of annoyances in Clojure, most of which are nasty artifacts of being implemented on the JVM. There are many worse ones than `recur`. Some people listed additional points in the comments, and someone else had a nice followup on his own blog with even more Clojure annoyances (not so much JVM stuff this time though). I also agree with you about the class loader, it's painful. I think there are valid reasons to dislike the JVM.

`recur` doesn't make my list because I just don't think it's a big deal at all, but it's not a completely baseless objection; it is an admited. I still think the good outweighs the bad overall in Clojure. I don't agree with people who think the bad outweighs the good but it's a valid argument to be made. It depends what you value the most in a language.

The article you linked to is an example of an irrational objection, by comparison. "Java stack traces look like barf!" People who reject all of Clojure solely on the basis of the presence of `recur` without knowing anything more about the language are also irrational in my opinion, because they're forming an opinion without enough information. It's the same with people who reject all Lisps because of the parens. A person can find a minor flaw in any language, and use that to reject the whole language as trash, but he'll be missing out.

[duncan]

Well, that blog seems to be down at the moment. And, while I've done a bit of playing around with Clojure I haven't done enough to have a strong opinion on it one way or another. I liked some of what I saw, but I was also a bit down on it mainly because of a factor Unne mentions: I'm just much more familiar with CL. If I did enough Clojure I might feel quite differently about that. I do agree with you about the limitations of the JVM, but of course there are also some big advantages to being on the JVM. But I also think there's an analogue to that in how I think about "Lisp all the way down." I'd also say in response to Unne that part of the reason Clojure hasn't come in for as much stick as a lot of other Lisp variants is that it gives the impression of not being completely half-baked. It also gives the impression of differing from CL in ways that might be pretty useful. The problem with a lot of the little Lisps people write is that they're taking something that would be a worthwhile learning project, but that probably doesn't need to be released into the wild, and offering it as if it were some sort of reasonable alternative to CL. That doesn't bother me much actually, but it gets under some people's skin pretty badly.

Anyway, since I haven't read the blog post, and I haven't done enough Clojure to have a strong opinion about it (yet- I keep meaning to try to write something non-trivial in Clojure but I've got too much on my plate at the moment) I mainly wanted to comment on the "Lisp all the way down"/"language bigotry" thing. First, you offer an "on the one hand... but on the other hand" position that's pretty hard to disagree with. I mean- certainly any practical CL implementation and the libraries one uses with it are going to use FFI to some extent. At the same time there are certainly going to be cases where you would prefer that a library be in CL, even considering the practicalities. So where most people are going to differ is where those lines are best drawn.

I do think that you're ignoring an important difference between using a piece of software and using a library though. If you want a piece of bulletin board software, and if one exists that does everything you want, and if you aren't going to want to customize it by a whole lot, beyond the customizations it is meant to support easily, then I can't see much reason to care what it's written in. Imean- you just install it and use it. End of story.

The situation is a bit different when you're using a library, and I'd say that if I'm programming in CL I'd pretty much always prefer a library written in CL, all other things being equal. There are some distinct disadvantages to using FFI. Debugging is trickier, for one thing, but there's also often an impedance mismatch between CL and the foreign language that takes some pretty clever programming to completely hide. And even after you've managed to hide those differences pretty well- well, you might want to alter the library you're using, but not want to have to write a lot of C or (shudder C++) to do it. Or you might want to reach down into the imlementation level from CL for some rreason, in ways that using an FFI makes difficult.

Of course for some types of thing this isn't much of an issue. If you only need a narrow interface to the functionality the library provides, and if that functionality is pretty much "settled"- I mean if it is functionality where there's a pretty clear right way to do things- and if your app is mostly about something else and isn't going to be very intertwingled with what the library is doing for it, and if the library itself is really solid... well, even in that case it would probably be better to have a library in CL, but it might not be enough better that it makes sense for anyone to actually write such a library.

My first programming jobs were in real-time graphics. Actually, the first sizable piece of code I ever wrote was a software renderer for Windows- this was just around the time that hardware acceleration was becoming available in the consumer market, but it wasn't widespread. Anyway, I managed to get a job doing graphics based on that sample code, but I pretty much immediately had to learn to program to some high level APIS, as we needed hardware acceleration (and some frighteningly expensive dedicated hardware) and had to be more productive than doing straight opengl would have let us be. I haven't done any professional graphics programming since 2002 (and even that was just a short term contract), but I've followed a lot of the developments, and I've been interested to see some pretty sophisticated open source libraries appear. I've also done a bit of idle thinking about how one would go about using CL to do graphics programming.

I think that using FFI to call opengl is not a hard decision at all. It might be nice to have an opengl analogue written entirely in Lisp, but it's hard to imagine that the advantages of something like that would make it worthwhile to write one. Gl is pretty close to a graphics assembler, and using an FFI to call it seems pretty obviously the right thing to do. But if you wanted to write a game, for instance, you probably wouldn't want to write straight gl. You'd want to use a higher level library. And in that case it would be a lot better to have an engine written in CL (assuming you could get performance where you wanted it.) On the other hand, if you were working as a single programmer, even if you were working full-time, you probably wouldn't have the time to write both the engine and the game. So as a matter of practicality you probably would wind up using some existing graphics library or game engine. But it would be noticeably less good than having something written in CL on top of an FFI to gl or some other low-level graphics API.

I guess this is sort of an extreme example. There aren't a lot of places where people use libraries as extensively, and want to change them as much as they do when using libraries meant to structure things like games and other graphics applications. But I think it's instructive to think about, both because it is an extreme example, and also because of the difference between the low-level APIs, like gl, and the higher level APIs, like those found in 3D and game engines. There aren't a lot of drawbacks to using FFI with the former, but I think there would be significant drawbacks to using FFI for the latter.

[phil]

I should state clearly that I haven't followed Clojure as much as I should so am probably fretting over nothing here. My question is how many people know about Clojure's implementation (sometimes referred to as a projects Bus Factor)? I only ever hear mention of Rich Hickey and I'm always nervous about a technology with only one person driving it in case they decide to walk away from it (much as seemed to happen with Arc). That said, I don't think any CL compiler has a huge number of implementers either (although there is more than one implementation) and of course, I may be pleasantly surprised to find out that there's a whole team of people working on the core of Clojure.

[Unne]

My question is how many people know about Clojure's implementation (sometimes referred to as a projects Bus Factor)? I only ever hear mention of Rich Hickey and I'm always nervous about a technology with only one person driving it in case they decide to walk away from it (much as seemed to happen with Arc).

Clojure recently moved to github so you can see for yourself. There are a bunch of people contributing to the core, but Rich has pretty tight control over everything that makes it into the core, as I understand it. There are a lot more people with commit rights to the official contrib libraries and (trusted) contributors have more free reign to mess with code there as they see fit. You can also check out the mailing list. There's a list of contributors if you want some real numbers. So I imagine the bus factor is pretty high, though if Rich disappeared in a jungle one day the project would suffer greatly. The whole process is a lot more open (and active) than Arc, to be sure. There's also a completely independent port of Clojure to .NET underway.

[findinglisp]

Sorry, no I didn't mean to imply that you were one of the JVM-bigots.

No need to apologize. I didn't think you implied that at all. I just wanted to go on record lest anybody read the thread and think I was on that side.

For what it's worth, I haven't found a language yet that hasn't had annoyances, so that can't be a showstopper.

[findinglisp]

I mainly wanted to comment on the "Lisp all the way down"/"language bigotry" thing. First, you offer an "on the one hand... but on the other hand" position that's pretty hard to disagree with. I mean- certainly any practical CL implementation and the libraries one uses with it are going to use FFI to some extent. At the same time there are certainly going to be cases where you would prefer that a library be in CL, even considering the practicalities. So where most people are going to differ is where those lines are best drawn.

Yes, agreed.

I do think that you're ignoring an important difference between using a piece of software and using a library though. If you want a piece of bulletin board software, and if one exists that does everything you want, and if you aren't going to want to customize it by a whole lot, beyond the customizations it is meant to support easily, then I can't see much reason to care what it's written in. Imean- you just install it and use it. End of story.

Fair enough. It is different if you're intending to customize something. One of the reasons this forum still doesn't have RSS capabilities is that I'd have to fiddle with PHP in order to make it happen and I'm not looking forward to that.

The situation is a bit different when you're using a library, and I'd say that if I'm programming in CL I'd pretty much always prefer a library written in CL, all other things being equal. There are some distinct disadvantages to using FFI. Debugging is trickier, for one thing, but there's also often an impedance mismatch between CL and the foreign language that takes some pretty clever programming to completely hide. And even after you've managed to hide those differences pretty well- well, you might want to alter the library you're using, but not want to have to write a lot of C or (shudder C++) to do it. Or you might want to reach down into the imlementation level from CL for some rreason, in ways that using an FFI makes difficult.

Of course for some types of thing this isn't much of an issue. If you only need a narrow interface to the functionality the library provides, and if that functionality is pretty much "settled"- I mean if it is functionality where there's a pretty clear right way to do things- and if your app is mostly about something else and isn't going to be very intertwingled with what the library is doing for it, and if the library itself is really solid... well, even in that case it would probably be better to have a library in CL, but it might not be enough better that it makes sense for anyone to actually write such a library.

Yes, I basically agree that it's always preferable to have a library in the native language that you enjoy programming in. That's sort of a given and hard to argue with. My objection to the original blog post was that the author was sort of saying (paraphrased), "Gak! If you use Clojure then you'd have to use Java and we all know that sucks!" My reaction to that is mostly, "Well, using Java libraries is really one of the core advantages of Clojure in the first place." Frankly, I think that tapping into the wealth of Java libraries is probably the most interesting feature of Clojure and one of the things that will help propel it forward. It means that Clojure starts life with a whole set of robust, debugged libraries for doing almost everything right from the get-go.

[tayssir]

I find it hard to argue with this blog post, because it's a passionate statement of personal religion. (Maybe if I'd ever used Symbolics Genera, I could argue that it's not as good as its mythology.) But since rejects arguments based on productivity.. there's not much for me to say. Maybe I can agree that it's closed-minded... but sometimes there's a use in preserving your own ignorance, especially in situations where many people repeatedly failed.

Though there's one point... The world isn't written in Lisp. (So says the xkcd cartoon.) Even with a Lisp machine, you'll probably be wanting to interact with that non-lisp world. Clojure is in the spirit of growing a Lisp interface into non-Lisp things. With time, the lisp interface can come to affect the non-lisp things and infuse it with lispishness.

There's long-term plans (which you hear occasionally) to rewrite Clojure in Clojure (aside from a a platform-dependent residue), so it can be conveniently ported to Actionscript, .net, etc. That sounds great, using Clojure in Flash.

You know, it's the whole Go vs. chess thing Rich Hickey mentioned once, where it's about market share rather than "beating the other guy."

(On a technical note, I like Clojure. Not just because of the libraries, but that really helps. I like using the language, though we could talk about where things could be better. For instance, there's plusses and minuses to Clojure's multimethods. Though, the nice thing is that Clojure evolves to reduce its minuses. For instance, there's a port of CL's FORMAT, and apparently someone developed something that resembles the Condition System.)