On Mon, 19 Nov 2007, brad clawsie wrote:
i would categorize myself as a purely practical programmer. i enjoy using haskell for various practical tasks and it has served me reliably. one issue i have with the library support for practical problem domains is the half-finished state of many fundamental codebases such as networking and database support.
in the perl world, support for these domains is provided through cpan, and this model is viable due to the (once) massive number of perl coders out there. in the java, c# etc world, a "batteries included" approach implies a narrowing of options, but also an immediate delivery of functionality.
Although I liked the "battery included" approach of GHC so far, I install more and more interesting "additional" libraries, and GHC is shipped with libraries I have never used. A library being shipped with GHC has the aura of being standardized. However also these standard libraries changed, and I find the interface of some of them not satisfying. Since I expect that there will never be a consensus on the definition of "relevance" or even "right interface" I think that the Hackage approach of atomic libraries is the best solution for the future. It allows me to import libraries according to my needs, whereas today the decision is often directed by "what is standard?". With this solution we wouldn't have had the FiniteMap break, we could choose more equally between different data structure collections (say Edison vs. GHC libs), monad libraries, and so on.