Haskell

Haskell is many things:

A buzz-word magnet; functional, lazy, pure, non-strict …
You can collect more of these from HaskellWiki.
An emphasis on solving the problem, rather than manipulating the computer-hardware to achieve a result.
A painful learning-experience.

Whilst the semantics of, & justification for these buzz-words are better explained elsewhere, the second point above is an opinion which warrants some explanation here. It seems to me that programming-languages have had a haphazard evolution; originally just a means to control complex hardware; allocate memory, goto an address, store a result. The 3GLs of choice today may be admirable examples of the breed, providing enhancements (abstraction, encapsulation, inheritance, & polymorphism) which may distance one from the stark reality of the hardware which ultimately must be controlled, but which still require one to face the same direction. This relationship with the underlying hardware, may utilise it effectively & facilitate translation into fast machine-code, but it would seem to be an extraordinary coincidence, if it also represents the ideal way in which to express the solution to a given problem. Prior to the creation of programming-languages, the solutions to problems were expressed mathematically, & there was no irrelevant requirement to encapsulate data, or remember where it was stored.

Having programmed in C++ & Perl for more years than I probably should have, I noticed style-trends emerging as I strove to produce code which was more obviously correct:

The use of constipated code, i.e. making things "const" just because they can be.
Exporting types from classes, to permit them to flow through the code like the data whose shape they define; as with the STL.
The reduction of a significant number of Perl-programs to unbroken sequences of list-operations, each either transforming or selecting from the data-stream (similar to SQL-queries, or to the pipe-lines of command-line utilities so common in shell-scripts), having neither explicit loops nor mutable variables.

print map { … } grep { … } map { … } grep { … } <FILE-HANDLE>;

Whilst I believed programs written in this fashion were more readable, (despite Perl's write-only design), & contained fewer errors, it can't be said that either language promotes this style.

C++'s "const"-keyword doesn't prevent the subsequent mutation of the value of an identifier so qualified, rather it degenerates to mere advice to the programmer, & is of little use to the optimiser.
Mismatching types can be automatically bludgeoned into shape by the compiler.
Perl-5's simple garbage-collector results in hideous memory-usage for programs written as above, rather than the equivalent program written with explicit loops.

Learning Haskell is a long road … including a mine-field.

The multi-paradigm capabilities of Perl & C++ are useful (they allow one to start programming in a familiar procedural or OO style, without inhibiting progression to functional programming) but that doesn't necessarily make them good languages in which to express functional programming, or to reap the dividends. To program in this style and reap the dividends, one needs a single-paradigm language; less is more (unless taken to extremes).

Without knowing it, I'd started on a road to Functional programming & which ultimately led me to Haskell
… though when I say "road", I mean "mine-field", & when I say "led", the sign-posts were sufficiently confusing that for many, it will be a road to nowhere.

A further observation was that the pursuit of clarity in one's source-code, often results in less efficient code; Perl written in the above style, typically runs more slowly than when written using explicit iteration. With Haskell, & its distance from the hardware, one would expect to pay a punishing performance-price, as many high-level programming-languages do; but far from it. Partly because of the default purity of functions, & the resulting lack of side-effects, the optimiser doesn't yield the meagre dividend that one might expect with C++, but an enormous improvement. It isn't currently (2010), quite as fast as C++, but it's tolerably close, & the lack of shared data, facilitates parallelization. For the majority of tasks, I have significant doubts that the average programmer can effectively utilise a large number of CPU-cores via multi-threading in traditional languages; it's hard to write, test, debug & maintain. Since advances in the CPU-performance have shifted from the counter-productive pursuit of GHz to more scalable multi-core designs (to address escalating power-consumption & heat-generation), the relative ease with which one can parallelize Haskell, is of increasing significance.

One's brain is best before end 30. Those blessed with the mind of a child, may find it easy to learn Haskell, but anyone who's strayed just a little further down the road towards fossilisation, including those who've regained the mind of a child, will probably find it hard. Regardless, you will give up; I gave up three times, but that annoyed me just a little bit more than trying to learn the language, so I gave up giving up, & got back on the saddle.

The painful of learning Haskell. Remember your most painful experience, perhaps standing on the dangerous end of a discarded rake, then learn Haskell & you'll feel that most painful memory just melt away. Learning Haskell gives you the power, to get lesser degrees of pain in perspective; then, slamming your finger in the car-door (the hinge-side), will only seem significant, if it's the one with which you used to type. Contrary to the conventional wisdom regarding self-inflicted pain (stop doing it), I urge you to stick with the program, though you're unlikely to see the light until your eyes have stopped watering.

This page isn't really about learning Haskell; if you want to, I recommend Learn You a Haskell for Great Good (though I had many resources simultaneously open, to get different perspectives on the many esoteric concepts; some of them may even have been upside down). The software on this site is written in Haskell, mostly because that's the way I wanted to evolve as a programmer; it feels more like wielding a scalpel than a club, & without inciting you to wield either, I hope it inspires you to learn it too, since even without wielding it, one can see problem-solving from a different point of view.