

What I Wish I Knew When Learning Haskell - tenslisi
http://dev.stephendiehl.com/hask/#intro

======
dljsjr
Personally, I like to follow the mantra _cabal is not a package manager_.
Because whenever I treat it like one, I get messed up in a bad way. I buy in
to this argument[1] as to why it isn't.

[1]: [http://ivanmiljenovic.wordpress.com/2010/03/15/repeat-
after-...](http://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-
cabal-is-not-a-package-manager/)

~~~
CJefferson
That argument seems more like (ignoring the naming issues of cabal vs cabal-
install), that cabal is a terrible package manager, but still (to me) seems to
bare all the major features of a package manager.

~~~
dljsjr
The fact that it forwards package registration to the underlying ghc-pkg
system, has very poor/nearly nonexistent record keeping, and can't perform
uninstall operations are kinda crucial. I've never heard of a packager manager
that can't uninstall.

If you present it as a package manager, even if it's a bad one, then you also
telegraph a certain amount of implied functionality, and in turn the user has
a certain level of confidence that the system is smart enough to do its best
to prevent you from damaging your package ecosystem (not a guarantee, but at
least an effort); cabal and by extension cabal-install doesn't provide this at
all. It simply provides a way to install packages and makes a best effort at
meeting the build goals required for individual commands to succeed in a
vacuum.

I hesitate to call that a package "manager". It's just a very mediocre package
installer.

~~~
Siecje
> I've never heard of a packager manager that can't uninstall.

easy_install

------
platz
I wish I knew what changed from the last time this was posted 2 months ago:
[https://news.ycombinator.com/item?id=7637278](https://news.ycombinator.com/item?id=7637278)

Also I believe last time Stephen was surprised folks had gotten a hold of
content on his "pre-prod" domain (e.g.
[http://dev.stephendiehl.com/](http://dev.stephendiehl.com/)), because he was
still working on that post, before it was ready.

I like points as much as the next person, but maybe "pre-release" content
should not be posted to aggregreators like HN before they are "realeased"

That said I'm excited he's continuing to update this series, it's helped a lot
of people and there is a ton for me to learn still!

~~~
tenslisi
It appears to be twice as long as the old 2.0 version, and a lot of the latest
GHC 7.8 topics which wasn't released before the last version.

~~~
platz
That's helpful, thanks

------
taeric
I have to say that this line irks me: "Any preconceptions one might have for
the word 'return' should be discarded, it has an entirely different meaning."

This sentence literally does nothing to help me even prepare to understand
what is about to be explained. At the least, give a small example of what
preconceptions should go. "All of them" implies that someone did a crap job of
naming this thing.

Edit: Apologies to all responses. I responded to two, but I'm not sure I have
different responses for each. If it seems I've ignored some aspect, apologies.

~~~
nilkn
That sentence could have more information, but I think it still serves a
worthwhile purpose. It's basically saying that, for now, think of "return" as
a new thing you've never seen before and don't worry about correlating it with
what you already have seen in other languages.

In Haskell, 'return' creates a monadic value. Here are some excerpts from
Learn You A Haskell for Great Good:

> If you've done imperative languages like C, Java or Python, you're probably
> thinking that you know what this return does and chances are you've already
> skipped this really long paragraph. Well, here's the thing: the return in
> Haskell is really nothing like the return in most other languages! It has
> the same name, which confuses a lot of people, but in reality it's quite
> different. In imperative languages, return usually ends the execution of a
> method or subroutine and makes it report some sort of value to whoever
> called it. In Haskell (in I/O actions specifically), it makes an I/O action
> out of a pure value. If you think about the box analogy from before, it
> takes a value and wraps it up in a box. The resulting I/O action doesn't
> actually do anything, it just has that value encapsulated as its result.

...

> return is sort of the opposite to <-. While return takes a value and wraps
> it up in a box, <\- takes a box (and performs it) and takes the value out of
> it, binding it to a name.

[http://learnyouahaskell.com/input-and-
output](http://learnyouahaskell.com/input-and-output)

~~~
taeric
I should have been clearer, myself. My problem is not that I may have to drop
preconceptions from other programming languages. My beef is that the word has
meaning outside of programming. And is part of the reason it was chosen in
said programming languages.

Imagine if it was called "name". And we had to "throw out all preconceptions
you have with the word 'name.'"

~~~
Filligree
It works in that sense, though.

"return x" is a monad (mobit?) which, when evaluated, returns x. The trick is
that it's a distinct function, not a command.

~~~
taeric
Exactly. My (terribly made) point is I am _not_ throwing out all of my
preconceptions. :)

