On 2004-09-28, Alastair Reid <[EMAIL PROTECTED]> 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.) _______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
