[Haskell-cafe] Re: Haskell Speed

[Paul Moore]

On 25 Dec 2005 12:24:38 +0100, Peter Simons <simons at cryp.to> wrote:
> Paul Moore writes:
>
>  > It would be interesting to see standalone code for wcIOB
>  > (where you're allowed to assume that any helpers you
>  > need, like your block IO library, are available from the
>  > standard library). This would help in comparing the
>  > "obviousness" of the two approaches.
>
> A simple version of the program -- which doesn't need any
> 3rd party modules to compile -- is attached below. My guess
> is that this approach to I/O is quite obvious, too, if you
> have experience with system programming in C.

Hmm, I can't honestly believe that you feel that your code is as
"obvious" as the original. I'm not unfamiliar with monads and state,
and I know C well, but it took me a significant amount of time to
decipher your code (even knowing what it was intended to do), whereas
I knew what the original was doing instantly.

> IMHO, the main point of the example in the article is that
>
>   wc :: String -> (Int, Int, Int)
>   wc file = ( length (lines file)
>             , length (words file)
>             , length file
>             )
>
> is a crapy word-counting algorithm.

Dunno. It's certainly not a bad (executable!) definition of the
problem. My point is that Haskell allows me to write *very* clear
"executable pseudocode", but that code is not a good starting point
for writing production-quality code.

To me, the point of the original article was to demonstrate how to get
from the original version to an efficient version, in reasonable
steps. I'm not sure how well it achieved that - particularly as the
final code didn't clearly (to me) separate out standard libraries,
supporting (but non-standard) libraries, and application code. But the
article was specifically noted to be incomplete by the author, so
that's not unsurprising.

> I'm not sure whether
> conclusions about functional programming in general or even
> programming in Haskell can be derived from this code. Most
> people seem to have trouble with lazy-evaluation, first of
> all.

The biggest conclusion to me is that techniques for *readable* and
"obvious" code in Haskell differ significantly from techniques for
efficient code. I think that conclusion is not isolated to this one
specific example...

Back to where this came from, my view is that this is an education
issue - tutorials tend to focus on lazy, functional techniques, and
not on efficiency. This is true for C (or any other language)
tutorials as well, but in languages where the step from naive to
efficient code isn't as large, it's not such an issue (mailing list
questions in C or Java about "my code isn't fast enough" tend to
result in advice on fairly comprehensible tweaks that can be made; in
Haskell, they tend to result in monadic rewrites which bear little
relationship to the original code - so the original poster hasn't got
much chance of understanding what happened...)

But the material is available, so people *can* learn. It just needs
some effort (but possibly more than it should...)

Paul