Taking a step back

Tue Oct 20 21:06:34 UTC 2015

7.10 cost me an hour on a 60k loc project.

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.

Going to concur with Greg here.

On Tue, Oct 20, 2015 at 4:01 PM, Greg Weber <greg at gregweber.info> wrote:

> 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
>>
>>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>

-- 
Chris Allen
Currently working on http://haskellbook.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151020/0a92d249/attachment-0001.html>