| I haven't written any Haskell code seriously in almost a year, so I may be fuzzy on the details with the following: > Likewise, when you have concrete problems, have you asked for help on #haskell irc or the Haskell-Cafe mailing list? Yes, and I will say that the Haskell community is one of the most friendly language communities in my experience. I was very impressed with the attitude on #haskell, and I wish other development communities were more like it. That said, I don't think these problems should be happening in the first place (or at least as often). For contrast, a Python package that is correctly developed inside a virtualenv with a proper requirements.txt should be easily installable via pip on any POSIX machine[1]. Haskell's language design is much more strict that Python's, so it surprises me that something like virthualenv[1] is only in alpha rather than the standard approach. If I remember correctly, my problem was that I wanted to use Snap for my application, but Snap would only compile with an older version of the same HTTP client library that was also needed for some other API library that I needed to use. Maybe there's so A (separate) problem that makes these hard to debug is the way that Haskell modules (and their documentation) are organized. The documentation is highly focused around types, which makes sense, but this causes problems if you (A) aren't sure how to use the relevant constructors, or (B) aren't sure which module provides those types. My favorite error message was something along the lines of "Data.Text.Lazy expected but found Data.Text.Internal.Lazy". Since I had at the time imported neither Data.Text nor Data.Lazy, I was left to figure out which module relied on those packages, and then which module I needed to import in order to construct the types that this module needed. This is a problem when the package names and the import paths are sufficiently different - maybe not to a veteran, but certainly to a newcomer. By contrast, certain languages have very strong cultures of documentation-by-example. Go and Python would be two easy examples. It's incredibly helpful when most packages provide a minimum of one single, straightforward example of how to use the package. It makes it much easier (As for the namespace issues, I really like the Go approach to this: the import path is just the same URL that is used for installing - ie, 'import "github.com/jbarham/go-cdb"'.) > People: hand wavy complaints that do not give concrete examples are hard to fix. It's hard to get much more specific when I'm not actively trying to solve the problem (anymore); I can't readily recreate error messages from several months ago. [1] The possible exception being issues with compiling C extensions, but that's not even the biggest issue I've found with Haskell. And yes, I know it's taken Python 20 years to reach this state, but now other languages are starting to follow in its footsteps - look at npm, for example. [2] http://hackage.haskell.org/package/virthualenv |