Everyone seems to be focusing on the PHP vs Haskell thing and seem to be missing the other points. Here's a summary:
Callbacks in Javascript make you feel more productive, but in fact you become less productive.
Design patterns in Java don't actually make much of a difference in productivity, but you think they do.
Templates in C++ seem hard but with a big payoff, but they don't accelerate productivity.
Unit tests in python do make you more productive, though it doesn't feel like it. Decorators on the other hand do not make you more productive, but they make you feel more productive.
In Lisp, macros accelerate both the feeling of productivity and actual productivity.
In Haskell, once your brain stops hurting you become productive. When you learn monads, your brain will hurt for a bit. While your brain hurts, your productivity declines. Once you get past understanding monads, your productivity grows at roughly the same rate as it did before you knew monads (in other words, monads do not accelerate productivity). Then you learn category theory, which has no bearing on your productivity but makes you feel less productive.
PHP is a bit of a cheap shot, stating that you won't become more productive over time but you will always feel super productive.
I'll take another tack and suggest that productivity today is more a function of what libraries might be available rather than language choice.
A language like Python has a massive number of really good libraries spanning a range of disciplines. Is it the "best" language (whatever that means)? Don't know. Don't care. You can get the job done and the ecosystem is huge.
I am not comparing Python to Haskell or anything else, just using it as an example. I don't use Haskell and wouldn't know how the libraries compare.
My only point is that when all the smoke and bullshit clears out the only thing that matters is if you can get the job done as required. If this includes a performance metric than language performance is important. If it does not, then library availability or other criteria might quickly become more significant.
From my own perspective, it would take a lot for me to choose anything other than Python for my work. When a platform mandates it --iOS native apps-- you have no choice. On embedded systems it's mostly C. When Python fits I can get shit done with it. Nothing else matters.
The graphs are not productivity vs language choice. They are productivity vs experience in a given language.
In languages with strong libraries, I'd expect a diminished benefit from experience. 10 years python experience doesn't make you much more productive in standing up a django application vs someone with 1 year of experience. Thus, the curve for python might very well be quite flat (since you start fairly high to begin with).
Lisp, on the other hand, may not start as high on the productivity scale. Because of its powerful macro system, the language can be tailored to suit your problem better than anything else.
That's what the graphs are talking about. How valuable experience is (and comparing it to how valuable we think our experience is).
A python developer with limited experience is likely to use too many 3rd party libraries in simple cases where they are really not needed. As the application grows this turns into a maintenance and/or performance nightmare.
Not to mention the fact that it takes experience to understand/troubleshoot/fix third party code. When things go wrong the dev with 10 years experience is going to be vastly more productive than one with less experience.
I am a python dev with >10 years experience and I manage numerous junior devs with limited experience, so I see this kind of thing all the time.
But are you actually gaining productivity when fixing third party code? Or are you losing productivity? I would say you are paying back the gains you got from using the library in the first place and therefore losing productivity. Granted, you generally come out ahead.
I think that's the plateau in most languages. You get to a point where you are fighting the language/ecosystem as much as it's helping you and so productivity plateaus.
I wasn't referring the the graphs anyway in regards to absolute productivity. Rather, I was referring to the parents claim that the library in python makes you more productive, which may be the case.
Also, "why wouldn't they be"? Whitespace is boring. Maximizing useful space on each graph would require a different scale for each language. Also, productivity in each space is varies widely limiting apples-to-apples comparisons across languages (even within languages this is tricky). There's no question that for some workloads Python is more productive than C++ or Haskell. The discussion is really about what the learning curve for the language is (hence the title).
It's funny that we feel PHP doesn't make you more productive, yet most of the web was running PHP apps until a few years ago when better languages gained momentum and we saw new web sites not built in PHP.
The decision to use PHP is not represented in the graphs. What the graphs say is that as you gain more experience with PHP you don't necessarily become more productive. 1 yr PHP experience == 10 year PHP experience.
I think your parent is referring to the fact that the Productivity graphed for PHP is the worst of all the languages, even at t=0 (except Haskell, which is shown as starting out with 0 productivity for a while.)
I also strongly disagreed with that for the same reason your parent comment did. The self-assessment bar is funny, but hte blue (productivity) graph needs to be way higher.
There's no absolute scale, so you can't make comparisons between the graphs. The only conclusions you can make from the PHP scale is 1) that (according to the author) PHP developers think they are a lot more productive than they actually are and 2) experience doesn't increase productivity substantially in PHP.
what makes you think the graphs aren't meant to be read on the same scale? By that reading the PHP productivity line could be 100x higher than the next-best language listed, but with self-assessment being 1000x higher than the next-best language listed. That is not a very sensible reading.
Callbacks in Javascript make you feel more productive, but in fact you become less productive.
Design patterns in Java don't actually make much of a difference in productivity, but you think they do.
Templates in C++ seem hard but with a big payoff, but they don't accelerate productivity.
Unit tests in python do make you more productive, though it doesn't feel like it. Decorators on the other hand do not make you more productive, but they make you feel more productive.
In Lisp, macros accelerate both the feeling of productivity and actual productivity.
In Haskell, once your brain stops hurting you become productive. When you learn monads, your brain will hurt for a bit. While your brain hurts, your productivity declines. Once you get past understanding monads, your productivity grows at roughly the same rate as it did before you knew monads (in other words, monads do not accelerate productivity). Then you learn category theory, which has no bearing on your productivity but makes you feel less productive.
PHP is a bit of a cheap shot, stating that you won't become more productive over time but you will always feel super productive.