Speaking as an ops guy who does manage said servers, i can tell you that sandboxing apps to let them run their own dependencies is going to be the future for ops. That said, I see the value of “batteries included” because it’s great for anyone teaching anyone else which happens a lot. Having a consistent set of dependencies is also great for the systems engineers. These guys might be looking at a program’s performance in depth, so a server that may not have OpenGL installed still has a huge benefit in using a particular version of a library. The systems engineers can learn just that version of the code, understand its performance well and then pass on the requirements to the ops guys to install just enough packages and libraries in the sandbox to make the application work. The ops guys are happy because they know how many servers to provision and how the application is expected to scale because the systems engineers know every line of code in action, not just the application. So, is there value in minimal installs to facilitate sandboxing? Yup Is there an equal value in standardizing developers around specific sets of library-versions? Yup Is the future going to be ops installing Haskell Platform into a sandbox? No idea, but that’ll depend on the advocacy of Haskell Platform as the way for developers to write software, among other things Kind regards, Yaakov M Nemoy On Apr 15, 2014, at 21.52, Johan Holmquist wrote:

I strongly believe we need the HP to be able to compete with Python etc with "batteries included". Having a set of blessed packages with stable APIs makes development easier, so the HP is a very important part of the Haskell eco system IMHO.

Having graphics packages in the platform does make it a bit wierd to install on servers which are typically not equipped with OpenGL etc.

Johan

2014-04-16 4:28 GMT+02:00 Simon Hengel :

...

...

and I have a somewhat cunning plan along these lines (related to some other ghc-pkg/cabal improvement work) which might make that rather easier

what I want is for ghc itself to come with multiple profiles, with one being the minimum (base + rts + deps), and that could be used as a basis for new envs

With such a feature, it sounds like we can get the best of both worlds: * a feature-rich Haskell Platform to support beginners * minimal sandboxes for advanced users

The issue with such integrated approaches that affect the whole toolchain (ghc, cabal, etc.) is that this can seriously harm innovation, at least if the net result is that it gets harder and harder to write alternative package managers, etc.

TL;DR: If anything, we should make things *less integrated* (read more open and hackable).

Let me try to make my point by looking at Haddock. Let's assume you are not happy with the current state of Haskell documentation tools. In such a situation it can makes perfect sense to give it a fresh start. But Haddock is so integrated with GHC, Hackage, Cabal,... that this is very hard to do. You can write an alternate documentation tool, but it may be hard for potential uses to experiment with it. Currently I think the only feasible way to get your changes in or experiment with new ideas is through the current maintainer, and if the current maintainer thinks your approach is a bad idea or just does not like you or does not have the time to look at your code you may be in a situation where it's hard to improve things. There is a lack of competition and I think it is not something absurd to assume that this lack of competition results in a lack of innovation.

...

...

Where would something like the HP actually make sense? For stuff that has external dependencies that are not easily installable with cabal-install (like curses bindings, SSL support, etc.). We have none of this in the HP. So I think currently we just have additional costs, but no benefits (+ we harm innovation by arbitrarily "endorsing" random packages).

I understand this point of view, but allow me to offer an opposing one. By putting packages with external dependencies into Haskell Platform, we often increase the dependencies of Haskell Platform itself. For example, Haskell Platform currently includes Graphics packages; installing Haskell Platform on a server entails installing a number of OpenGL libraries that are never used.

My point here was that (from my perspective) the cost/benefit ratio of bundling packages that are easily installable with cabal-install is negative.

Cheers, Simon _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe