3 ms·

Something like Haskell Stack fixes a lot of problems with versions but it is not suitable for all situations. It is a lot of work to produce a curated set of pa

Something like Haskell Stack fixes a lot of problems with versions but it is not suitable for all situations. It is a lot of work to produce a curated set of packages that work. But most of the time things just work so people work around it the rest of the time.

wereHamster 9y ago
It's not stack but stackage you are referring to. Stackage puts considerable effort on the whole community to ensure that packages remain compatible, and forces package publishers (developers) to update their packages in a timely manner (otherwise the package will be dropped from the snapshot). That works in the Haskell community, but I'd be hard pressed to believe any javascript developer who has a package on npm.org would put the same amount of effort into keeping it up to date.
- kronos29296 9y ago
  Package manager is stack and the online repo is hosted at stackage. You manage packages from stackage using stack. You probably can't do it in a larger community like JS or Python because it is too big. Haskell is at the right size to do such things.
  - wereHamster 9y ago
    Not all Haskell packages (those in hackage.org) are in the stackage snapshots. Stackage is opt-in, there must be a maintainer willing to resolve the occasional build failures. That means there is no such thing as 'too big', because the number of all existing packages in a ecosystem doesn't matter. It's the commitment that counts, and that's what I don't see in the JS community.
chriswarbo 9y ago
Such curated sets make sense for "core functionality", like text handling, streaming, encoding/decoding, etc., which are used by many 'mainstream' applications (Web backends, console programs, etc.). Yet they raise the barrier to entry by placing a larger burden on developers. For example, there's a long tail of one-off packages on Hackage that are really valuable to keep around, even if they're not actively maintained and bumping versions would cause breaking changes. I'm thinking of all the various logic frameworks, theorem provers, etc. which are out there; maybe to accompany some paper from the 90s. They're certainly not "core functionality", but every now and then it may turn out that one of them is exactly what is needed in some app/library. Every few years the major repos may drop the last working version of GHC, so someone may have to step up and do the required fixes, but that's few and far between. These days I use a combination of Hackage (all versions of all packages), Cabal (to solve dependencies), tinc (to make Cabal deterministic) and Nix (to cache everything).

wereHamster 9y ago

It's not stack but stackage you are referring to. Stackage puts considerable effort on the whole community to ensure that packages remain compatible, and forces package publishers (developers) to update their packages in a timely manner (otherwise the package will be dropped from the snapshot). That works in the Haskell community, but I'd be hard pressed to believe any javascript developer who has a package on npm.org would put the same amount of effort into keeping it up to date.

kronos29296 9y ago
Package manager is stack and the online repo is hosted at stackage. You manage packages from stackage using stack. You probably can't do it in a larger community like JS or Python because it is too big. Haskell is at the right size to do such things.
- wereHamster 9y ago
  Not all Haskell packages (those in hackage.org) are in the stackage snapshots. Stackage is opt-in, there must be a maintainer willing to resolve the occasional build failures. That means there is no such thing as 'too big', because the number of all existing packages in a ecosystem doesn't matter. It's the commitment that counts, and that's what I don't see in the JS community.

chriswarbo 9y ago

Such curated sets make sense for "core functionality", like text handling, streaming, encoding/decoding, etc., which are used by many 'mainstream' applications (Web backends, console programs, etc.). Yet they raise the barrier to entry by placing a larger burden on developers. For example, there's a long tail of one-off packages on Hackage that are really valuable to keep around, even if they're not actively maintained and bumping versions would cause breaking changes. I'm thinking of all the various logic frameworks, theorem provers, etc. which are out there; maybe to accompany some paper from the 90s. They're certainly not "core functionality", but every now and then it may turn out that one of them is exactly what is needed in some app/library. Every few years the major repos may drop the last working version of GHC, so someone may have to step up and do the required fixes, but that's few and far between. These days I use a combination of Hackage (all versions of all packages), Cabal (to solve dependencies), tinc (to make Cabal deterministic) and Nix (to cache everything).