Study of 49 programmers: static type system had no effect on development time

If anything, I think this study is actually in favor of static typing. Why? Well, most of the proponents of dynamic typing claim it makes development faster. Most proponents of static typing concede this point, but claim that while it may slow down initial development, it makes maintenance much easier.

Of course, this study is fairly limited and drawing conclusions from it is probably premature. I would not base any policy decisions on it alone.

But, if static typing does not slow you down, it seems worth using even if benefits to maintainability are slight. And if they're nonexistent, using a statically typed language over a dynamically typed one still doesn't hurt you.

Besides, I think static typing is awesome. And I'm a college student--you can trust me! That should be all the validation you need :).

I don't know how science can help you here. In the case of the improved fan design, well that's easily testable.

However, I don't want to go down the rabbit hole and argue social vs natural sciences.

I find it dumbfounding that in this day and age, people can still create rather arbitrary social experiments with only 49 people and then think they can draw grandiose conclusions from their "data".

I'm still torn between dynamic and static typing.

The main disadvantage of dynamic typing for me is the lack of verifiable documentation about what data a function needs, and which data comes out of it. This becomes a problem when

a) the data is complex (e.g. dictionary of lists of items with certain properties)

b) I haven't looked at the function for a while.

In those cases, I find statically typed code easier to reason about.

On the other hand, it absolutely maddens me that static type systems force me to spell everything out, even where it's trivial. It slows me down, it bloats the code (especially when you have to create a new class for everything) - which again makes it harder to see the purpose of the code instantly.

That's why I decided to make my own little pragmatic experiment: In cases where complexity is expected (or experienced) - and only there- I use the Clojure pre- and post-conditions to check the shape of selected parameters and/or its return value. It looks like this:

(defn german-holidays

  "Returns map of german holidays, in the year of d."

  [d]

    {:post [(like {(date 1 1 2012) :easter} %)]}

   ...)

(defn calendar

  [c start-date end-date]

  {:pre [(like {:appointments {} :new (list)} c)]

   :post [(like {(today) {:occupations [] :appointments 

#{}}} %)]}

   ...)

You can instantly see how the data is supposed to look like, it will be checked automatically, and it is close to the actual code where you need it (unlike e.g. Unit Tests).

I'm not yet sure how this experiment will fare in the future, so any suggestions or warnings are appreciated.

"I think it's GHC 7.4, which allows something similar for Haskell, to have the typing checked at runtime, to allow this kind of experimentation."

It will be in GHC 7.6.1 and the extension is '-XDelayErrors'.

http://hackage.haskell.org/trac/ghc/ticket/5624 http://hackage.haskell.org/trac/ghc/wiki/DeferErrorsToRuntim...

I use tests for documentation. They seem like more work at the start, but they're more flexible. You can self-document things with tests that you cannot with just types.

For example, here are some tests from the lisp interpreter I've been working on: http://github.com/akkartik/wart/blob/8a8cf96816/030.test

You're right that tests aren't close to code. But that can be good or bad. Since it's not next to the code it can be more verbose and thorough without adding a constant reading burden. And when I wonder, "why is this line here?" I can comment it out and run the tests to find out.

I think of tests as records of the input space of my program. Most of the time we go to great lengths to make explicit what we do but not quite what aspects of its behavior we truly care about. Where are the dont-cares in this program? If I refactor it am I restricted to a bit-for-bit identical behavior? In practice that's impossible, and without tests we fudge random parts of the state space without rigorously knowing what is important and what isn't.