I use clojure not just because it's a practical lisp (it is), but because Rich Hickey is a genius, and is stirring up programming language design in ways we haven't seen in a long time.
Where everyone else (except for maybe the Haskell people) seems to be doing the same old grab bag design "oh that's a cool feature, oh, and that too", Rich has a clear idea of what programming should be, and he moves closer to that goal daily.
I think people overestimate the significance of choosing e.g. Ruby over Python or vice versa. C vs. Java is a legitimate choice, Java vs. Clojure is legitimate, Ruby vs. Python is not, IMO. I'd like to see an example of where choosing Ruby / Python / Perl is a momentous decision.
I'd like to see an example of where choosing Ruby / Python / Perl is a momentous decision.
The only one I can think of is that a lot of people have an intense hatred for one of the three, so you've got to weigh your team's preferences to make sure you offend the fewest number of people.
Personally, I have a deep seated, all-consuming, perfectly irrational (though I'll happily invent reasons) loathing for Perl, and I just refuse to use it.
But Ruby or Python? Eh, close enough that I'm not going to complain either way...I'm sure you'll find plenty of Ruby zealots that wouldn't touch Python with a ten foot pole, though, and vice versa.
I love Ruby. It's the first language that's made me happy as a programmer. I don't like special characters, and I can tolerate ruby's occasional =>, |e| and {}, and I tend to avoid the other ones. For the same reason, I like Python.
Languages that introduce characters for the sake of making a compiler happy make me, personally, unhappy. I have a really hard time being comfortable with (){}; all over the place. And it's taken me years to realize why - it slows me down. I don't see very well, and those little things cause me sometimes hours of pain.
So I'm a bit of a language snob. The more clean the syntax, the more I'm going to be drawn to it, and the more I'm gonna be productive in it.
In fact, it's why I like SASS more than LESS (for CSS).
So I guess I'm saying Ruby vs Python? Exactly. Meh. Ruby over Perl or C#? Any day of the week.
> I think people overestimate the significance of choosing e.g. Ruby over Python or vice versa. C vs. Java is a legitimate choice, Java vs. Clojure is legitimate, Ruby vs. Python is not, IMO. I'd like to see an example of where choosing Ruby / Python / Perl is a momentous decision.
I agree here as well re: Ruby vs. Python vs. Perl. I've found that since I know Perl (have spent many years working on it, both professionally and on my own), I can fairly easily work on Python projects. Out of those three, my choices are generally going to be based on whether one has a better library than the other two (e.g., Python having a better ncurses library than Perl, Perl having an better XML parser interface). I've no personal preference between the languages themselves, as I feel when I program in them, I am not learning anything that I don't already know well. (Ruby being a slight exception with its Smalltalk-like features, co-routines, etc...).
It's pretty much the same way for me with C# vs. Java and C++: C# has language features which make it a more pleasant than the other two, but ultimately the choices come down to platform choices/library availability/project-specific limitations (e.g., I'll use C++ or C# for desktop applications, C/C++ for non-trivial UNIX command line utilities, Java for server side/distributed applications which make extensive use of threading; C# might be nice for that role as well, but having Windows in a datacenter can easily kill a project or a even company -- and Mono isn't quite "there" yet). Again, compared to each other, neither of these languages teaches me something the others won't, with a few notable exceptions (e.g., Java's interfaces taught me the pattern to use -- most of the time -- with C++'s multiple inheritance: inherit a single non-abstract, constructable class and multiple purely abstract classes).
Doug Hoyte called the concept "blub central": there's game theoretic disadvantages to the mainstream languages introducing new features (e.g., for the long time Java wasn't taken seriously in the mainstream due to being a garbage collected language; I'd imagine there was similar debate around closures being added to C#, but now Java will -- after much botching -- have them).
On the other hand Scala, Clojure, Haskell, OCaml, Scheme and Common Lisp each teach me new concepts that I haven't seen before. Even if I ultimately disagree with the languages' aims, I still find these languages worth learning: e.g., I tend to think that, ultimately, dynamically typed languages with optional type hints (e.g., Common Lisp, Clojure, Strongtalk) are preferable to statically typed languages, statically typed languages with well-designed type systems (Haskell, OCaml, Scala) are still very much worth learning.
This is a particularly valueless comparative assessment of some programming languages, with a focus on Clojure. I'm surprised that it was posted here, and more surprised that it's getting up-voted. But then, people don't really want hard comparisons of the tools they use. Instead, they want warm fuzzy emotional validation that reinforces the time commitments they make to learning those tools.
This comment doesn't cite any firsthand experience, doesn't cite even any secondhand experience, and makes frequent generalizations and assumptions about where, how, and why respective languages are designed and used. It also makes the all-too-frequently-made, blithe, and baseless assumption that languages are necessarily in competition, or that if they are in competition, that competition is zero-sum. This is a bar conversation in comment form. It's hand-waving.
Look: comparing programming languages is hard. You can't do it in a blog comment. You can't really even do it in a blog post. Researchers have a hard time doing it in lengthy academic papers. Hardly anyone has attempted to do it in book form.
Don't think that someone summarizing the bullet points from the feature lists of two languages and then extrapolating them out over their particular view of the industry is anything other than opinion. If that opinion validates your choice of language, great; you'll sleep better tonight. But this is just talk. Experience and metrics are what counts.
I don't think the authors intention is to compare the relative merits of the languages in the context of a particular project. Its more about horserace and market niche. And these are terms in which startup founders are accustomed to thinking in - in the absence of data, you look at related trends and use your reasoned intuition to think about the spread of new ways of doing things.
My guess is that a lot of people read that comment and figured that it made sense and captured conventional wisdom in a succinct way.
As an aside, because language adoption has network effects, the fact that a lot of people can get interested and excited about Clojure is itself meaningful, which is why I upvoted it.
I'd love to see Clojure break into the mainstream. Perhaps it will, but I'm skeptical that any s-expr syntax will ever be palatable to a majority of programmers.
I think programmers tend to overestimate the importance of language choice in the success or failure of a development project. We can passionately debate the merits of static vs dynamic typing and various schools of syntax but I suspect that ultimately the skill and determination of the people involved make the crucial difference.
That said, I do think Clojure's prospects are better than any previous lisp, because even if it can't "win" it can tag along for the ride with the rest of the Java ecosystem and benefit from its much larger momentum.
Clojure has a leg up over most Lisps for another reason: the people that know Clojure well and participate in its community are not complete douchewieners, and they're willing to accept that everyone has different needs and backgrounds. They actually want people to try Clojure out (even if they were - gasp! - Java programmers!), rather than making the assumption that anyone that doesn't already worship their language as The One True Holy Solution-To-Everything Language is a moron.
To hear the more vocal Common Lispers tell it, even people that code Clojure are retarded code apes that need to be lectured on why they're stupid for not using a Real Lisp, more deserving of scorn than encouragement or support. Haskell's community is not nearly as bad (Common Lisp's userbase has become one of the most bitter, self-important cesspools of snobbery the programming world has ever seen, and Haskell is far too active and useful to foster such degeneracy), but there's always that pervasive scent of "If you're not already using Haskell, you're cheating, and it's clearly because you're dumber than I am."
Then again, the Haskell folks piss me off for other reasons - after studying such things in the context of real math, it's infuriating to be talked down to by people that just "got" monads and think that their shallow grasp of the concept entitles them to wield Genius Points over everyone else's heads. I suspect this is just a small but vocal sub-population in Haskell-land, but it's a really annoying one that seriously turns me off from the language...
And was pretty roundly flamed for it. In any case, I totally agree that the community surrounding common lisp is utterly and irreparably toxic and that Rich is right to ignore it and to carefully cultivate a far more civil and friendly community around Clojure.
I don't know exactly what it is about functional programming that attracts people that can't tolerate different philosophies. Maybe the more Aspberger-prone coders naturally gravitate towards tools that promise to impose simple, elegant order on the inherently messy world of real-life programming.
Common Lisp's userbase has become one of the most bitter, self-important cesspools of snobbery the programming world has ever seen
You are absolutely right here. I am not sure what caused this to happen, but I have never seen a programming community that so actively discourages code reuse. Ask why two libraries don't work together, and the answer is usually, "you shouldn't be using libraries!"
Yeah. SBCL is a nice VM, but the community needs to die.
Then again, the Haskell folks piss me off for other reasons - after studying such things in the context of real math, it's infuriating to be talked down to by people that just "got" monads and think that their shallow grasp of the concept entitles them to wield Genius Points over everyone else's heads.
You're sort of doing the same thing, right? And in reality, the people that actually use Haskell are not like this. Don't let someone that read about Haskell on Reddit yesterday, opened ghci, and typed "let fibs = 1 : 1 : (zipWith (+) fibs $ tail fibs)" put you off. People like to be excited about things, and people that read too many programming blogs get themselves unnecessarily excited about simple things. Then when they sort of understand that simple thing, they feel the need to tell everyone.
The clojure community has the "omg monads!" problem too, but that structure isn't particularly useful in Clojure and that is obvious, so people aren't as excited about it. There is plenty of annoying Clojure fanboi-ing, though... but that is true of any language. (OK, there are no Cobol fanbois.)
Totally - my knowledge of Haskell is probably more superficial than most Haskell fans knowledge of category theory, so I'm in no position to fairly poke fun. Consider the jab retracted. :)
I think I'm just seething from a recent argument about Haskell's superiority where I was accused of not understanding the almighty Power Of The Monad...really, I just think that the necessary pervasiveness of the pattern indicates that the language is not as powerful as it could be (I raise an eyebrow when I see any pattern used very often anywhere), whereas fanboys sometimes take it as evidence that the language is beautiful - witness the number of Java programmers that think design patterns are proof of Java's perfection. I personally don't like it so much when languages make too many choices for me, and Haskell seems to have that same "protect us from ourselves" philosophy that makes Java so irritating to work with, just with a different enforced paradigm.
And in reality, the people that actually use Haskell are not like this. Don't let someone that read about Haskell on Reddit yesterday, opened ghci, and typed "let fibs = 1 : 1 : (zipWith (+) fibs $ tail fibs)" put you off. People like to be excited about things, and people that read too many programming blogs get themselves unnecessarily excited about simple things. Then when they sort of understand that simple thing, they feel the need to tell everyone.
Yeah, this is what I pretty much assume, that it's a vocal minority creating most of the noise. I should probably give it a fairer chance, given that a lot of people find it the perfect language for a lot of stuff.
Unfortunately at the moment, the only "stuff" I can afford to work on involves DOM manipulation, so it's Javascript or bust for the foreseeable future...
" I just think that the necessary pervasiveness of the pattern indicates that the language is not as powerful as it could be (I raise an eyebrow when I see any pattern used very often anywhere), whereas fanboys sometimes take it as evidence that the language is beautiful "
Very interesting observation! Generally recurring patterns in one language "disappear" in more advanced languages (as Peter Norvig's slides point out), either by new syntax or changes to the runtime . How could Monads or (by extension type classes) disappear in a new language? Something to think about.
Actually, the problem with Monads in other languages is that they do disappear behind the statement separator (semi-colon in many languages). In Haskell terms, you're stuck in the IO Monad and can never, ever get out of it.
An analogy: C has the array-dereference operator []. But that pattern is locked into the language, you can't do _anything_ but dereference C arrays in exactly the way the operator does. C++, Python, C#, and a wide variety of other languages unlock the array dereferencer by permitting the operator to be overloaded, and thereby permitting things other than a straight-up C array deference, ranging from dereferencing into something that presents the interface an array does (like some sort of ordered tree) but is not literally laid out as a contiguous block of memory, to things that aren't arrays at all, like keying into hash tables.
Accusing Haskell of being "less advanced" because it actually exposes Monads to you and permits you to use them is very much like accusing C++ of lacking power vs. C because it permits you to overload the square brackets. If you put aside the question of whether it's a good thing to have the power (a separate debate in both cases), it's not a very sensible accusation to level against Haskell.
The Monad pattern appears everywhere in every language whether you know it or not, Haskell merely exposes to the user something that is already there. Calling a monad a "programmable semicolon" is not necessarily the best way to understand them, but it has more truth to it than some of the other metaphors tossed about.
Accusing Haskell of being "less advanced" because it actually exposes Monads to you and permits you to use them is very much like accusing C++ of lacking power vs. C because it permits you to overload the square brackets.
I addressed this a bit in a response to jrockway (http://news.ycombinator.com/item?id=1170325), but wanted to make it clear here: my complain is not that monads are exposed, sugared up, and/or "allowed", because I think that's great - to the extent that we are "stuck in the IO Monad" in other languages, I agree, that is not a good thing. My problem is that (to some extent, at least) dealing directly with the pattern is necessary if we want to handle stateful computations, and it's less convenient than simply writing the computation naturally, with state.
My accusation (and I know it's not a new one by any means) is merely that Haskell artificially limits its expressive ability and that state monads are a workaround, not that all monad usages are a problem (or even a symptom).
You may know these things, but to be clear: Nothing in Haskell stops you from using the usual functional mechanisms for passing state as explicit parameters to functions. The State monad is not necessary. In fact you can pretty much ignore the fact it exists if you want from what I can see. It's just useful because it's simpler than passing the state of the computation around.
You say that in Haskell it's harder, so I conclude you must not be talking about "the state of a computation" the way I am, but just talking about state in general, including the stuff you'd have to access through IO. I still fail to see how this is harder than in any other functional langauge, excepting that there's no convenient "final global fallback". Haskell isn't quite unique in that (Erlang arguably falls here too), but it is very unusual. My perspective may be skewed by my fairly extensive work in Erlang, I've learned how to deal with this issue. But other than the lack of a true global state I'm not sure what you could be thinking of that's really any harder.
Incidentally, while I use and enjoy Haskell, I'm not besmitten with it. I'm truly interested in what you see as a problem, but I'm having trouble matching your accusations to my experiences.
"Actually, the problem with Monads in other languages is that they do disappear behind the statement separator (semi-colon in many languages)... The Monad pattern appears everywhere in every language whether you know it or not, Haskell merely exposes to the user something that is already there. "
Yes I agree (haskeller myself). The "disappearance" I meant was addressing the original point of view that the repetition of the pattern was a weakness in the language, something like Visitor pattern disppearing in Common LIsp. (an intriguing idea to play with and a valid point of view). Your interpretation of disappearance goes the other way - something like continuations being hidden in fortran and explcit in Scheme.
"Accusing Haskell of being "less advanced" because it actually exposes Monads to you and permits you to use them is very much like accusing C++ of lacking power vs. C because it permits you to overload the square brackets. If you put aside the question of whether it's a good thing to have the power (a separate debate in both cases), it's not a very sensible accusation to level against Haskell."
A better analogy would be an argument about exposing call/cc in scheme. Is call/cc good language design? There are arguments on both sides. Haskell does continuations differently than Scheme. Which is "better"?
And come on, no one is really "accusing" Haskell of anything. I for one, like the language a lot.
If you will, think of this as a speculation about a successor language. 15 years from now (say) there will be a better language than Haskell in the statically typed lazy functional languages space, which absorbs the key positives of Haskell, has a few new ideas, and possibly treats Monads differently (or does away with them altogether). Clean (the language) deals with IO with uniqueness types with nary a monad in sight. Is that design "better"? Worth thinking about.
> If you will, think of this as a speculation about a successor language. 15 years from now (say) there will be a better language than Haskell in the statically typed lazy functional languages space, which absorbs the key positives of Haskell, has a few new ideas, and possibly treats Monads differently (or does away with them altogether). Clean (the language) deals with IO with uniqueness types with nary a monad in sight. Is that design "better"? Worth thinking about.
Clean's uniqueness types have the distinction that you can e.g. in theory split the state of the world, thread it to two different function and then put it back together, and make the type system ensure safety.
Monads have the distinction that they are not only easy to compose but that composability is baked right into their very definition (and laws).
Functional reactive programming might be a good alternative model for I/O and some other things where monads are used. Also arrows seems to be worth more investigation.
Arrows are in a lot of cases the more apt structure that monads. The reason arrows aren't used more in Haskell already is that the monads have such a nice syntax.
> A better analogy would be an argument about exposing call/cc in scheme. Is call/cc good language design? There are arguments on both sides. Haskell does continuations differently than Scheme. Which is "better"?
To clarify this, here's a couple of questions whose answers might amuse you.
Is it possible to implement explicit continuations in terms of monads?
Is it possible to implement monads in terms of explicit continuations?
If it is possible to implement A in terms of B (and not vice versa), then B is more basic than A.
That's why I prefer Ruby over Python. It unifies loops and iterators using closures. At the same time the syntax "pretends" to be simple so that you can start using Ruby straight away without having to understand continuations and closures. But I think a language which manages to hide the complexity of monads without removing them will blow Clojure out of the water.
> I think a language which manages to hide the complexity of monads without removing them
Hm, I'm not sure this is possible: a great part of the "complexity" of monads is because it's a similar (and fairly simple!) structure that applies to a great many apparently unrelated concepts: function sequencing, backtracking, and what have you.
I don't know if that's fully true. One pattern used nearly ubiquitously and having relatively little fear of vanishing is the function. That example makes me either doubt the power of that quote or curious as to what in the hell could out abstract abstraction.
(More concretely, works like the Typeclassopedia seem to get at the heart as to why I think Monads are a different beast than language patterns like Singleton.)
I agree with you - some patterns, like functions (yes, we're really starting to stretch the word "pattern" here...), appear because they are symptoms of good design. Sometimes, maybe even most of the time, monads appear as symptoms of good design, as well.
But sometimes they appear as workarounds for language limitations, and that's where we run into trouble. I feel like most pure languages in any paradigm run into this problem a lot, and it's why I vastly prefer mixed languages.
I don't know that I fully agree with what plinkplonk says; I don't really think monads or type classes should disappear in "better" languages, because they are very powerful tools to have in the box. I'm just concerned that in Haskell, because those powerful tools are there and relatively painless to use, other tools that have many fine uses have been pulled out, and the language loses expressive ability as a result.
really, I just think that the necessary pervasiveness of the pattern indicates that the language is not as powerful as it could be
I think you're wrong, but I don't know how to explain it. The pattern is "running a procedure, and then running another one". Let me know when you "work around" that.
(I'm not really sure why you were downmodded...I don't think that's an unreasonable response to my objection.)
Sorry if this is a bit long: I've been trying to figure out precisely what it is that bothers me about the monad "pattern" as it shows up in Haskell, and I've mostly put my finger on it. It's mainly the use of the State monad that smells to me, by the way, some of the others are quite powerful and merely indicate flexibility - note that when I said "necessary pervasiveness" is a problem, it's "necessary" that bothers me, not "pervasiveness".
Some patterns, even if they show up all over the place, are not alarming at all, because they are there to facilitate good design no matter what paradigm you work in - I think of these as "style patterns", because they're usually not enforced, and sometimes you're tempted to break from them, but without a real good reason you should usually resist the urge. MVC is a perfect example - it's not there to enable you to do something, it's there to restrict what you do so that you write better, more maintainable code. This, to me, is the signature of a good design pattern: it tells you what not to do, and it lays out a way to avoid doing it.
But others are "power patterns", if we're being charitable, and "power" is not a good word in this context. Things like the adapter, decorator, iterator, and strategy patterns (not an exhaustive list, of course) are mostly around to enable behaviors and flexibilities that the language (Java or C++, usually) makes very inconvenient. Not that the patterns necessarily make them easy, but they do make them possible, usually with the minimum friction that the language will allow - if you have to use Java, you have to know and use these patterns, because otherwise you're going to end up reinventing them anyways to get your work done.
Sometimes I think of these sorts of patterns as "patterns of delusion" rather than "power patterns." By which I mean, they spring from the fact that the systems we're trying to model don't map very well onto the models that the language at hand imposes (the "delusion"), and we end up having to shoehorn concepts into each other to make them fit. This is always uncomfortable, and when we find ourselves doing it, it's a language smell.
In the case of Java, the core delusion is obvious: everything is a noun with properties (which may be other nouns) and abilities (which may not). In order to work with abilities (verbs), we have to "noun" them first, but before they can do anything we need to re-verb them, and God forbid we want to work with verbs that act on verbs...
...thus we end up with several patterns pretty much exclusively devoted to working around the inconveniences of treating verbs as nouns. Some of the other power patterns in Java are caused by other delusions (maybe I should be less critical and say "overly specific model assumptions"? Bah, screw it...), but this is the most consistently painful.
Pure functional programming's core delusion is pretty clear as well: all state is immutable. Trivially, state is not immutable in many problems (at least under the natural description of the problem), and whenever we thread state or use state monads we're employing a power pattern to work around a restriction imposed by our language/paradigm.
Now, context can determine whether a pattern is employed for power or style: I'm fine (thrilled, even) with threading state or using state monads when they are employed as style patterns - if you're working in Scala, Clojure, Lisp, etc., and you have a chunk of code that you've decided really needs to be purely functional for whatever reason, awesome. The pattern is a restriction, not an enabler, and that makes it good. I can't offer any argument against benefits of state-free programming, I fully agree that it is incredibly useful and can make life easier, to the point that it should probably be the default in any language.
But far too often I see Haskell code where state-simulation is done solely because the problem under consideration is naturally expressed with mutable state, and the only benefits that accrue by wedging the mutable state into an immutable framework are that you can write the program at all, usually at a healthy loss to clarity. Every time I see this, it's like seeing bits of Java code written in functional style: it's ugly, it's inconvenient, and you've lost most of the benefits of the paradigm that you're mocking.
I've yet to be convinced that Haskell actually gains very much from its stateless-ness; I understand that in principle there are nice optimizations that it can enable, and parallelization becomes rather simple, but I'm not seeing it beat the pants off of impure functional languages in speed or clarity. More than anything, I think what Haskell has going for it is all the other nice syntax and power that it has (a lot of which has been mimicked in other languages because it's so nice), and I'm not sure I believe that any of that would be degraded one bit if "normal" stateful programming was added in as an option.
Agree or disagree (either way is fine, I realize there are arguments in the other direction), I think that's at least a better explanation of what I was complaining about before. I realize I'm stepping into holy war territory here, maybe I should have just kept my mouth shut. :)
Pure functional programming's core delusion is pretty clear as well: all state is immutable.
There is no "state" in functional programming, there is function application. Your program is a function from some value (inputs) to some value (the result). You write that program by composing various smaller programs with operators like (.) and (>>=) (or if you like being generic, (>>>)). There is no data, there is just function application.
So then, "state" becomes an imaginary concept that sometimes makes things easier to think about; if there is a sequence of computations that logically operate on the same "thing", then you call that "thing" the state. The State monad is nothing but syntax sugar that lets you very explicitly pretend that there is a such thing as state; something you can "get" at and "put" into as needed. This abstraction, BTW, is no different than state in any other language (which is why it comes up so much in hastily-written Haskell programs; you can just cut-n-paste from C and change the spelling of some keywords), except instead of "get" and "put", you just use variable names and "=". Otherwise, exactly the same concept and semantics, and very similar syntax everywhere.
In procedural languages, state is important because the procedures abstract CPU instructions, which operate on little boxes called "registers". But in functional programming, your program is not a list of things to do to a register, it's just functions. So state is not really meaningful anymore. Don't program the machine, program your algorithm!
I've yet to be convinced that Haskell actually gains very much from its stateless-ness; I understand that in principle there are nice optimizations that it can enable, and parallelization becomes rather simple, but I'm not seeing it beat the pants off of impure functional languages in speed or clarity.
But nothing is ever going to "beat the pants off" hand-optimized assembly in a benchmark; there is only so much work a computer can do, after all. In the real world, however, people don't have time to spend hundreds (or thousands!) of hours optimizing four lines of code. In that case, you'll find that these theoretical optimizations are great -- you write code the natural way, and the optimizer turns that into something closer to the optimized-for-hundreds-of-hours assembly. C and Java compilers just can't do that because it can't make any assumptions about what you mean, it can only work with what you say (since those programming languages are basically high-level lists of instructions for the CPU to perform).
Common Lisp's userbase has become one of the most bitter, self-important cesspools of snobbery the programming world has ever seen
There's a lot of truth to this. C.l.l. is horrible and #lisp is often horrible. Sometimes my jaw drops at what assholes they are.
That being said, there are quite a few people using Lisp actively who are nice. The problem is that they (we? I hope) are scattered and relatively isolated. One glimmer of hope to me is that the community around Clozure Common Lisp is sane and functional. If there is to be another renaissance of Common Lisp, I wouldn't be surprised if it grew out of there.
I sincerely don't understand the standard flaming /about/ the CL community. I've read this complaint for years. But my experience is very different. I have been learning CL in the last two years, and I've found that most people (including the usual suspects) are quite helpful. It is true that comp.lang.lisp has a very low tolerance for stupid questions and a bizarre and occasionally harsh sense of humor, but I've never had any problem with it.
What I find alarming in the CL community is something different: I feel that there is practically no innovation. It is magnificient but dying culture. The underlying idea is either that CL is a peak of perfectibility, or that the world has no more the force needed to change anything in CL anyway.
The issue with at least the #lisp community is that they are nice so long as you go along with their ideas. As soon as you suggest anything might be done better some other way, out come the thorns.
Some of the more vocal (and ignorant) members of the clohure community are ex ruby fanbois who jumped off the ruby/RoR bandwagon and moved their babbling proselytizing to Clojure. Yestrday it was all "ooooh mixins, shiny" or " ooooh Open classes shiny" and today it is all " oohh s expressions, shiny!". This is a shame, because Clojure is a nice language that deserves better. But otoh, the quiet and competent Rubyists are breathing easier now.
Of course, Rich Hickey and co don't do any unnecessary trumpeting or deprecation of other languages, but there is a lunatic fringe which combines loudness with ignorance in Clojure just as with Haskell (as you point out, correctly).
But neither the Haskell loudmouths nor the Clojure loudmouths are as toxic as the Common Lisp loudmouths, so things are relatively better in these languages and that is a good thing.
I have noticed one or two Clojure articles that border on "douchewienery", but only on personal blogs. I haven't noticed any bad behavior on the Clojure group.
That said, I haven't noticed that much negativity in the Ruby community either, aside from on Zed Shaw's blog, so perhaps I'm just looking in the wrong places. (Or the right places, depending on one's point of view.)
"I haven't noticed that much negativity in the Ruby community either"
Well I interpreted "douchewienery" to be more (ignorance + snobbishness) than being harshly negative. Both Ruby and Clojure have plenty of practitioners who have no deep understanding of other languages (or knowledge of programming language theory or language design skills) combined with a certainty that their language is "the one". Witness all the "Ruby is better than Python" rants.
Interestingly, the founders of both languages are the opposite - competent and down to earth. One would think they would be emulated more.
As long as the freely available documentation of clojure doesn't improve significantly, I personally don't see clojure participating in any kind of battle/war/...
With documentation I mean a) offline readable documentation and b) non-technical documentation targeted at newcomers. Please take a look at the scala site http://www.scala-lang.org/node/198 and compare that (especially the "Language Specification" and "Scala by Example") with the clojure site.
Alternatively, take a look at the offerings of the haskell community -- including Real World Haskell.
Stuart Halloway's "Programming Clojure" is a very good book but unfortunately there's nothing I've seen online to match it for pacing and quality of examples.
I would hazard to say that while most problems can benefit from a functional style of programming their solutions are not entirely without side effects. Somewhere in there there is a “sweat spot”. A functional side effect free line in the sand, so to speak.
Piling on the contradictory metaphors (is it a line or a spot?) is one thing. I'd really prefer to use a language without a sweat spot though.
If you haven't, go read his slides from the "Are We There Yet?" talk http://wiki.jvmlangsummit.com/images/a/ab/HickeyJVMSummit200... (PDF) . It's worth a read, regardless of what programming language you like best.
Where everyone else (except for maybe the Haskell people) seems to be doing the same old grab bag design "oh that's a cool feature, oh, and that too", Rich has a clear idea of what programming should be, and he moves closer to that goal daily.
I think people overestimate the significance of choosing e.g. Ruby over Python or vice versa. C vs. Java is a legitimate choice, Java vs. Clojure is legitimate, Ruby vs. Python is not, IMO. I'd like to see an example of where choosing Ruby / Python / Perl is a momentous decision.