
The empirical evidence that types affect productivity and correctness - luu
http://danluu.com/empirical-pl
======
michaelochurch
First of all, this is one of those where differences within categories are
much greater than those between categories. I'd rather work at a principled
Python shop than a sloppy Scala shop. If you use nulls and go overboard with
inheritance, Scala becomes unmaintainable as well. I've never seen sloppy
Haskell, but quality of people matters more than the language itself and
that's probably largely because the Haskell community is small and elite.

That said, for me, it's about flow. (The IDE flamewar gets into the same
territory. I just don't like the flow-breaker that is having to use the mouse,
when coding.) Writing unit tests can be a flow-breaker. On the other hand,
ripping through source code to chase down a NullPointerException (or similar
error, like a "List.head []") is annoying at best and extremely disruptive
when the error/failure distance is high, as it often can be in dynamic
languages. I find, on average, that development is more flowful in statically-
typed languages, and even if the development top speed is slower, I think
that's made up by the low frequency of flow breakage.

That said, Java's version of "static typing" is abysmal and, in a typical
corporate shop, you're never going to get into flow in the first place so it
doesn't much matter.

~~~
dllthomas
_" I've never seen sloppy Haskell"_

I've written sloppy Haskell...

~~~
codygman
Yeah, I've written my share of sloppy Haskell as well.

------
dang
This review is surprising in two ways: how thorough it is and how even-handed.
It must have been a lot of work to put together and I'm glad you did it so the
rest of us don't have to.

It's refreshing to see posts like this and
[http://blog.metaobject.com/2014/06/the-safyness-of-static-
ty...](http://blog.metaobject.com/2014/06/the-safyness-of-static-typing.html)
pointing out that we don't have strong evidence on this and keeping an open
mind. A trend? One can hope.

------
jerluc
It was hard to really see the author as being objective on the subject after
reading the experiment that pitted Perl/Python programs against Java/C++
programs in an application requiring "string manipulation and searching
against a dictionary". I'm all for trying to prove this point empirically
(though I disagree with the author's stance), but in the least you've got to
eliminate as many of these variables as possible (e.g. choosing typed
languages that have similar string manipulation and sane collection libraries
rather than pretending like working with Java HashMaps is anything near a
Python dict).

Other than that, I'd say skip the over dramatized dogma and just pick the tool
that suits your problem space best.

~~~
scott_s
I'm confused by your comment. The author of this blog post had problems with
the experimental design in the paper you're talking about. Specifically, he
said: "However, since the scripting language group had significantly different
(and easier) environment than the C-like language group, it’s hard to say how
much of the measured difference in implementation time is from flaws in the
experimental design and how much is real."

Said another way, the experimenters picked a task which some of the languages
were designed for. Which sounds rather like the point you're trying to make,
too. Did you confuse the quoted abstract with this author's comment?

------
astrieanna
td;lr there's very weak evidence either way.

If the long list of evidence is too long for you, then it's totally worth
clicking the "click here" link to jump to the author's summary at the end. The
summary is readable and useful by itself -- and it is what you're looking for
if you really just wanted him to summarize the research for you instead of
telling you about all the relevant studies, one by one.

~~~
pervycreeper
For convenience's sake: [http://danluu.com/empirical-
pl/#wat_summary](http://danluu.com/empirical-pl/#wat_summary)

