Hacker News Reader

Comment by jabberwock | Hacker News Reader

I think the Haskell folks would do well to consider a complete rewrite of Cabal and look at something like Leiningen, Npm or even Opam as a base from which they can start with their new version.

View on HN

That doesn't solve the problem. The problem is that the problems Cabal faces are real, which is to say, faced by every language that allows you to use packages from external entities, and the solution almost every other package manager uses is to sweep the problems under the rug and hope for the best. Haskell the language can't do that very well (because it is already careful under the hood), and Haskell the community won't do that.

I'm actually intrigued to see what comes out of this. When the Haskell community turns its mind to something like this, something quite interesting tends to come out.

Like many people have pointed out, cabal and npm are not solving the same problem. npm appears to "work" more often because a whole class of problems in Javascript program are deferred to runtime while in Haskell all interfaces have to be compatible, link properly and compile. That's why "cabal hell" is such an imprecise term because on top of the version bound issues it's also used for any and every failure that happens when using cabal, even if it's the library in question that's to blame and not cabal. If you want to consider a similar problem, take 20 interdependent C++ libraries and try to link them into a single application using just version information and see how often that works out of the box.

I think that's only a part of it. I think that it's also the case that the Haskell ecosystem has more breaking changes at the root of diamonds in the dependency graph - which isn't something a build tool can solve (or at least isn't something any build tool does solve).

In my experience the dependency graph often has many more nodes as well. I'm not sure if this is because Haskell code is especially reusable or Haskell developers are especially lazy.

There is an ambient culture of code reuse at a level I don't see elsewhere, that's one of Haskell's strength's in my opinion. Though it does make certain packaging problems more difficult.

High levels of abstraction and well defined edges mean more opportunities for reuse, which probably contributes to both.

You can (and I do) use npm and Node.js with type checking at compile time using TypeScript. Although to be honest it doesn't play that well with different versions of the same type definition, but in principle you could have two header files of the same library and the compiler will create an error on a type mismatch.

Reply on news.ycombinator.com