On 2004-09-28, Alastair Reid
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.)