3 ms·

No because that dependency hell is up front (Haskell ecosystem likes being explicit). Whereas in dynamic languages you just install it all and hope it doesn't

No because that dependency hell is up front (Haskell ecosystem likes being explicit). Whereas in dynamic languages you just install it all and hope it doesn't crash (and your unit test coverage is sufficient).

taeric 13y ago
Firstly, I think this is somewhat unfair to dynamic solutions. I could just as easily reword it as "you try and pull in a library and hope it doesn't break your compilation." Simply put, it could be the up front hell that probably puts a lot of people off of a solution. Not to mention adding a new piece to a highly type based solution could involve modifying a lot of the existing types to make room for the modification. Whereas with many dynamic solutions, this is not the case.
- deleted 13y ago
  [deleted]
- nightski 13y ago
  It is more of a contract. The library author is stating this package was developed against these dependencies and versions. It is known to work well in these cases. This does not mean it will not compile. In fact often the fix is simply for the author or developer to relax the version bounds and everything will be fine. Lastly, many of these issues arise not because of a direct dependency but an indirect one. The problem is that GHC will not allow you to depend on two packages which themselves depend on different versions of the same package. Once this is fixed, along with sandboxing, will eliminate the vast majority of the cabal hell problem.
  - taeric 13y ago
    I still feel you are being a touch unfair to the dynamic world. Many times, bringing in a dependency just works. The analogy I have in my mind is a digital computer for a bike. The general "contract" is simply that you will somehow get a pulse to the computer for each rotation of a tire with a known size. The details of how the bike is constructed are ultimately irrelevant. Further, because this is such a general contract, it doesn't actually matter if you hook it to the wheel or not. You can, in fact, use such a computer in a non bike device with success.
    - tel 13y ago
      There's work to provide this "module by contract" notion you're talking about exactly (http://www.mpi-sws.org/~skilpat/backpack/ http://www.mpi-sws.org/~skilpat/backpack/) but it's very new and far from implementation. OCaml does a good job of this and is usually the poster child for parametric modules done right. That said, dynamic languages allow this kind of contractual module imputation by the virtue of allowing absolutely anything to be considered a module and hashed out at runtime. At the least this means carrying around a lot of tagging/runtime typing information so you can call up runtime errors. At the most, it means that your whole system is held together by an increasingly wide set of unchecked and uncheckable assumptions. Cabal hell is annoying but at least it's checking.

taeric 13y ago

Firstly, I think this is somewhat unfair to dynamic solutions. I could just as easily reword it as "you try and pull in a library and hope it doesn't break your compilation." Simply put, it could be the up front hell that probably puts a lot of people off of a solution. Not to mention adding a new piece to a highly type based solution could involve modifying a lot of the existing types to make room for the modification. Whereas with many dynamic solutions, this is not the case.

deleted 13y ago
[deleted]
nightski 13y ago
It is more of a contract. The library author is stating this package was developed against these dependencies and versions. It is known to work well in these cases. This does not mean it will not compile. In fact often the fix is simply for the author or developer to relax the version bounds and everything will be fine. Lastly, many of these issues arise not because of a direct dependency but an indirect one. The problem is that GHC will not allow you to depend on two packages which themselves depend on different versions of the same package. Once this is fixed, along with sandboxing, will eliminate the vast majority of the cabal hell problem.
- taeric 13y ago
  I still feel you are being a touch unfair to the dynamic world. Many times, bringing in a dependency just works. The analogy I have in my mind is a digital computer for a bike. The general "contract" is simply that you will somehow get a pulse to the computer for each rotation of a tire with a known size. The details of how the bike is constructed are ultimately irrelevant. Further, because this is such a general contract, it doesn't actually matter if you hook it to the wheel or not. You can, in fact, use such a computer in a non bike device with success.
  - tel 13y ago
    There's work to provide this "module by contract" notion you're talking about exactly (http://www.mpi-sws.org/~skilpat/backpack/ http://www.mpi-sws.org/~skilpat/backpack/) but it's very new and far from implementation. OCaml does a good job of this and is usually the poster child for parametric modules done right. That said, dynamic languages allow this kind of contractual module imputation by the virtue of allowing absolutely anything to be considered a module and hashed out at runtime. At the least this means carrying around a lot of tagging/runtime typing information so you can call up runtime errors. At the most, it means that your whole system is held together by an increasingly wide set of unchecked and uncheckable assumptions. Cabal hell is annoying but at least it's checking.