
Clojure won't win the battle but may win the war - twism
http://enfranchisedmind.com/blog/posts/what-killed-lisp-could-kill-haskell-as-well/#comment-37144
======
arohner
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.

If you haven't, go read his slides from the "Are We There Yet?" talk
[http://wiki.jvmlangsummit.com/images/a/ab/HickeyJVMSummit200...](http://wiki.jvmlangsummit.com/images/a/ab/HickeyJVMSummit2009.pdf)
(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.

~~~
ewjordan
_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.

~~~
bphogan
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.

~~~
eru
You should have a look at colorForth. The author replaced punctuation with
colors exactly because he has poor vision. (So I have heard.)

------
al3x
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.

~~~
programnature
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.

------
cageface
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.

~~~
ewjordan
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...

~~~
jrockway
_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.)

~~~
ewjordan
_You're sort of doing the same thing, right?_

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...

~~~
plinkplonk
" 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.

~~~
jerf
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.

~~~
plinkplonk
"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.

~~~
copper
Your point is spot-on.

> 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.

~~~
wedesoft
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.

~~~
copper
> 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.

------
xtho
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/...

~~~
papaf
The documentation on clojure.org is usable and once you're in clojure you can
type (doc whatever) to get the documentation for a function.

However, its a known problem (discussed on the clojure group this week) that
there are many ways to set up the environment and build tools.

~~~
xtho
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.

~~~
dpritchett
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.

------
pvg
_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.

------
morphir
Are there anyone else who are concerned with the lack of tail call
optimization in Clojure?

------
olliesaunders
Watch the video, it's awesome, the blog post—meh—not so much.

