<div dir="ltr">7.10 cost me an hour on a 60k loc project.<div><br></div><div>Aeson 0.10 (<3 you Bryan, but this was brutal) cost me a couple days on a 2k loc project and I'm still not totally satisfied with how things have settled yet.</div><div><br></div><div>Going to concur with Greg here.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 20, 2015 at 4:01 PM, Greg Weber <span dir="ltr"><<a href="mailto:greg@gregweber.info" target="_blank">greg@gregweber.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">stack and Travis CI make it easy for library authors to make sure their libraries work across multiple versions of GHC. For users, it makes it easier to install the newest version of GHC.<div><br></div><div>I have to say that I think very few people are choosing not to use Haskell because there are breaking changes to the language.</div><div><br></div><div>In fact, this problem didn't register as a major concern in FPComplete's survey</div><div><a href="https://www.fpcomplete.com/blog/2015/05/thousand-user-haskell-survey" target="_blank">https://www.fpcomplete.com/blog/2015/05/thousand-user-haskell-survey</a></div><div><br></div><div>If anything new releases with improvements (breaking or not) get people excited about using Haskell.</div><div>When people talk about stability, they are generally thinking about whether the platform is buggy, and whether they can get a stack trace when there is a bug, not about upgrade cycles. For new users, upgrade cycles tend to be an afterthought. </div><div><br></div><div>The burden is placed on open-source library authors like Johan and myself. In general we would like to spend our time on things that produce new value and minimize spending time keeping things working how they are now. If you don't even believe the change prompting this work tax is a useful one, I can definitely see how it would be demoralizing. In my case I can say that for the last GHC release, members of the community that started using the pre-release contributed a lot of patches for the upgrades, so it actually did not bother me too much. On the other hand, aeson's latest release with unnecessary and undocumented breaking changes created hours of work for me for absolutely no reason.</div><div><a href="https://github.com/bos/aeson/pull/288" target="_blank">https://github.com/bos/aeson/pull/288</a><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Tue, Oct 20, 2015 at 12:24 PM, Ivan Perez <span dir="ltr"><<a href="mailto:ivan.perez@keera.co.uk" target="_blank">ivan.perez@keera.co.uk</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF"><span>
    <div>On 20/10/15 19:47, Mike Meyer wrote:<br>
    </div>
    <blockquote type="cite">
      <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" target="_blank">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?</div>
        </div>
      </div>
    </blockquote></span>
    I don't know about them, I can tell you my personal experience.<br>
    <br>
    If GHC and all libraries were perfect and free from bugs and
    ultimately optimized, then you'd be right: there would be no reason
    to change.<br>
    <br>
    But if you ever hit a bug in GHC or a library which was fixed in a
    future version, or if you want an improvement made to it, you may
    have to update the compiler.<br>
    <br>
    Library creators/maintainers do not always maintain their libraries
    compatible with very old/very new versions of the compiler. In an
    ecosystem like ours, with 3 versions of the compiler in use
    simultaneously, each with different language features and base APIs
    changed, compatibility requires a lot of work.<br>
    <br>
    This problem is transitive: if you depend on (a new version of a
    library that depends on)* a new version of base or a new language
    feature, you'll may have to update GHC. If you do not have the
    resources to backport those fixes and improvements, you'll be forced
    to update. In large projects you are likely to use hundreds of
    auxiliary libraries, so this is very likely to happen.<br>
    <br>
    I recently had to do this for one library because I could only
    compile it with a newer version of GHC. This project had 30K lines
    of Haskell split in dozens of libraries and a few commercial
    projects in production. It meant fixing, recompiling, packaging and
    testing everything again, which takes days and it's not unattended
    work :( It could easily happen again if I depend on anything that
    stops compiling with this version of GHC because someone considers
    it "outdated" or does not have the resources to maintain two
    versions of his/her library.<br>
    <br>
    Does that more or less answer your question?<br>
    <br>
    Cheers<span><font color="#888888"><br>
    <br>
    Ivan<br>
    </font></span><br>
    PS. I do not use stack yet. So, I remain ignorant about that. I see
    how it could help in some cases, but not this one.<br>
  </div>

<br></div></div><span class="">_______________________________________________<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>
<br></span></blockquote></div><br></div>
<br>_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">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>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr">Chris Allen<br><div><span style="font-size:12.8000001907349px">Currently working on </span><a href="http://haskellbook.com" target="_blank">http://haskellbook.com</a></div></div></div></div></div></div>
</div>