[Haskell-cafe] Re: Haskell Speed

[Tomasz Zielonka]

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