This is way too many needlessly rude words for what it's actually trying to say, but the underlying issue is one I've experienced.
I find it really interesting how a the success of programming language (or project) is a combination of multiple factors that aren't necessarily correlated -- like for example, the Haskell community is full of really genuinely nice people while the Linux kernel community is full of screaming. Or how lisp is famously great except that there's multiple incompatible implementations; there's nothing about lisp itself that causes that. And similarly in this case: there's nothing inherent about Haskell that required the versioning mess it seems to have* .
In all these cases there are some weak correlation: perhaps the research origins of Haskell led to a culture of respectful disagreement, perhaps the flexibility of lisp implies more differences of opinions, perhaps extra-powerful static typing leads to more breaking APIs on version bumps. But that's not enough to fully explain it. A lot of it is just how things turned out.
In an imaginary world I'd be able to just read the language spec and have enough info to judge whether to base my next project on something, but it turns out there are all these "soft" factors that matter just as much.
* You could imagine for example a different design where you get a separate copy of all needed libraries for each project so that they never stomp on each other (like what the various fooenv tools do for ruby/python/etc.). It has different tradeoffs, sure, but it at least superficially seems it would reduce frustrations like in this post.
Yeah, up to a point, the maturity of a language's ecosystem matters much more than the quality of the language. That's the main reason I still choose Python for my web-related projects. Haskell, Clojure, Go, Racket or Arc might all be more powerful languages in principle. But in Python or Ruby, I can pretty much assume there's already a library to do anything I want to do with minimal fuss. For these niche or up-and-coming languages, not so much.
I'm disappointed to hear the Haskell toolchain is so problematic, as I was looking forward to trying Yesod.
Dont let this discourage you from trying Yesod. The Yesod team has made it really really easy to install a core of isolated packages for the framework. The problem comes from trying to upgrade. I know that sounds insane(and it is), but you should try it out, it has quite a lot to offer.
I find Python to be one of my least favorite languages in terms of the design of the language, but the one I end up using the most for the reasons you mention.
You would think by this point all languages would have standardized on a basic library. I mean, if you're not starting off with what Python (or even Mono for that matter) already has, then you're just making things needlessly complicated for yourself.
Everyone goes crazy over syntax and idioms and OMG GROUNDBREAKING NEW IDEAS (not) when really 85% of a language depends on the library and toolchain.
The differences between standard libraries, programming idioms, communities and ethos often play a large role in defining a new language, so surely sharing a standard library would in many ways defeat the point of trying something new?
A programming language is not just a spec and a syntax, it's also a way of seeing the world - "The limits of my language mean the limits of my world.", so to get a new way of looking at things, you also need to reinvent the basics to some extent, and rethink how (for example) basics like errors, threads or strings are handled.
Personally, I think it's useful to have a multipolar programming landscape, even if it sometimes leads to duplicated work, because it can give you a fresh perspective on old problems.
I'm hardly an advanced Cabalist, but it does the job nicely for me, and is quite stable at that too. Like virtualenv, it can also create a "sandboxed" GHC, so even system-level updates to GHC don't wreak havoc in your projects.
cabal-dev is close to giving you a separate copy of all needed libraries for your projects. It just doesn't do it for dependencies of your dependencies
"It just doesn't do it for dependencies of your dependencies"
Yes, it does. cabal-dev can install a fully hermetic package database if you ask it to, but by default it only installs packages that aren't already present in your global package db.
I find it really interesting how a the success of programming language (or project) is a combination of multiple factors that aren't necessarily correlated -- like for example, the Haskell community is full of really genuinely nice people while the Linux kernel community is full of screaming. Or how lisp is famously great except that there's multiple incompatible implementations; there's nothing about lisp itself that causes that. And similarly in this case: there's nothing inherent about Haskell that required the versioning mess it seems to have* .
In all these cases there are some weak correlation: perhaps the research origins of Haskell led to a culture of respectful disagreement, perhaps the flexibility of lisp implies more differences of opinions, perhaps extra-powerful static typing leads to more breaking APIs on version bumps. But that's not enough to fully explain it. A lot of it is just how things turned out.
In an imaginary world I'd be able to just read the language spec and have enough info to judge whether to base my next project on something, but it turns out there are all these "soft" factors that matter just as much.
* You could imagine for example a different design where you get a separate copy of all needed libraries for each project so that they never stomp on each other (like what the various fooenv tools do for ruby/python/etc.). It has different tradeoffs, sure, but it at least superficially seems it would reduce frustrations like in this post.