On Thu, Feb 6, 2014 at 9:36 PM,
... Haskell seems worse to me in that if package foo is updated, every other package depending on foo (recursely) must then be rebuilt, even if they didn't change and even if the interface presented by foo didn't change.
This is something of a problem, yes... but it's not really "Haskell"'s fault. It's a specific design decision in GHC, in the name of performance: aggressive cross-module inlining means that specific compilation details of dependencies leak into the ABI of their dependents, necessitating exact ABI matches instead of simply consonant versions as in (normal) C. (For comparison, note that KDE has often had exactly the same problem in C++, through using cpp macros in place of inline functions for performance on "hot paths"; the exact macro and *every* (external or internal) function/method/variable it touches becomes part of the "public" ABI that must be maintained for compatibility.) Other Haskell compilers such do things differently. ajhc is a whole-program compiler, so in fact you *always* compile your dependencies again from source. uhc I don't think does the same amount of cross-module inlining, at a performance cost but maintainability gain. (And "Cabal hell" is shooting the messenger; it's just reporting the mess ghc has made / will make.) I do find myself wondering if anyone has checked to see how important the inlining is these days; perhaps ghc's general performance (and a hat tip to Moore's law) has made it possible to consider compiling more stable libraries. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net