[pron]

Regardless of the merits of Haskell, I think that learning any new language -- while sometimes necessary -- is among the least valuable uses of your "learning resources". That is to say, it may be valuable, but there are probably much more valuable things you can learn (from new algorithms and data structures through OS design and all the way to hardware design). Programming languages are a small -- and not the most central -- part of computer science.

Even from a pragmatic point of view, adopting a new programming language is one of the least effective ways to increase software quality. It is certainly the most expensive and wasteful way to increase productivity/quality and its returns are modest (certainly compared to the cost). I think that widely applicable -- and not at all "mathematical" -- techniques such as automated unit-testing have done so much more to increase software productivity and quality over the past twenty years than any language.

[dreamcompiler]

I completely disagree. If all the languages I'd used had been in the Algol family (as most "mainstream" languages are) I might agree with you, since there's not much qualitative difference between them. But some languages are so different that they change the way you think about programming, and those new ways of thinking improve your skill in every language. For example, Forth taught me about threaded, stack-based code. It's a very different metaphor than assembler or C and it runs just as fast. Icon (the language) showed me what you can do when failure is a first class notion and everything is a generator. (Icon is monad-based programming, although that word wasn't used when Icon was invented.) Prolog taught me what you can do with declarative programming, pattern-matching, and unification. Prolog is not really a general-purpose language, but it's a mind-blowingly elegant way to solve some classes of problems. (Prolog is the world's best database query language, for example. SQL feels like primitive torture by comparison.) Lisp taught me the virtues of lambda calculus, functional programming, programs as data, macros, and ubiquitous composition. After I learned Lisp I thought I understood functional programming.

And then I learned Haskell, which cranks FP all the way to 11. You can curry in Lisp, but Haskell does it automatically. And then there are monads, which (spoiler alert) really are not about I/O. They're much more general than that. Knowing all this stuff has made me a better, more productive programmer in every language I use.

[pron]

> But some languages are so different that they change the way you think about programming, and those new ways of thinking improve your skill in every language.

I absolutely agree -- I never said that learning new languages is useless -- it's just that there are other things you can learn that are much (much) more useful.

For example, decent familiarity with various algorithms and data structures (the more the better), OS architecture and hardware architecture will also improve your skill in every language, and will do so to a much greater extent than knowing Lisp, Haskell, Prolog and Python. The reason is that different programming languages differ in the abstractions they provide and the way they're used to express algorithms. But abstractions -- while very important -- are secondary to the algorithms themselves.

I'm saying this from the vantage point of roughly 20 years of experience, after having learned (to varying degrees) Lisp, Haskell and Prolog. Yes, they help. But knowing that other stuff helps so much more.

I find that it is younger programmers who tend to equate a program with its code, while more experienced programmers learn to separate the two: the code (which is very important), and the program itself -- the stream of machine instructions that get executed on the CPU and its interaction with other hardware subsystems and the OS. Today I can get a very good feel for what a program does -- and how elegantly it does it -- without even looking at the code or knowing what language it's written in, but simply by running it in a profiler (or several), although the profiler should be appropriate for the language. I find that "profile elegance" is even more important than "code elegance".

Code elegance is sometimes subjective and is almost always language dependent. Often, migrating abstraction concepts from one language to another really hurts code elegance; chief among those offending imported concepts is the monad, which has much better alternatives in imperative languages -- in fact, I'm giving a talk precisely about that in the upcoming Curry On/ECOOP conference in a couple of weeks.

[dreamcompiler]

I guess I hadn't thought about the relative value of multi-language knowledge vs algorithm fundamentals; I sort of assume that any competent programmer has already mastered data structures, algorithms, complexity analysis, etc. and given that background, knowledge of multiple languages can improve your skills.

But I take your point; for a programmer who has not mastered the fundamentals, their time is best spent doing just that before embarking on language exploration.

As to your other point about elegance being language dependent, I mostly agree. Pushing a language to do something it was manifestly not designed to do (e.g. monads in C) is often ugly -- Greenspun's 10th rule kicks in. But sometimes such a push is unavoidable. For example, I've had to write bignum code in C (fortunately there's a library for that) and adjustable arrays and manual recursion in old versions of Fortran that supported neither natively. It's not pretty, but it's sometimes necessary because language choice is outside your control.

I'd be very interested in reading your talk if you're able to post it.