3 ms·
It's an interesting charge. Here’s my personal experience with the two cited resources, back when I was learning Haskell. YMMV. RWH’s “Here’s how you get the j
by ezyang 15y ago
It's an interesting charge. Here’s my personal experience with the two cited resources, back when I was learning Haskell. YMMV.
RWH’s “Here’s how you get the job done” style exposition did a reasonably good job of making me feel comfortable turning on profiling of my Haskell programs, but didn’t give me much sense at all of why the particular examples they chose were particularly representative of space leaks. I went on to do some amount of performance tuning of some data structures http://blog.ezyang.com/2010/03/the-case-of-the-hash-array-mapped-trie/ http://blog.ezyang.com/2010/03/the-case-of-the-hash-array-ma... ... but I still managed to miss some really obvious performance bugs that Tibell caught later when he revamped my benchmarks http://blog.johantibell.com/2011/03/video-of-my-hashing-based-containers.html http://blog.johantibell.com/2011/03/video-of-my-hashing-base... . I just didn’t know where to look! All I had were a bunch of patterns: "watch out for lazy folds", "using bang patterns can be a good thing", without any particular mental model of how to deduce these things from just looking at code.
To be honest about the Wikibooks article... I found it hard to read. (Which is terrible, since it's a wiki, and if I don't like it, I should improve the article...) Exactly why is hard to pinpoint. It might be statements like "Haskell values are highly layered"; it might be the fact that none of the examples are in motion (they don’t show before-and-after; the actual operation of the program!); it might be that in many respects, its coverage is incomplete.
Obviously, this series isn’t going to be the be-all, end-all reference for laziness. While it would be extremely gratifying to see other people take up the ghosts and presents metaphor, I’ll be content if people walk away with a sort of visceral feeling about all the churning that goes on under the hood when they write a functional program, so that it’s not surprising when a trace statement shows up much later than you expect it and so that it’s not a matter of trial-and-error inserting bang-fields and seqs.
- joelburget 15y agoReally, my reason for saying I wouldn't learn anything is because I personally learn better from concrete examples. That's why I like the RWH chapter. It gives you knowledge of how GHC represents your program, and helps you use that to change your program accordingly. Perhaps I should have reserved my criticism for the end of the series. Hopefully you will show us how to apply your model to our real programs. For instance, I think it would be neat to have a simple example of, say, folding a list. Show us what happens when we make a field strict. Show why `True || undefined` doesn't blow up. Just some suggestions. I agree with you on the wikibooks article. I included it so someone reading my comment would have a place to go for the rest of the story that RWH doesn't talk about. (By the way you might want to reformat your links, HN seems to have misinterpreted them.)
- ezyang 15y agoGood suggestions, and I hope to do them.