Considering that this question is such a FAQ, I believe it would be worthwhile discussing what we think the 'actual problem' is.
When Algol-60 was being implemented, the challenge was how to compile using only 2000 words of memory (or something as ridiculous as that). The solution was to make a compiler with 20-odd passes.
[Sorry if the details are wrong; its from (neurological) memory]
Today not just compilers but databases are vying with each other to go back from disk to memory -- hardly surprising considering that a vanilla machine bought today has a TB of disk and GBs of memory.
In short the goal-posts shift with time and we need to readjust priorities accordingly.
For myself if the total disk usage of my haskell-related installation were to go up from being linear in the number of packages to quadratic, I am unlikely to care. Of course total naivete in package-management strategy may make it exponential which would make me sit up!
Reminds me of a restatement/corollary to Moore's law I recently saw:
Programmers' cost increase exponentially with time.
Just alpha-rename 'programmer' to 'cabal-installer'
On Thu, Dec 13, 2012 at 12:19 AM, Ertugrul Söylemez
<es@ertes.de> wrote:
I'm afraid the burden is that you would have to write the necessary Nix
expressions for your Haskell packages, so until we create a real Nix
channel for Hackage the barrier to entry is high. But it's certainly
possible as a community project.
I believe you are saying something significant here. Here's my rendering of it.
Currently we have a 'managed' hackage server talking to an unmanaged cabal client (in the sense of
http://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a-package-manager/ )
We need to move to hackage talking to a managed (as with nix) client.
So what work is needed to make this happen?
--
http://www.the-magus.inhttp://blog.languager.org