[Haskell-cafe] Re: Silly I/O question

John Goerzen jgoerzen at complete.org
Tue Sep 28 19:43:23 EDT 2004


On 2004-09-28, Alastair Reid <alastair at reid-consulting-uk.ltd.uk> wrote:
> On Tuesday 28 September 2004 22:19, John Goerzen wrote:
> That said, if you want to write a cat-like program which is as fast as Unix 
> cat, you should not process data a character at a time or a line at a time 
> but, rather, read fixed size blocks.  Ideally the block size would match what 

Right.  However, the way to do that is not really apparent from the
docs.

> ps It sounds like you're trying to learn Haskell by writing programs with lots 
> of I/O in them.  This isn't really playing to Haskell's strengths and forces 
> you to learn some tricky stuff (and, if chasing performance, learn some 
> murky, non-portable libraries) before you learn what Haskell is really good 
> for.

I appreciate the wisdom, Alastair, and understand what you're saying.
Partly you are seeing these I/O-related questions because I've figured
out other things without help :-)

At the same time, I'm not new to functional programming, nor to lazy
evaluation (though it has been some time since I've worked with it
extensively), and have been spending a lot of time with OCaml recently.
It strikes me as very similar to Haskell in several ways.

Most of the programs I write are I/O intensive.  I/O is the most, well,
different thing about Haskell when compared to my prior experiences.  I
have no problem framing tasks recursively, for instance.

One of the things I do when I learn a new language is to try to probe
where its weaknesses are.  I'm not saying I/O is a weakness in Haskell;
just that it was a cause for concern after the shootout results on
Alioth.  (BTW, I, having known Haskell for a few hours, did manage to
speed up one of them by a factor of three while still using only one
line of code, so things may not be so bad <g>)  The fact that so many
Haskell tutorials save I/O for many chapters down, or even don't bother
to cover it at all, is a cause for concern for a hacker-type like me.

No, I'm not going to bother with murky low-level hackish libraries for
I/O.  I just want to understand the strengths and limitations of the
existing system.  OCaml's system is blazingly fast.  But Haskell's is,
well, beautiful.  I like that.

I/O is very critical to a lot of different applications.  I think maybe
Haskell is shortchanged in that department sometimes, and just suffers
from some under-documentation.  (Hal Daume III's Yet Another Haskell
Tutorial had a great down-to-earth coverage of it that was accessible
and easy to follow.)





More information about the Haskell-Cafe mailing list