[Haskell-cafe] A very edgy language (was: A very nontrivial parser)

[Dave Bayer]

On Jul 7, 2007, at 4:23 AM, Thomas Conway wrote:

> the performance model for haskell programs is at best inscrutable

I punched my first Basic program by hand with a paper clip, in my  
high school library. Even after experiencing an APL interpreter at  
19, it has taken half my life to fully internalize that how long a  
language takes with a machine isn't the issue, what matters is how  
long a language takes with ME. I was beginning to accept that I might  
die before clearing my pipeline of research projects I want to code  
up. Haskell has given me new hope.

Haskell is like ice sailing, where one can reach 100 mph on a 15 mph  
breeze. A few months ago, I watched a colleague write a significant  
code experiment in Haskell in an hour, and I was stunned. Now, I  
routinely write reasonable code experiments in an hour to help learn  
the language, and I'm still a beginner. It pays to "time" all  
executions, one can sometimes knock a factor of ten out of a given  
algorithm with a modest amount of tweaking. One learns in the process  
how to write faster code next time on the first try. GHC is very  
impressive if one pays a little attention to one's code.

This of course sets up the best answer to this debate: For a hard  
problem, one can express better algorithms in Haskell that would  
simply be too painful to code in other languages, swamping any  
considerations about the speed of Haskell versus C for a given  
algorithm.

This is not where I'm personally at. I want Haskell to work math  
examples for me that would take months to work by hand. With current  
processor speeds, the bottleneck is how quickly I can specify to the  
computer what I want. Haskell is the perfect language for this. For  
this purpose, concise readable code I can understand later beats hell  
out of a better algorithm. My evolution as a Haskell programmer is to  
say things more clearly with less fuss, not to get the machine to go  
faster.