Taking a step back

[Ivan Perez]

On 20/10/15 19:47, Mike Meyer wrote:
> On Tue, Oct 20, 2015 at 1:35 PM Gregory Collins 
> <greg at gregorycollins.net <mailto: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151020/8807454a/attachment.html>