
Learning Curves for Different Programming Languages - linhmtran168
https://github.com/Dobiasd/articles/blob/master/programming_language_learning_curves.md
======
phamilton
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.

~~~
rebootthesystem
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.

~~~
phamilton
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).

~~~
t4ngent
Libraries can only take you so far.

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.

~~~
phamilton
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.

------
balloot
I am increasingly convinced that Haskell only exists so that people who know
it can pat themselves on the back for being wonderful.

~~~
coldtea
With the exception of pandoc, I don't recall seeing anything particularly
impressive from the Haskell camp.

(Btw, this, actual stuff people use, is how I measure programming languages --
this metric takes into account communities, libraries, practical issues, etc
all together, and ties them with practical results. It's my version of "let
the market decide").

~~~
cageface
Darcs used to be the poster child for Haskell but then somebody came along and
wrote a much better DVCS in C, of all languages. Draw your own conclusions...

~~~
mempko
Still use darcs to this day. Darcs is magical AND productive. I use a script
to play back my darcs commits into a git repo so i can put my projects on
github. I love you darcs, I love you.

------
iSloth
Really don't understand the pure hatred that people have for PHP, I'm at
network engineer and I don't have any desire to become a programmer because I
love my job, however I've wrote some very useful applications that myself and
my team use on a daily basis to make networking easier for us.

For me it was simple to learn PHP and create something 'useful', basically
every web server is capable of running it which makes my life a lot easier as
well.

Surely the fact that someone can hack together code within a few minuets that
doesn't profess to be a coder is a good thing, regardless of the language that
there using?

There is no better programming language than the one you know.

~~~
SixSigma
I'm no mechanic and I have no desire to be one but I've changed my own brake
pads, surely anyone can adjust their car's brakes and many other tasks with a
few simple tools and a book.

I don't understand why mechanics say some cars are better than others.

~~~
iSloth
Playing around with motorbikes is actually one of my hobbies, and I have some
very nice and quite expensive Snapon tools which work wonders in the garage.

However I'm certainly not going to suggest that changing your breakpads was
done incorrectly because my tools cost more than what I'm assuming yours did,
or that I could complete the same job a bit quicker and therefore better.

Sure, if you're going to change break pads all day long for the next year I
can suggest some very nice tools which might help you.

But instead I'd like to say well done on changing the break pads, I'd wish
more people would use the tools that they have at there disposal, show some
initiative, and do the same.

------
brucehauman
For goodness sake people. You can take a comic as an attack on a particular
programming language, but how is this useful? Maybe there is wisdom in this
comic or not, but there is value in people reflecting and presenting a
humorous point of view.

I have used all of the languages above and found the comic humorous and
greatly exaggerated. But I think that there is something here. If you haven't
really used the exalted languages in this comic please try them. You can only
learn from the experience.

Also, if users of a particular language appear to be elitist, this does not
say anything about the value of the language itself.

An open mind is going to be both happier and more capable.

------
coldtea
He wanted to make a cheap joke, but PHP should be the opposite: productivity
is rather high, while self-assesment is low.

~~~
aaronem
I think by "self-assessment" is meant something more like "self-regard", the
whole being taken to mean that PHP programmers have a relatively high opinion
of themselves, which is not justified by the code they generate.

I gather the author is perhaps not a native speaker of English, so perhaps
this is a subtlety which has simply passed him by. As such, I've opened an
issue on Github to suggest the replacement of the term. (Also another, to
suggest the Javascript chart be updated to account for promises; I've somewhat
less high hopes of that one, given that the author appears to be a disciple of
the Haskell language family and to entertain the prejudices so commonly
associated therewith, but who knows? It's worth a shot, in any case.)

~~~
coldtea
> _I think by "self-assessment" is meant something more like "self-regard",
> the whole being taken to mean that PHP programmers have a relatively high
> opinion of themselves, which is not justified by the code they generate._

I read it this way too, and this is what I'm disagreing with. I've seen far
more programmers for other languages having a high opinion of themselves than
PHP guys, which are more workman-like.

The worst offender in this regard would be some Javascript guys (and their
n-th rediscovery of the computer programming wheel).

------
aikah
This isnt even funny.Unless you want to take a cheap shot at PHP and glorify
Haskell,the language everybody brags about but almost nobody uses
professionally.

------
rubiquity
I'm not a PHP user, nor do I like PHP, but I do know plenty of PHP users that
are quite productive with the language.

~~~
seppo0010
There's no scale on the vertical axis to compare different curves. You can
only compare the productivity and the self-assessment within a language.

~~~
brandonhsiao
But you can compare derivatives. Which is the stab at PHP.

------
xrstf
Oh wow lel so funny, 10/10, pease make more PHP jokes, they are so super
funny. And you are right, too! Not a single PHP developer was ever productive
and shipped a product. None. Never. And especially PHP devs walk around and
proclaim "We are the elite! Our language makes coding fun and hip!!!!" all the
time.

</rant>

~~~
vdaniuk
Actually, right in these comments PHP programmers proclaim how productive they
are, how PHP powers half the web and how Haskellers haven't done anything
practical.

So it seems your sarcastic rant completely misses the mark.

Disclaimer: not a haskell, nor a php programmer.

~~~
jbeja
Which language do you use this days?

~~~
vdaniuk
I've discovered elixir several weeks ago and fell in love. Dynamic functional
language with great concurrency support and ruby syntax. Wow. Lots of other
goodies, too.

Started a complete rewrite of my data analysis project in elixir and it is
going great. I am nearly sure that my chemistry with elixir will stick for a
long time.

Due to practical reasons javascript is my primary choice for small, short-term
projects. As an example, meteor is really interesting. I consider JS to be a
safe-ish investment of my time due to its momentum and huge ecosystem. It
doesn't make me happy, though.

So, to answer your question my languages of choice are JS + Elixir.

Before elixir I've tried python, ruby, go, r, javascript, haskell and c. Btw,
I consider programming in haskell to be a good learning exercise for
understanding advanced CS concepts.

------
iamcreasy
I wish the article didn't include the php learning curve. Then this thread
could have been an interesting read.

------
stared
It seems that it interchanges "productive" with "writing clean code".

PHP is ugly but can be productive. Haskell is beautiful, but well, I know a
lot of people encharmed by it, but no-one productive (i.e. delivering products
quickly; it's not the same as solving pure, mathematical problems).

~~~
MaxGabriel
Do you know alot of Haskell programmers? Because I'm enjoying my typesafe SQL
queries, typesafe intra-application linking, typesafe templating, etc. Haskell
is capable of far more than "pure, mathematical problems"—indeed, typed IO is
a premier feature of the language.

edit: sorry, this was pretty defensive; I shouldn't have written this comment
so hastily.

~~~
virtualwhys
You know, C#/F# programmers are enjoying most of the above in spades, and the
libraries are fully vetted and mature to boot; could say the same for Scala to
some degree.

Can we say the same for Haskell? Let's take a sample: you say, "I'm enjoying
my typesafe SQL queries"

There are 2 Haskell query DSLs worth talking about (read: that support joins):
Esqueleto and OpalEye. The latter is fresh off the presses and not yet ready
for prime time (see the "ideal sql" samples interspersed with the performance
killing actual sql); the former at first blush looks decent, but then you
realize, whoops, no string based SQL interface (for those ultra complex db-
specific queries business requirements demand, but cannot be expressed in the
dsl), and no Oracle or SQL Server support -- yikes, bye bye enterprise; in
fact both libraries officially support _one single_ database, Postgres.

Also, given Haskell's lack of a module system (hello global namespace
conflicts), the choice of operators is somewhat, well, hideous (Haskell itself
remains beautiful though, at least in terms of concision).

Not sure how things are on the web framework front, but given the claims of
achieving C-like performance, that Yesod and Snap basically face plant in a
popular benchmark[1], one wonders where reality and the ideal world Haskellers
seem to live in, meet.

[1]
[http://www.techempower.com/benchmarks/#section=data-r9&hw=pe...](http://www.techempower.com/benchmarks/#section=data-r9&hw=peak&test=db)

~~~
MaxGabriel
Hi virtualwhys, won't have time to respond to everything but wanted to mention
Esqueleto supports MySQL/Postgres/SQLite, they're mentioned in the testing
section of their Hackage page
[https://hackage.haskell.org/package/esqueleto](https://hackage.haskell.org/package/esqueleto).

Re: the techempower benchmarks, my understanding is that they used an old
version of GHC which didn't include the MulticoreIO manager or something like
that. It's since been fixed [1] but it's been awhile since a TechEmpower
benchmark (iirc round 10 was pushed back but they're now working on it again
[2]).

[1]
[https://github.com/TechEmpower/FrameworkBenchmarks/commit/9e...](https://github.com/TechEmpower/FrameworkBenchmarks/commit/9e8701c4311e04c92b8379819c65457697f07b7d)

[2]
[https://github.com/TechEmpower/FrameworkBenchmarks/issues/12...](https://github.com/TechEmpower/FrameworkBenchmarks/issues/1273)

------
trcollinson
It seems like a lot of people love to hate PHP, and I am not the biggest fan
of PHP myself but some of the arguments are a bit off. My current consultancy
focuses on coming into companies in a last ditch effort to fix problems with
startups, generally after they have failed some sort of technical due
diligence when being sold. I get a fairly even mix of most languages (Ruby,
PHP, Python, .Net, Java) and they all have problems in the wrong hands.

In 2014 (so very recently, this year), I was brought into a company that was
just about to be sold and failed a technical due diligence. One of the red
flags was that most of the engineers were in the process of leaving having
"accomplished a dream and sold their amazing system to a large organization".
They left for really big, well known companies rather than finish the
technical due diligence and take an aqui-hire position.

A look at the code showed why. While these were all honestly rather Senior
level engineers, they had written some of the most horrible Ruby, JRuby, and
Clojure code I have seen in my career. Often it seems they decided well known
and good frameworks were just "not good enough" so they decided to write and
not maintain their own. Their list of technical sins was quite long but the
last I will mention is that they never could decide, from day to day, what the
right architecture was, so they just changed it, over and over, on a whim.

The point of this story is, languages don't write poor code, engineers do. I
know that people will say, "But PHP has an ecosystem of Junior developers just
picking it up and pushing out bad code and never really learning." This may be
true, but it's actually just as true with Ruby, Python, .Net, and Java. Those
languages, Ruby and Python in particular, are just much better at the PR game
of making themselves look "more mature" than PHP is.

------
virtualwhys
tl;dr humerous Haskeller takes steaming dump, rejoices; one may think that one
is not being productive, and yet one's actual productivity sky rockets,
whereas in other languages (exception, LISP) one's actual productivity is less
than one feels, especially in the case of PHP where delusion apparently
reigns.

Seems to be a riff on the text editor comic graph where emacs morphs into
dragon-eating-its-tail recursion as one approaches unreachable mastery [1]

[1]
[http://ergoemacs.org/emacs/emacs_fun.html](http://ergoemacs.org/emacs/emacs_fun.html)

------
sergiotapia
Say what you want but PHP is one of the most Rambo-bad-ass languages I've ever
used. You toss everything to the wind if you want and you will still get a
working product.

Few languages have that sheer "Survive" feel to it. For that alone I think PHP
should be celebrated. Note: I'm not a PHP developer.

~~~
krapp
I think that most of the things people hate about PHP are the things that make
it work. It doesn't force you into a particular paradigm, and it all but
encourages mixing PHP and HTML together into one horrifying but incredibly
convenient stew. It doesn't force you to write clean, elegant or secure code
(you can, but it doesn't hold your hand in that regard.) A lot of it is still
just wrappers around c. You're not chained to a package manager (although you
can use one if you want) or a framework (although you can pick one of many.)

And yet, for almost everything people want to do when they want to put
something on the web, it's not only perfectly adequate, but in some ways more
efficient than other languages. Most of the web is still CRUD anyway. Take
stuff from a database, iterate it, insert it into html, serve html. Or maybe
do all that, and serve json instead. This is still far, far easier to do in
PHP than it is other languages.

That said, as a professional PHP developer, there is still plenty about the
language that drives me up the wall. I think anyone who works with it and is
serious will admit there are issues with the language. But no one can say it
isn't battle-tested, or that it doesn't make it easy to get something up and
out onto the web.

------
raverbashing
Decorators are more than simple syntactic sugar in Python ;)

It seems overly critical, but still funny (the Haskell one is probably the
most spot on)

And after all, Facebook uses PHP and MySql

~~~
frostmatthew
> Facebook uses PHP

This is the common rebuttal of PHP jokes - but pointing to a sole outlier is
rarely a solid defense. Especially when they have created Hack[1] and HHVM[2].
So it's not entirely accurate to say they "use PHP."

[1]
[https://en.wikipedia.org/wiki/Hack_(programming_language)](https://en.wikipedia.org/wiki/Hack_\(programming_language\))

[2]
[https://en.wikipedia.org/wiki/HipHop_Virtual_Machine](https://en.wikipedia.org/wiki/HipHop_Virtual_Machine)

~~~
coldtea
> _This is the common rebuttal of PHP jokes - but pointing to a sole outlier
> is rarely a solid defense._

Sole outlier? Hardly. Half of the web is powered by PHP, including tons of
websites with huge traffic and usage.

> _Especially when they have created Hack[1] and HHVM[2]. So it 's not
> entirely accurate to say they "use PHP."_

Hack and HHVM do not show some inherent PHP issue that something like Ruby or
Python would not have.

Hack is mostly an attempt to add type checking/hinting to PHP. The lack of
type checking would be the same if they used Python or Ruby or Node+JS or
whatever.

And HHVM is an attempt at a speedup, to work at Facebook like economies of
scale. Considering that plain PHP is on par speedwise with Ruby and Python,
that's again not something that would be saved using those other languages.
Which is why Google tried to do Unladded Swallow (for Python), Dropbox does
their own thing, RoR companies invest hard on speeding up Ruby/Rails, etc.

TL;DR: Hack and HHVM may be proofs of some lack in PHP for Facebook uses, but
are not proofs of PHP lacking things compared to other similar languages like
Python and Ruby.

~~~
yawboakye
_> Half of the web is powered by PHP, including tons of websites with huge
traffic and usage._

What powers the web: web servers or web sites/applications? If it's web
servers then your claim that half of the web is powered by PHP is false
because I'm—and I'm going to be honest here—yet to see/use a web server
written in PHP.

~~~
coldtea
Obviously web sites/applications.

Web servers would just server static sets of pages without some means to run
dynamic code.

~~~
yawboakye
_> Web servers would just server static sets of pages without some means to
run dynamic code._

Web applications respond to requests. That's all they do. Web servers parse
those requests and deliver responses appropriately. You're reducing the role
of all intermediaries (DNS servers, caches, etc) and unfairly praising the web
application. The web server serves both non-changing static files and the
generated documents.

------
creyes123
I am working on a commercial SAAS application written in Haskell. I have been
programming computers since 1980, with solid experience in at least a couple
dozen programming languages. I chose Haskell for this project because of its
programmer productivity and runtime performance. I have not been disappointed.
I am always amazed at how little code it takes to get things done. The
Achilles Heel of too many languages and their implementations is concurrency
support. Haskell had that problem licked ten years ago. Once my code compiles,
I know it has few remaining bugs. It runs fast and there are enough good third
party libraries to meet my needs.

So what's not to like about Haskell? It has a brutal learning curve. Not so
much because it is hard, but because it is different.

------
DavidSJ
Presumably inspired by [http://www.terminally-
incoherent.com/blog/2006/08/01/text-ed...](http://www.terminally-
incoherent.com/blog/2006/08/01/text-editor-learning-curves/)

------
horrido
Re: Haskell monads

If something hurts my brain, I don't want to do it; I don't care about the
long-term benefits. Most humans feel the same way and that's why Haskell will
never become mainstream.

~~~
JoeAltmaier
...and that's the difference between an amateur and a professional.

~~~
horrido
No, it's not. Software developers are human. Being a professional does not
always override human nature. Statistically, most "professional" software
developers will not want to adopt a language with a high cognitive load.

~~~
JoeAltmaier
Doing what you need to do, and not what you want to do, is the heart of
professionalism.

------
gexla
Poor PHP. It just keeps getting dumped on.

~~~
zxcdw
And rightly so. Frankly, I think the only reason PHP keeps floating on is the
inertia it has. All the investment in tools, existing codebase and developer
experience are what keep it going, not language merits.

And yes, this means, that whatever you invest in, be ready to abandon it and
move forward, preferrably sooner rather than later. After all, langauges are
_nothing_ but tools. Don't take them personally.

~~~
coldtea
> _And rightly so. Frankly, I think the only reason PHP keeps floating on is
> the inertia it has. All the investment in tools, existing codebase and
> developer experience are what keep it going, not language merits._

Considering the alternatives PHP is not bad at all. It's not like Python or
Ruby are some pinnacle of language design.

It's main BS is a polluted default namespace, incosistent function naming, and
a few semantic inconsistencies. It's not like any other language doesn't have
its share of BS.

Plus what it lacks (a proper AST etc) it's getting. It has been improving ever
since 5.0, and fast. Including getting a vast speed increase with 7 that will
leave Python and co in the dust.

------
cstrahan
The stigma around Haskell is quite unfortunate. Most complaints that I've
heard leveled at Haskell are variations of "it's too academic". Given that
those complaints usually come up when one is tackling abstractions like
Functors, Applicatives and Monads, it would seem that the true sentiment is
that "Haskell is too abstract".

Interestingly, I have yet to hear someone complain about abstractions like
Collection, Stack, Dictionary, or looking at the ever popular OOP abstractions
Class and Method.

Why is it that OOP is widely accepted[1], and yet Haskell-like FP has yet to
take off? Well, I think I have an explanation for why this is.

The abstractions commonly used in Haskell are perhaps a bit "more abstract"
than those seen in most OOP programming. Most people can intuit the value of
collections/classes/etc., and those that can't are pushed in the right
direction by the majority of the industry.

Compare the situation of popular imperative languages to that of Haskell: the
utility of the former is easily acknowledged and has the support of the
industry, whereas the latter is harder to fully appreciate without investing
some time and has the industry actively suggesting that the abstractions are
useless.

Haskell-like FP is, unfortunately, where OOP probably was when it was still
"the new thing". "Why would anyone use this? Classes, interfaces, methods,
messages... Too academic!"

And then OOP picked up momentum as people discovered the utility of
encapsulated state, programming to an interface (instead of an
implementation), the ability to isolate the System Under Test via mock
objects... And then those that tasted the benefits worked really, really hard
to shift the mindshare of the industry to accept these abstractions as "good
things".

I hope Haskell et al will get there some day. The thing is, ideas like Monads
are incredibly useful - just as useful as any of the more popular
abstractions. They're just one more tool in the toolbox - if you don't know
them, you might be missing out.

In an attempt to dispel the myth that abstractions common in Haskell are
academic and useless for professional programming, I would ask one thing of
you: please, please, please watch Tom Stuart's talk "Refactoring Ruby with
Monads" (given at Barcelona Ruby Conference 2014):
[https://www.youtube.com/watch?v=J1jYlPtkrqQ](https://www.youtube.com/watch?v=J1jYlPtkrqQ)

The abstractions are useful. Yes, just like any of the abstractions that you
may have already mastered, they do take time to learn. It's an investment. I
know the payoff might not be immediately obvious, but I promise that it's
right around the corner. There's a practical, pragmatic reason Haskell is
being used to great effect at places like ThoughtBot, Facebook, Skedge.me, and
more.

[1] This is almost a given now: recruiters have often quizzed along the lines
of "why is OOP a superior paradigm?"

------
esaym
Ugh, they left off Perl.

------
salafy
What about ruby ?

~~~
notacoward
I think the fact that Ruby didn't even make the list tells a lot about how far
it has fallen in terms of mindshare. I have nothing against Ruby, its people
or its ecosystem, but it's beginning to seem like a bit of a flash in the pan.

~~~
sergiotapia
10 years+ totally a flash right?

~~~
notacoward
When you have more than a few years' experience yes, something like this seems
like a flash in the pan.

[http://www.tiobe.com/index.php/content/paperinfo/tpci/Ruby.h...](http://www.tiobe.com/index.php/content/paperinfo/tpci/Ruby.html)

Peaked in 2009, now down to a third of that popularity. Other measurements
might give you different numbers, but the same trend. As I said, I have
nothing against Ruby, but it just doesn't seem to be holding its position.

------
smt88
This is a lot of debate for something that's intended to be funny.

If all the lines were accurate, would it have been funny at all?

------
hexaust
Add ruby and c#

~~~
melling
How about C# vs F#? Both have great support. You'd think if people were 2x-3x
more productive in a functional language, you'd get a lot of developers moving
from C# to F# because both have excellent support from Microsoft.

~~~
phamilton
"support from Microsoft"

I know a few Microsoft employees who got in trouble for using F# internally.

~~~
jbeja
Those don't represent the rest.

------
bluecalm
Can you share what did you use to make those beautiful graphs ? I really like
the fuzzy axis lines.

~~~
douglasfshearer
The author is using the Matplotlib Python library. [1]

Similar style charts to that used by Randall Munroe in XKCD.

See also this D3 style for producing similar charts by Dan Foreman-Mackey. [2]

[1]
[http://matplotlib.org/xkcd/examples/showcase/xkcd.html](http://matplotlib.org/xkcd/examples/showcase/xkcd.html)

[2] [http://dan.iel.fm/xkcd/](http://dan.iel.fm/xkcd/)

------
rubiquity
Would learning Monads really come before learning Category Theory in Haskell?

~~~
dragonwriter
Monads are a construct from category theory, and one with a particularly
significant use in idiomatic Haskell, so I'd expect learning Monads as used in
Haskell to generally precede a broad understanding of category theory for most
Haskell programmers.

~~~
rubiquity
Thanks, good to know. I should clarify that I was genuinely asking a question
and not making a statement.

------
finid
For elmers out there, what will a graph of Elm look like?

~~~
rubiquity
Probably similar to Haskell, but with less productivity :p

~~~
jbeja
Because?

~~~
rubiquity
Because it's a fun language to play around with. I guess it depends on your
definition of productivity.

~~~
jbeja
Don't follow you and your logic at all nor understand how you came with it.

------
Tehnix
Does anyone know how the graphs were drawn?

~~~
aftabh
The graphs have been generated using Python's matplotlib[1] 2D plotting
library[2].

[1]
[https://github.com/Dobiasd/articles/blob/master/programming_...](https://github.com/Dobiasd/articles/blob/master/programming_language_learning_curves/generate.py)

[2] [http://matplotlib.org/index.html](http://matplotlib.org/index.html)

~~~
kwikiel
I love to see PHP vs Haskell debate about productivity while actual work is
done in Python.

------
misingnoglic
Someone needs to label their axis better

------
tdsamardzhiev
Pretty accurate, I'd say.

------
imartinez
Bad programmers are bad no matter the language... Why you don't waste your
time writing an interesting post of your preferred language instead of make
jokes about another ones? Maybe the answer is that you can't even write a line
of quality code... you people the Nelson Muntz of code..

