Experienced developers have learned that, typically, newer languages are better than older ones, but they typically do not get better by leaps and bounds across the whole domain. Instead, language evolution typically is a matter of two steps forward, ten sideways, and one step back.

Also, experience tells that new languages often get overhyped as making only forward steps. Given that, it does not make sense to switch horses too often, or one would be forever learning, and never be productive.

Even a small productivity gain (say 5%) over a long period of time can make a very large difference, and is worth spending weeks to learn.

Additionally, Haskell isn't a new little "fad" language. It is a pretty old research effort that accumulated many novel and useful ideas that are worth learning. I understand someone who knows Python and does not think learning Perl/Ruby/Lua will teach him anything substantial/new. But I think even a cursory look at Haskell will remove any doubt about whether it contains novel ideas to learn.

Learning about programming languages enriches you as a programmer, and I can't imagine spending a few weeks learning novel languages and the reward not far-outweighing the costs.

So, yes, I agree that learning about languages is something one should do often, but I do not think one should try to become fluent in a new language (and its libaries) too often.

And yes, IMO that does apply to Haskell, too.

One cannot be expected to learn the thousands of languages out there. But learning a bit about many of them is possible -- and then learning to use the most interesting ones is most probably worthy.

The question then raised is whether any given new programming language or paradigm will bring that 5% productivity gain, and in what circumstances. If it were an obvious and clear path to greater productivity, and superior to other paths to greater productivity (such as spending more time learning your editor and shell and environment, or learning about a new library in the language your work is written in, or learning new tricks in your current language), no one would hesitate to increase their productivity in this way.

You seem to assume that people are choosing not to become more productive by opting not to switch to Haskell or learn Haskell or something about Haskell. There are thousands of programming languages. Shall we learn them all to become five thousand percent more productive?

I'm not opposed to learning new languages. I think folks should tinker. But, I don't think it is provable that learning Haskell will make you more productive than other activities.

Also, STL provides some infrastructure for FP-like programming (defining functors, argument binding, and providing map/fold-like transformations). But given that C++98 didn't provide lambda functions, it was all a bit too painful.

I've done enough to scream in terror and run towards a Lisp should anyone suggest such an awful thing! I think there's a huge, huge gap between your 'pretty much a functional language' and standard 'a functional language' [with proper meta-programming capabilities].

In the obscure years previous to c++11, meta-programming in c++ would have required a language lawyer.

In haskell, the syntax is so nice that is easily readable, and it doesn't get in your way.

Unless you want if-then-else in the do notation (yes, I know that there is a GHC extension for this), disagree with its whitespace rules, or like record syntax (which subsequently pollutes your namespace).

Also, point-free style is nice, but it is easily and often abused, leading to unreadable code.

Yeah, but the syntax and the verbosity hides your aim.

Many people would argue the same of Haskell. So much semantics are encoded in the particular operators, monads, functors, monad transformers, arrows being used, that they are hidden from plain sight.

That's why it's called point-less style. It's too seductive.

> Many people would argue the same of Haskell. So much semantics are encoded in the particular operators, monads, functors, monad transformers, arrows being used, that they are hidden from plain sight.

In a sense. But at least Haskell is parseable. And overloading is only done in a very systematic manner. So if something fishy's going on, you at least see strange symbols you haven't seen before.

In terms of programming-in-the-large, at Google and elsewhere, I think that language choice is not as important as all the other choices: if you have the right overall architecture, the right team of programmers, the right development process that allows for rapid development with continuous improvement, then many languages will work for you;

Also, I think that comma before "the right" in Norvig statements means logical AND. If we rewrite that statement it will look like that: if you have the right overall architecture AND the right team of programmers AND the right development process that allows for rapid development with continuous improvement, then many languages will work for you.

I think it is too many AND's here. In most realistic situations you cannot have such luxury.

Also, choice of Haskell (or similar language) allows you to address at least two points from Norvig statement: the right team and right development process.

Those who learned and applied Haskell almost cannot form the wrong team. Almost - as we cannot rule out failure completely.

The right development process is almost ensured by strong type system. Type systems like Haskell's can be viewed as a tool to spread requirement changes through complete program.

(that's why it is seemed hard to introduce or change a constructor in a data type)

So all in all I think that languages make a difference here. For many languages you should fulfill those three points, for some languages those points fulfill themselves.

I.e. in Haskell you make a change to a type and propagate it, until the compiler stops complaining. In Java you click some `refactor' button in your IDE, and your changes will propagate through the code base automatically.

That's less of a comment on the languages, since Haskell will probably grow better tools some day, but more a comment on the relative stages of maturity.

You can certainly develop rapidly in C++ if you have the right process and people. In fact that is where that quote came from, Norvig noting that devs at google where not hampered by their choice of Java and C++.