<div class="gmail_quote">On Tue, Jan 31, 2012 at 9:19 PM, Steve Severance <span dir="ltr">&lt;<a href="mailto:sseverance@alphaheavy.com">sseverance@alphaheavy.com</a>&gt;</span> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>The other thing is that deepseq is very important . IMHO this needs to be a first class language feature with all major libraries shipping with deepseq instances. There seems to have been some movement on this front but you can&#39;t do serious parallel development without it.</div>

<div></div></blockquote></div><div><br></div><div>I completely agree on the first part, but deepseq is not a panacea either. It&#39;s a big hammer and overuse can sometimes cause wasteful O(n) no-op traversals of already-forced data structures. I also definitely wouldn&#39;t go so far as to say that you can&#39;t do serious parallel development without it!</div>
<div><br></div><div>The only real solution to problems like these is a thorough understanding of Haskell&#39;s evaluation order, and how and why call-by-need is different than call-by-value. This is both a pedagogical problem and genuinely hard -- even Haskell experts like the guys at GHC HQ sometimes spend a lot of time chasing down space leaks. Haskell makes a trade-off here; reasoning about denotational semantics is much easier than in most other languages because of purity, but non-strict evaluation makes reasoning about operational semantics a little bit harder.</div>
<div><br></div><div>In domains where you care a lot about operational semantics (like parallel and concurrent programming, where it&#39;s absolutely critical), programmers necessarily require a lot more experience and knowledge in order to be effective in Haskell.</div>
<div><br></div><div>G</div>-- <br>Gregory Collins &lt;<a href="mailto:greg@gregorycollins.net" target="_blank">greg@gregorycollins.net</a>&gt;<br>