On 5/16/12 4:37 PM, Gregg Lebovitz wrote:
1) Outstanding best practices documents that capture this knowledge and provides useful answers. Organizing this information in an online document that can be searched by keyword or index would be really helpful. The hard part will be maintaining it. As someone already pointed out the wiki entry on performance is already dated.
In light of that fact, and the general high-pace of innovation in Haskell, I think that rather than trying to keep a wiki up-to-date, it would probably be better to create a series of time-stamped "formal" documents--- like how HCAR is published. The benefit of such an approach is two-fold. On the one hand, there's a date right there which shows when the contents were relevant (e.g., on which version of GHC one particular style performed better than another). On the other hand, when putting out the next issue/version the authors are forced to revisit the old content and ask whether it's still relevant or whether the tides have shifted; and if they're not willing to commit one way or another, the content can be dropped without eliding the fact (written in the previous issue) that it used to be an optimization. Another thing I think is important is to give the actual reasons why some particular thing is an optimization, and more particularly why it is no longer an optimization once things have changed. A big issue I've run into with blog-posts etc on performance in Haskell is that there's a lot of folkloreism and just-so stories which tell people "just do X", without explaining how X differs from Y, why X is better or worse than Y, or the circumstances under which you may prefer Y to X. Without providing the details about why something is an optimization/pessimization, we don't provide users with the tools to figure things out for themselves in this everchanging world. -- Live well, ~wren