Breaking Changes and Long Term Support Haskell

[Vincent Hanquez]

On 22/10/2015 01:42, Gregory Collins wrote:
>
> 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.
Not that I disagree that we need general stability but,

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.

Working software engineers have developed methods to deal with change 
(or not to deal with it) for decades.
To name a few with Haskell: private hackage, stackage, cabal pinning.
It's also commonly available through stack nowadays.

Also, having worked on multiples different Haskell teams doing 
commercial/professional software, compiler/libraries upgrades were never 
a concern of the team.
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..

I can't help but think that you meant "opensource library maintainers" 
instead of "working software engineers", which is somewhat a very 
different beast.

-- 
Vincent