Isn't this a problem of timescale? Nothing can be backward compatible for ever (or at least nothing that is being developed or maintained)
There will be, in the life of non-trival length project, change. We rely (and I mean rely) on Haskell s/w that was written over 10 years ago - we accept that when we want to recompile it (about every 2/3 years as the systems it interacts with are updated) there will be a cost of change to bring it up to latest libraries etc. But the joy is that (combined with the regression and property tests around it) we can have very high confidence that once the "old" stuff recompiles it will operate the same. And as it is key to our business that is a nice feeling - let's me sleep soundly at night. The beauty of the Haskell ecosystem is that such change is nowhere as hazardous as with other approaches. Therefore its total costs are less. The experimentalism in this community is to be applauded and encouraged - it is spawning robust solutions to the "real" underlying problems of constructing a society that can actually support the technical infrastructure it is creating. Don't forget the motivation for Ada was that the projected costs of supporting the US defence infrastructure was projected to exceed the projected GDP of the US by 2012. Maintaining essential safety critical systems isn't an optional extra. We see that the same Ada-like scenario is working its way out in companies today - large Telcos, Goverment projects etc - I also see that formalism, such as embodied in Haskell, is the ONLY hope we have to contain the costs of maintenance complexity. Yes, the underlying issue is a human one - but it lies in the low value given to medium to long term sustainability of organisations (e.g Telcos) compared to the relative high value that is given to novelty. Perhaps this is an inevitable by-product of a marketing driven, short term driven business culture? Neil On 3 May 2013, at 10:04, Ertugrul Söylemez <e...@ertes.de> wrote: > Raphael Gaschignard <dasur...@gmail.com> wrote: > >> I'm pretty sure most of us have experienced some issue with >> dependencies breaking , and its probably the most frustrating problem >> we can have have in any language. It's hard not to take this all a bit >> personally. Maybe if we think more about how to solve this (getting >> people to maintain their stuff, for example) we can make the world a >> better place instead of bickering about issues that are more or less >> language-agnostic really. > > The problem can't be solved technically. It's a human problem after all > and it's amplified by the experimentalism in this community. I think > the best we can do is to acknowledge its existence, which places us way > ahead of mainstream programming communities. > > We don't pretend that type X in lib-0.1.0 is the same as type X in > lib-0.2.0. What we need to work on is the ability to actually combine > multiple versions of the same package conveniently, i.e. we shouldn't > view this combination as an error. > > > Greets, > Ertugrul > > -- > Not to be or to be and (not to be or to be and (not to be or to be and > (not to be or to be and ... that is the list monad. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
