

Why inbreeding is bad for your community - denzil_correa
http://www.txt.io/t-2kv5h

======
jmillikin
(reposting my comment from Reddit)

I don't understand why he wanted to reinstall things so often; it would have
been much easier (and certainly faster) to just install libraries once.

The first problem is that he didn't read any of the Cabal documentation. He
complains that after upgrading his Cabal binary, that it still complains that
an update is needed. I'm almost certain this is because he hasn't put the
Cabal binary directory (~/.cabal/bin) on his $PATH. While this is arguably
something that Cabal should be detecting and warning about, it's also not a
requirement unique to Haskell -- any package manager that installs to a user's
home directory will need them to change their $PATH.

Continuing on, he installs cabal-dev (good!), then proceeds to not use it.
Instead, he tries to jam all of Yesod (a notoriously version-picky package)
into his global package directory.

Then he uses cabal-dev to build his new site, and here's where things get
weird. It should absolutely not install anything other than what his
particular package needs as dependencies. If it's installing the world again,
then there is something horribly misconfigured on his system.

Finally, I strongly object to Yesod being considered a "success story". While
web frameworks are currently the hip thing, and Yesod is indeed a web
framework, to my knowledge it's gained no significant userbase in part due to
the huge nest of conflicting library versions that it depends on.

Here's what he needs to do:

    
    
      # Clean up whatever mess he's currently made
      $ rm -rf ~/.cabal ~/.ghc
    
      # Re-initialize Cabal
      $ export PATH="$HOME/.cabal/bin:$PATH" # optionally add to .bashrc
      $ cabal update
      $ cabal install cabal-install cabal-dev
    
      # Assuming that Yesod is using standard Haskell packaging properly, this
      # should install Yesod in its own little sandbox so it won't destroy the rest
      # of the system.
      $ mkdir my-yesod-project
      $ cd my-yesod-project
      $ export PATH="$PWD/cabal-dev/bin:$PATH"
      $ cabal-dev install yesod
    
      # Now Yesod can be used without fear
      $ yesod init .
      $ cabal-dev install

~~~
dllthomas
Ideally, getting a basic setup going shouldn't take a deep-read of the docs of
my package manager. This is absolutely a weakness of the current Haskell
ecosystem; perhaps not as bad as presented in the post here, but something
that deserves improvement.

Contrary to the thesis of the post, the haskell community seems to be well
aware of this, and there are several attempts to fix it being actively worked
on, just nothing particularly standardized yet. Meanwhile, cabal-dev lets
people get work done.

~~~
jmillikin

      > Ideally, getting a basic setup going shouldn't take a
      > deep-read of the docs of my package manager.
    

Please name one package manager which installs binaries to the user's home
directory, but doesn't require updating the user's $PATH.

~~~
tedivm
>>Ideally, getting a basic setup going shouldn't take a deep-read of the docs
of my package manager.

>Please name one package manager which installs binaries to the user's home
directory, but doesn't require updating the user's $PATH.

Do you even realize how little those two statements follow each other? The
whole red herring argument here is kind of annoying, but I'll hit it anyways-
every package manager that I've used which installs binaries (or anything,
really) in the user's home directory (or any directory really) does make me
update the path- but it also tells me this and gives me sane errors when that
hasn't happened.

~~~
jmillikin
In my experience, other package managers (my experience is with Python's and
Ruby's) will behave just like Haskell's. Specifically, they do not seem to
inspect the user's $PATH variable to determine whether their default
installation directory is present.

~~~
wowzer
Having used both Haskell's package manager cabal and Python's pip and
easy_install. Cabal has a long way to go before it's anything like pip. You
can see cabal moving in the right direction, but pip is leagues ahead of it
right now, especially when using virtualenv.

~~~
jmillikin
In what ways do you find pip better than cabal, or pip+virtualenv better than
cabal-dev?

------
evmar
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.

~~~
graue
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.

~~~
Cacti
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.

~~~
grey-area
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.

------
aristidb
While it is true that some of those problems are real, this level of rudeness
is just not acceptable. Especially the accusation of "inbreeding".

One thing that is wrong is the lack of "semantic versioning". There is the
Package Versioning Policy
(<http://www.haskell.org/haskellwiki/Package_versioning_policy>), and most
packages now adhere to it. Granted, its prescriptions differ from "semantic
versioning", and some people disagree that Haskell packages should specify
such restrictive versioning boundaries all the time.

(The PVP essentially says that for a version a.b.c.d, every change of a or b
means that the API might have changed. Now it might be that most packages are
not even affected by the change...)

~~~
dllthomas
I admit, not having published a haskell package yet, that I've only done a
shallow reading of the PVP - is it actually incompatible with semantic
versioning or orthogonal? That is, is it possible in the general case to
adhere to both? If not, are they incompatible in most cases or very few?

~~~
aristidb
This is the biggest difference (quote from semver.org):

"Major version X (X.y.z | X > 0) MUST be incremented if any backwards
incompatible changes are introduced to the public API. It MAY include minor
and patch level changes. Patch and minor version MUST be reset to 0 when major
version is incremented."

Meanwhile the PVP lets you get away with just updating the minor version
there.

~~~
dllthomas
Oh, I realize that PVP does not require everything semantic versioning does.
It sounds like PVP requires nothing semantic versioning forbids, nor vice-
versa? In which case, you could (and, I would assert, should) follow both.

------
NullSet
The problem with packages and Haskell is well known; there are a few camps
currently trying to solve the issue. Personally, (although the author went
about things in a rather roundabout way) I can feel for the author. I LOVE
Haskell, I cannot think of a better language for prototyping crazy ideas in
and I work in it every chance that I get; that being said, its awful to get up
and running with cabal. The suggestion which has been posed to me is "simply
use cabal-dev", when I do this, I wind up with crazy huge project files
because of repeat installs. I sincerely hope that someone much smarter than
myself can come up with a solution for this; I think it is a primary reason
why Haskell is not being more widely adopted.

References(for those who are interested)
<http://www.yesodweb.com/blog/2012/04/replacing-cabal>
<http://www.yesodweb.com/blog/2012/03/cabal-nirvana>

Hopefully the guys at FP complete will redirect some of their focus onto this
(please oh please). <http://fpcomplete.com/>

------
codewright
This has been my experience with Haskell as well, however, the extremely
helpful and pleasant community makes up for it.

If this rather rude character is repulsed by Haskell then I think the
community is probably better for it.

------
peripetylabs
Why not learn Haskell and contribute, instead of being nasty?

On second thought, people this rude should stay away from Haskell.

~~~
klez
> Why not learn Haskell and contribute, instead of being nasty?

Catch-22, he can't contribute if he can't bootstrap a development environment
:)

------
realrocker
Whoa, deja vu right there and "ivanm" did try his best to help me too.cool
guy. cabal still doing that, hunh

------
mck-
500 Error here

~~~
btilly
Ditto. But a Google search for cache:www.txt.io/t-2kv5h directed me to
[http://webcache.googleusercontent.com/search?hl=en&sclie...](http://webcache.googleusercontent.com/search?hl=en&sclient=psy-
ab&q=cache%3Awww.txt.io%2Ft-2kv5h&oq=cache%3Awww.txt.io%2Ft-2kv5h&gs_l=serp.3..0l4.2104.8095.0.8352.8.8.0.0.0.0.313.756.1j3j0j1.5.0.les%3Befrsh..0.3...1.1j2.ti_Xcu3LRm0&pbx=1)
which had the original content.

