On 25 Dec 2005 12:24:38 +0100, Peter Simons
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