Taking a step back

[Greg Weber]

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.

I have to say that I think very few people are choosing not to use Haskell
because there are breaking changes to the language.

In fact, this problem didn't register as a major concern in FPComplete's
survey
https://www.fpcomplete.com/blog/2015/05/thousand-user-haskell-survey

If anything new releases with improvements (breaking or not) get people
excited about using Haskell.
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.

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.
https://github.com/bos/aeson/pull/288

On Tue, Oct 20, 2015 at 12:24 PM, Ivan Perez <ivan.perez at keera.co.uk> wrote:

> On 20/10/15 19:47, Mike Meyer wrote:
>
> On Tue, Oct 20, 2015 at 1:35 PM Gregory Collins <greg at gregorycollins.net>
> wrote:
>
>> 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
>> *costs* 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.
>>
>
> 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 don't know about them, I can tell you my personal experience.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Does that more or less answer your question?
>
> Cheers
>
> Ivan
>
> 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.
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151020/d24cf196/attachment.html>