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

[chongli]

What better way to know your limitations than to seriously challenge yourself? I taught my friend to program in Haskell and while he struggled early on he found it incredibly rewarding. Since then he's found it extremely easy to learn other programming languages, despite their extensive differences from Haskell.

There's also a lot to be said for habit-forming. Imperative languages teach you a lot of habits and cause you to develop assumptions that might actually make it harder to learn a language as different as Haskell. This makes the concept of "taking steps" in your growth as a programmer a nonlinear one. Some languages might even hurt your ability in the long run.