On Mon, Dec 26, 2005 at 11:58:52AM +0000, Paul Moore wrote:
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.
It is often a good start, but not always a good end ;-) Recently, I have written some code to do something we previously thought would be impractical because of unacceptable performance. I did it in Haskell in the most obvious way I could. It works, because Haskell helps me to look at the problem itself and solve efficiency problems in the big picture, not only in the details.
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...
That's not my experience. I have often been surprised that I was able to transform the "obvious", inefficient code into an efficient version in a short sequence of small steps. The best way to do this is to first modularize the code, splitting it to smaller functions, perhaps introducing some type-classes, non-IO monads, etc. If you know what you are doing, you can later optimize the code locally, modularly. Also, you say that "monadic rewrites bear little relationship to the original code". I often start writing my *pure* code in monadic form, so I have this problem much less often. A good intro to modularizing functional programs is in the "Why Functional Programming Matters" article: http://www.md.chalmers.se/~rjmh/Papers/whyfp.html I've read it when I was learning Haskell a couple of years ago, but now I know I didn't get it back then. When I read it again this week and compared it to my experiences, I thought "Wow, this man knows what he's taking about!". I daresay that if you don't say something like "Wow" while reading the article, then you didn't get it ;-)
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.
If you want to focus on efficiency from the start, you write an assembler tutorial ;-) Well, you have some point. We need "Efficient Haskell" tutorials, for people who have already gone through basic tutorials. I think there even is one or two.
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;
On the other hand, in those languages it is often difficult to write high level, specification-like code. No wonder the step is so small ;-)
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...)
You don't have that problem, if your obvious code is monadic (not neccesarily IO!) from the start ;-) Best regards Tomasz -- I am searching for a programmer who is good at least in some of [Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland