[Haskell-cafe] Re: Silly I/O question
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
> 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
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