Hacker News Reader

Comment by jfoutz | Hacker News Reader

so, by swiching from python to haskell, you can get code that's 20x faster for no extra development time? sounds like a win to me. (cherry picked shootout data - http://shootout.alioth.debian.org/u32q/which-programming-lan...)

View on HN

Not to mention being able to rule out large classes of errors at compile time, and ease of refactoring large code bases. You mean I get all that for free? Where do I sign up?

Yes, but funnily enough it won't improve your development time. Go figure.

Obligatory language argument: If by ease of refactoring you mean having to change everything whenever anything changes just to avoid a little messiness. :)

only 20x? What happens when you reevaluate it with the python code not having any pieces that are C under the covers? (my understanding that a lot of python idioms for fast code basically turn into ah "use the approach that pushes as much work into C as possible")

That's a common idiom in Haskell, too :)

Not in the same way at all. Bytestring or hmatrix may have their primops in C, but the control flow stuff code for libs like Repa or Vector are pure Haskell (and in fact current state of the art work on Repa has it matching if not beating C code).

The crucial difference is that in python, these faster python idioms are for using C as the control code

Comparing favorably against a subset of a language that noone uses as such sounds pretty pointless. More interesting would be a comparison with pypy.

which, FWIW, usually makes my typical code run 2x to 10x times faster than CPy

Please read the paper and not the HN title.

The paper's title is casting doubts on the positive impact of statically typed languages as they had a negative impact on development time. (though not quality)

From the very first paragraph:

In the experiments the existence of the static type system has neither a positive nor a negative impact on an application's development time (under the conditions of the experiment).

What's the point of dynamic languages if they don't even make the initial implementation faster? They're certainly harder to maintain afterwards.

From the conclusion:

We measured two different points in the development: first, the development time until a minimal scanner has been implemented, and second the quality of the resulting software measured by the number of successful test cases fulfilled by the parser. In none of these measured points the use of a static type system turned out to have a successful impact. In the first case, the use of a statically typed programming language had a significant negative impact, in the latter one, no significant difference could be measured.

Here's my pet unprovable theory. Development time is dominated by a programmer's understanding of a problem. Static languages force programmers to say a lot about their understanding of a problem.

Dynamic code can be very fast, but in lisp, after algorithms, that means actually going and finding all of the calls to elt and replacing them by calls to nth. With a static language the compiler has a much better chance of specializing the code for you.

Reply on news.ycombinator.com