[Haskell-cafe] Re: Why can't Haskell be faster?

[Tim Newsham]

> Unfortunately, they replaced line counts with bytes of gzip'ed code --
> while the former certainly has its problems, I simply cannot imagine
> what relevance the latter has (beyond hiding extreme amounts of
> repetitive boilerplate in certain languages).

Sounds pretty fair to me.  Programming is a job of compressing a solution 
set.  Excessive boilerplate might mean that you have to type a lot, but 
doesn't necessarily mean that you have to think a lot.  I think the 
previous line count was skewed in favor of very terse languages like 
haskell, especially languages that let you put many ideas onto a single 
line.  At the very least there should be a constant factor applied when 
comparing haskell line counts to python line counts, for example. 
(python has very strict rules about putting multiple things on the same 
line).

Obviously no simple measure is going to satisfy everyone, but I think the 
gzip measure is more even handed across a range of languages.  It probably 
more closely aproximates the amount of mental effort and hence time it 
requires to construct a program (ie. I can whip out a lot of lines of code 
in python very quickly, but it takes a lot more of them to do the same 
work as a single, dense, line of haskell code).

> When we compete against Python and its ilk, we do so for programmer
> productivity first, and performance second.  LOC was a nice measure,
> and encouraged terser and more idiomatic programs than the current
> crop of performance-tweaked low-level stuff.

The haskell entries to the shootout are very obviously written for speed 
and not elegance.  If you want to do better on the LoC measure, you can 
definitely do so (at the expense of speed).

> -k

Tim Newsham
http://www.thenewsh.com/~newsham/