
What i wish i knew when learning haskell - allenleein
http://dev.stephendiehl.com/hask/
======
baldfat
I tried to use Haskell three times. Cabal was the always the reason why I
left. I use three different machines. 2 at two different locations at work and
one at home. All three would be different and have different errors. I would
spend hours and always left with a horrible taste in my mouth.

Today I use Racket and I won't go back but I am glad Stack is taking over
Cabal.

~~~
danieldk
_Cabal was the always the reason why I left._

It is not only Cabal, but also the constant churn in a lot of packages. For
example, conduit was a great package when I used Haskell. But usually I had to
update quite a bit of code when I would bump conduit up to the latest version
after not touching a program for a year.

Maybe I have been unlucky enough to use Haskell during some transitions (pre-
arrows -> arrows rule, let's use them everywhere -> arrows suck, basic IO
monad -> iteratees, old fashioned field access -> various lens proposals ->
lens). But I never used a language ecosystem before or after where things
would change or break so often.

~~~
IngoBlechschmid
Yes, there have been quite a few transitions happening. They didn't happen
"for fun", but because it had been felt that the optimal solutions were not
found yet (optimal as in elegant, easy to use, maintainable, ...).

Luckily, Haskell's static typing coupled with the extremely helpful error
messages of the compiler makes refactoring a cheerful task: If it worked
before and all type errors have been fixed, then we can be quite confident
that it works again.

Many areas have stabilized now. For instance, Edward Kmett's lens package is
the de facto standard for all things related to records, getters, setters, and
all those things on steroids. (Personally, I love how this turned out. Before
lens, we quite frankly had the problem that field accesses were much more
painful than they are in mainstream object-oriented languages like Python or
Java. Nowadays field accesses are as simple as they are in other languages,
and in addition to this we have the flexibility of composable first-class
lenses.)

~~~
dllthomas
> all type errors have been fixed

... by someone trying to actually address the issues. There are almost always
wrong ways you can fix a type error. Fortunately, that's usually the situation
at hand...

------
fixed_carbon
As a relative newbie to Haskell, the linked document contains a lot of
information that I had wondered about but hadn't found definitive answers for
(eg. Should I be using String at all?) as well as a wealth of information I
hadn't even thought to ask yet. I suspect it's going to live in a browser tab
next to Hoogle until I get a lot more experience.

Favorite line: "Playing "type-tetris" to convert between Strings explicitly
can be frustrating." Such understatement! Converting between string types and
dealing with the lack of scoping in records have been two major pinch points
for me with Haskell so far.

Most puzzling part: The description of Erlang as an imperative language.

~~~
dllthomas
I had a reading group going through this, top to bottom. The chance to stop
and discuss things was a big win.

------
DonbunEf7
Two things missing that I wish I knew when I had learned Haskell.

First, Haskell is just another programming language. It has many papers
written about it, and many people have strong opinions about it, but at the
end of the day it is not _that_ special.

Second, the Haskell community is _not_ friendly and welcoming to many groups
of folks. In particular, if you are a fan of dynamic/gradual typing, objects,
distributed systems, etc. do not expect a warm welcome.

A personal anecdote: I left #haskell on Freenode because a regular and popular
user proposed and endorsed an extended analogy wherein all humans are divided
into "dynamically-typed" and "statically-typed" people, and statically-typed
people are superior because they are more reliable. This kind of bias pervades
the community and ruins any kind of cross-ecosystem collaborative efforts.

Edit: Was I being confrontational? I wasn't even part of this conversation! I
was lurking, and I saw this ridiculous thing play out unprompted between
regulars.

~~~
platz
Conversely, if I am a fan of static typing and compile time constraints,
should I expect a warm welcome pushing those ideas in Clojure and Ruby
communities?

One should not be surprised that actively rejecting/attacking the core values
of a community brings ire. Are you sure you weren't the one being
confrontational?

~~~
shakna
Clojure has the core.typed [0] optional type system! So yes, though they are
dynamic, they embrace that others can differ.

> This work adds static type checking (and some of its benefits) to Clojure, a
> dynamically typed language, while still preserving idioms that characterise
> the language. It allows static and dynamically typed code to be mixed so the
> programmer can use whichever is more appropriate.

Some communities don't hold the dynamic vs static debate as an issue of such a
hard regard that an individual must be rejected, lest they infect others.

matz has pretty much said that static type checking will not be part of Ruby,
and he won't open up the syntax for it. But bugs like this one [1] aren't
filled with hate, telling people to get lost. There's a constructive approach.

[0]
[https://github.com/clojure/core.typed/wiki](https://github.com/clojure/core.typed/wiki)

[1] [https://bugs.ruby-lang.org/issues/9999](https://bugs.ruby-
lang.org/issues/9999)

~~~
platz
I am aware of those extensions. There is a difference between some
features/extensions and core principles. If you want to play that game,
Haskell supports ways to "add on" more dynamic behavior as well. One way is
via -fdefer-type-errors [1] which allows parts of the program which do not
typecheck to not impede the rest of the program.

But this is missing the point of core values. I will refrain from listing all
the digs that Rich Hickey has taken at static types and their ilk, but he has
done so quite a lot.. My point is both sides don't like their core values
rejected. I thought this thread is about community and not extensions so much.

> bugs like this one aren't filled with hate, telling people to get lost.
> There's a constructive approach.

And there are many examples of haskell folks treating others with a
constructive approach too on various topics outside of the "cannon". I'm not
sure what you're implying here, or are if you're referring to a specific case
(however, tallying up some cherry-picked anecdotes may not be so useful)

[1]
[https://downloads.haskell.org/~ghc/latest/docs/html/users_gu...](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#deferring-
type-errors-to-runtime)

~~~
shakna
> I am aware of those extensions. There is a difference between some
> features/extensions and core principles.

Referring to a core library as an extension that isn't in line with core
principles just sounds... Wrong.

> I thought this thread is about community and not extensions so much.

For something to be taken by the community, and willingly added to the core
library, suggests a level of embracement within the community. Hickey himself
weighed in on typed [0], embracing it with praise, despite the fact it may go
against his personal values, he doesn't see it going against Clojure's values.

Static typing simply isn't a core value for Clojure. Thus:

> Conversely, if I am a fan of static typing and compile time constraints,
> should I expect a warm welcome pushing those ideas in Clojure and Ruby
> communities?

Absolutely.

> And there are many examples of haskell folks treating others with a
> constructive approach too on various topics outside of the "cannon". I'm not
> sure what you're implying here, or are if you're referring to a specific
> case (however, tallying up some cherry-picked anecdotes may not be so
> useful)

I agree, anecdotes here may be entirely unhelpful. Yet, I know I am not alone
in saying that some of the haskell community is warm and embracing of
newcomers, and yet there are also those that clearly reject newcomers,
instructing them instead to learn mathematical concepts or the right words for
the right concepts, and not guiding them to do so.

[0] [https://groups.google.com/forum/#!msg/clojure-
dev/ryYzI1Bj0p...](https://groups.google.com/forum/#!msg/clojure-
dev/ryYzI1Bj0p0/uWdEwO9T6xAJ)

~~~
platz
I did not say core.typed wasn't accepted by the Clojure community. It's great
you have many examples of Clojurians extolling core.typed.

I said rejecting "core values", outright, would be met with resistance. Since
Optional Typing via core.typed _is_ a "core value" as you claim, there is no
conflict. I want to be clear about what I'm claiming here.

> > Conversely, if I am a fan of static typing and compile time constraints,
> should I expect a warm welcome pushing those ideas in Clojure and Ruby
> communities?

> Absolutely.

Well, I think you're being disingenuous. After saying "Static typing simply
isn't a core value for Clojure". If I claim in the Clojurians slack the value
of what we agree is not a core value for Clojure, namely, ahead-of-
time/compile-time static typing, yes, I think that would be met with some
resistance.

Also, I hope you're not thinking that in this thread I have some problem with
Clojure. I'm talking about sociology, not technology.

------
unhammer
This is such a great reference. The best part is that it's continually
updated:
[https://github.com/sdiehl/wiwinwlh/commits/master](https://github.com/sdiehl/wiwinwlh/commits/master)

~~~
sid-kap
Whoa, didn't know he was still updating it! Last year he announced that he was
done working on it:
[http://www.stephendiehl.com/posts/docs.html](http://www.stephendiehl.com/posts/docs.html)

------
tux1968
Good advice about how to grok monads. An oldish but still useful video takes a
similar concrete approach to building up the idea from simple examples:

[https://www.youtube.com/watch?v=w_KY2I34-f8](https://www.youtube.com/watch?v=w_KY2I34-f8)

------
hota_mazi
Whenever I tried to use cabal, I always came up realizing how lucky we are on
the JVM with Maven and Gradle.

It's mystifying the Haskell community still hasn't been able to come up with a
decent dependency management + build tool.

~~~
IngoBlechschmid
There are a couple of peculiarities of Haskell's module system which made it
difficult, but yes, I agree that it took longer than it should have.

However, nowadays there is a decent dependency management and build tool! It's
called "stack", as in "stack install xmonad". I never once had any dependency
or other compile problems with stack. It simply always works. :-)

~~~
andolanra
I've had a lot of problems with Stack whenever I'm doing non-trivial (that is,
beyond just "build this executable the standard way") kinds of tasks—in
particular, it tends to corrupt its package DB after a while for mysterious
reasons, and you have to blow it away and rebuild, and it can be a _nightmare_
to do certain bits of configuration where the UI is undocumented or
nonexistant—but it's a pretty big step up from historical Cabal.

There's also an already-working-but-still-not-quite-finished alternative
system within Cabal which is eventually gonna become the default one, and
which does builds in a Nix-inspired way. I've been using that for the better
part of a year now, and I like it far better than either historical Cabal or
Stack: [http://blog.ezyang.com/2016/05/announcing-cabal-new-build-
ni...](http://blog.ezyang.com/2016/05/announcing-cabal-new-build-nix-style-
local-builds/)

~~~
dllthomas
> it tends to corrupt its package DB after a while for mysterious reasons, and
> you have to blow it away and rebuild

Odd, I've been using stack in anger for a while now and have never had that
happen. Have you reported a bug? Any ideas about reproduction?

~~~
andolanra
I didn't ever figure out a minimal reproduction, but I also should be clear
that that was my experience using Stack at the time: I haven't used it in more
than a year (I jumped ship to new-build as soon as it was first available and
haven't looked back) so those problems might have been alleviated since then.

