<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Oct 20, 2015 at 1:35 PM Gregory Collins <<a href="mailto:greg@gregorycollins.net">greg@gregorycollins.net</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">The point Johan is trying to make is this: if I'm thinking of using Haskell, then I'm taking on a lot of project risk to get a (hypothetical, difficult to quantify) X% productivity benefit. If choosing it actually <b>costs</b> me a (real, obvious, easy to quantify) Y% tax because I have to invest K hours every other quarter fixing all my programs to cope with random/spurious changes in the ecosystem and base libraries, then unless we can clearly convince people that X >> Y, the rationale for choosing to use it is degraded or even nullified altogether.</div></div></div></blockquote><div><br></div><div>So I'll rephrase a question I asked earlier that never got an answer: if I'm developing a commercial project based on ghc and some ecosystem, what would possibly cause me to change either the ghc version or any part of the ecosystem every other quarter? Or ever, for that matter? I've never worked on  a commercial project that changed anything major mid-project, no matter what language it was using. As far as I'm concerned, one of the major features of stack is that it handles project-specific ecostystems cleanly and transparently.</div></div></div>