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 

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?


On 3 May 2013, at 10:04, Ertugrul Söylemez <> wrote:

> Raphael Gaschignard <> 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 mailing list

Reply via email to