Dependency breakage is certainly an unavoidable problem.  However, I think Haskell is also in a much better position for having a technical solution to the frustration of breakages.

Barring issues with changing datatypes / class instances, we can already express many of the API changes you'd want to make to some library [1].  Now, no one actually does what this proposal suggests - it's a lot of work, and it doesn't work in general.  However, the fact that Haskell makes something like this seem reasonable is heartening.

Of course, even if we had good tools that automatically refactored code to use new APIs, it wouldn't be possible for any non-superficial changes.  Even so, if a good enough refactoring tool existed, and it was popular with both authors and users, a lot of the annoyance of dependency breakages could be removed.

-Michael

[1] http://haskellwiki.gitit.net/The%20Monad.Reader/Issue2/EternalCompatibilityInTheory



On Fri, May 3, 2013 at 2:04 AM, Ertugrul Söylemez <es@ertes.de> wrote:
Raphael Gaschignard <dasuraga@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