[dsrguru]

They're both amazing languages that are simultaneously very fun to use and very powerful, not to mention great with concurrency, but here's the grossly oversimplified gist of when you'd want which language:

Clojure has a beautiful dynamic type system. Haskell has a beautiful static type system. If you're working on a project with changing requirements (which for me means most nontrivial applications), Clojure will be much easier to work with and, as with most Lisps, is very well suited to what pg calls exploratory development. If you're working on a project whose requirements are largely static and known in advance (compilers, interpreters, parsers, static analyzers, mathematical tools, etc.), then you won't have to worry about coding yourself into a corner and Haskell's insanely powerful type system becomes a positive.

[chongli]

Wow. I came to the exact opposite conclusion you have. Changing requirements is really where Haskell shines. The ability to make a change in the types and have the compiler tell you everything that needs to be updated is an enormous aid to refactoring. As for exploratory programming? Haskell has powerful tools to do that as well. GHCI, type inference and typed holes[0] work extremely well for exploration of what's possible and can even give you solutions to your problem that you hadn't even thought of.

[0]. http://www.haskell.org/haskellwiki/GHC/TypedHoles

[platz]

I agree, though one has to compare apples and apples. experienced programmer vs inexperienced programmer is not fair. Of course if one is unfamiliar with how to build a flexible type safe systems, (newbies), there could be these sorts of issues. But for experienced programmers, not really.

[chongli]

though one has to compare apples and apples. experienced programmer vs inexperienced programmer is not fair.

Oh, definitely. I just feel that far too many people focus on programming languages that are good for beginners without really thinking about them from an experienced programmer's perspective. What may be good for a beginner can often be terrible for an expert. What may be hard to understand for a beginner can be extremely powerful and simplifying for an expert.

I think the question people should ask themselves is: "Do I want to stay a beginner forever? If not, why am I using tools that are designed for beginners?"

[mattgreenrocks]

Excellent point.

We regularly extol the virtues of expert-friendly text editors, but don't talk much about the appeals of expert-friendly languages and frameworks. Also worth thinking about: a huge amount of hype gets allocated towards beginner-level languages/frameworks that solve beginner-level problems (todo lists) more easily.

[JackMorgan]

I'd guess that is because most developers ARE beginners, right up till they retire/career shift.

If we were even half experts, maybe that would change, but in a field where "anyone can be a developer" you will see a long tail of low skill.

[mattgreenrocks]

Not sure why you were downvoted.

Industry routinely degrades skill and experience in favor of "just ship." New frameworks are continually churned out with the implicit promise that they'll fix everything (except their own lack of composition). Custom development is viewed as expensive when someone else can come along and paste several libs together, then apply duct tape to hold it all together. Domain modeling is viewed as esoteric. Testing is still hotly debated.

...I don't want to go on.

[AnimalMuppet]

I could argue that for most people, it is only when they start bumping into the limits of the beginner's tool that they see the point of the more advanced tool.

[chongli]

I think this is a very limiting approach to life. It leaves one open to the Blub Paradox[0] (or more generally the Dunning-Kruger effect[1]). My personal approach is to keep an open mind and assume that there's always a better way to do something than what I am doing now.

Edit:

[0] http://www.c2.com/cgi/wiki?BlubParadox

[1] http://en.wikipedia.org/wiki/Dunning-kruger_effect

[flopsey]

As a new programmer I'd say there's an aspect that you're ignoring. The need to take reasonable steps, and to know if not your limitations at least where you stand.

You want to take the next step that has enough familiar aspects that you can acclimate reasonably quickly and build non-trivial programs (the fun part) in a reasonable amount of time. But also different enough that you're exposed to new concepts and new ways of thinking about programming, and also to have access to a more powerful language.

Simply diving head first into a powerful but completely foreign language might not be the best way. Coding can be as frustrating as it is rewarding. And there's something to be said for trying to maximize the rewards and minimizing the frustrations.

[platz]

Although 'coding yourself into a corner' is definitely possible, I would rather hope that one makes good decisions, there is plenty of space to type things and allow re-usability and flexability. You could make a similar but different negative statement about clojure, about having to maintain a large project when the requirements change, if you're not careful you may find a change in one part of the code breaks another part of the code.