<div dir="ltr">That is very interesting, I just want to second Vincent because what I have read here initially was the exact opposite of the impression I had online.<div><br><div>From my probably biased point of view, the most visible and vocable persons who are being upset recently about FRP seems to be teachers and academics! Which is I must admit was extremely surprising to me.<div>Most haskellers I know working in the industry, or on open source libraries, seems to be totally fine with the change (and usually they got aware of it long time ago... when it was discussed).</div></div></div><div><br></div><div>Like some others have pointed out, it feel to me that it's much more an issue about communication than anything else.</div><div><br></div><div>Cheers</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 22 October 2015 at 12:57, Vincent Hanquez <span dir="ltr"><<a href="mailto:tab@snarc.org" target="_blank">tab@snarc.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 22/10/2015 01:42, Gregory Collins wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
All I'm saying is that if we want to appeal to or cater to working software engineers, we have to be a lot less cavalier about causing more work for them, and we need to prize stability of the core infrastructure more highly. That'd be a broader cultural change, and that goes beyond process: it's policy.<br>
</blockquote></span>
Not that I disagree that we need general stability but,<br>
<br>
I think it's quite unfair to say that working software engineers are being pushed away because of the current "instability", and actually I don't see any proof of such a thing.<br>
<br>
Working software engineers have developed methods to deal with change (or not to deal with it) for decades.<br>
To name a few with Haskell: private hackage, stackage, cabal pinning.<br>
It's also commonly available through stack nowadays.<br>
<br>
Also, having worked on multiples different Haskell teams doing commercial/professional software, compiler/libraries upgrades were never a concern of the team.<br>
It was always something that can be dealt quickly, painlessly and with a lot more certitude w.r.t the quality assurance, compared to e.g. dynamic languages where you don't have any types safety etc..<br>
<br>
I can't help but think that you meant "opensource library maintainers" instead of "working software engineers", which is somewhat a very different beast.<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Vincent</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><b>Λ\ois</b></div><div><div><a href="http://twitter.com/aloiscochard" target="_blank">http://twitter.com/aloiscochard</a></div><div><a href="http://github.com/aloiscochard" target="_blank">http://github.com/aloiscochard</a></div></div></div></div>
</div>