
What I Wish I Knew When Learning Haskell 2.0 - tenslisi
http://dev.stephendiehl.com/hask/#cabal
======
gtani
One thing that helps alot is the various undergrad course syllabuses that have
been given with emphasis on type systems and aspects of FP, immutability,
segregating and strictly marking side effects etc.

[http://shuklan.com/haskell/](http://shuklan.com/haskell/)

[http://www.cs.tufts.edu/~kfisher/teaching.html](http://www.cs.tufts.edu/~kfisher/teaching.html)

[https://www.inf.ed.ac.uk/teaching/courses/inf1/fp/](https://www.inf.ed.ac.uk/teaching/courses/inf1/fp/)
(P Wadler)

[http://www.cs.princeton.edu/~dpw/cos441-11/schedule.htm](http://www.cs.princeton.edu/~dpw/cos441-11/schedule.htm)

[http://blog.davidterei.com/2011/10/stanford-haskell-
course.h...](http://blog.davidterei.com/2011/10/stanford-haskell-course.html)

[http://www.seas.upenn.edu/~cis194/](http://www.seas.upenn.edu/~cis194/)

________________

also the Apress "Beginning Haskell" looks pretty good, tho the writing isn't
perfectly clear. The example topics and sample code look good, and that's what
mostly counts.

[http://www.amazon.com/Beginning-Haskell-A-Project-Based-
Appr...](http://www.amazon.com/Beginning-Haskell-A-Project-Based-
Approach/dp/1430262508)

The books by Hutton and Simon Thompson ("Craft of FP" 3rd ed)are good intros
as well. Haskell school of music is really good, but not sure for people who
aren't versed in music topics (harmony/theory, composition, MIDI, DSP.

[http://www.amazon.com/Programming-Haskell-Graham-
Hutton/dp/0...](http://www.amazon.com/Programming-Haskell-Graham-
Hutton/dp/0521692695)

[http://haskell.cs.yale.edu/euterpea/haskell-school-of-
music/](http://haskell.cs.yale.edu/euterpea/haskell-school-of-music/)

~~~
coolsunglasses
I want to highlight this particular course:
[http://www.seas.upenn.edu/~cis194/](http://www.seas.upenn.edu/~cis194/)

It's _REALLY_ good and can be gone through quickly while still getting a feel
for the "point" of Haskell.

------
thinkpad20
I think it's kind of amusing that right after sternly warning the reader to
avoid monad tutorials, he then proceeds to write a monad tutorial. I guess you
just can't resist...

~~~
gamegoblin
After I finally understood monads I thought about writing a tutorial. My
thought process was "Well I understand it now, why couldn't someone have just
_explained it this way_ ". Then I reevaluated and realized everyone has those
thoughts. It's just a hard concept to grasp on the first try. One really just
has to grind away and force themselves to use monads for a long enough time to
really grok them.

~~~
username223
I wouldn't call monads "hard to grasp" so much as "hard to explain" or "easy
to obfuscate." That's what the "mumble mumble endofunctors" joke is getting
at: sometimes they're a useful generalization, but more often they're a way to
make easy things sound hard, or to make bad teachers sound smart.

~~~
kazagistar
I agree that they often make things seem harder then they really are. The
monad tutorial that works best for me is the "don't mention monads" tutorial.
Thats the one where you just show some specific task to complete, like
composing (a -> Maybe b) functions, and show that there is a neat operator
that does it. Then, at some future time, show another composition task, like
composing (a -> [b]) functions, and show the same operator again.

Starting with the abstract just messes people up and gets them confused. You
don't start throwing around Kleisli Arrows and endofunctors right off the bat.

------
tenslisi
There's also a very detailed tutorial on writing a toy compiler with Haskell
and LLVM on this site:

[http://www.stephendiehl.com/llvm/](http://www.stephendiehl.com/llvm/)

------
nilkn
On a small monitor (11" MBA), not all the topics in the list are visible and
the list does not seem to be scrollable.

------
fiatjaf
Somehow related: For those who (like me) were searching for a long time for a
quick and complete Haskell tutorial (but were left with very introductory
guides for non-programmers like Learn You a Haskell for the Great Good), look
at this tutorial:

[https://www.fpcomplete.com/school/to-infinity-and-
beyond/pic...](https://www.fpcomplete.com/school/to-infinity-and-beyond/pick-
of-the-week/haskell-fast-hard) Haskell Fast & Hard.

~~~
platz
I reccomend LYAH even to programmers, there are enough things in the language
that it makes sense to go slow at first.

I think beginners get lost because they try to go too fast at first and get
impatient.

For example, see below about the guy who tried to do GPU programming early on
and got frustrated.

~~~
fiatjaf
Maybe you're right. I'll never know because I've read LYAH almost entirely
before getting to HF&H.

------
Kiro
I thought this was supposed to be a list of things to learn _before_ learning
Haskell but most of these are things you obviously have no idea what they are
if you don't know at least a little Haskell.

------
platz
Note that these are intermediate level Haskell topics, as intro describes.

------
kyllo
This was very timely and interesting to me as I just started learning Haskell.
Thanks!

------
leccine
The main force holding me back from learning Haskell is the cryptic syntax. I
totally understand that the type system is (supposed to be) superior to other
languages but it simply make it really hard to find the time. I am also unsure
how useful this language can be in every day use. There are so many great
languages out there nowadays, Clojure, Go, Erlang. It is easy to cover the
spectrum with these and I don't see where Haskell would be a better fit. maybe
somebody could shed some light on the strengths of this ecosystem.

~~~
thinkpad20
As to Haskell's syntax, I think it's really just as complicated as it needs to
be to express the ideas Haskell embodies succinctly and precisely. It doesn't
have any _more_ syntax than most other languages; it's just a very _different_
syntax than most non-functional languages. And this is precisely because the
_semantics_ of the language are also very different. Haskell, for example, is
not block-structured, as nearly all imperative languages are. (It does
simulate this with do-syntax, but this is only a simulation). I understand
though - I find Clojure practically unreadable, and this has kept me away from
it to a degree.

As to where Haskell fits: you're correct, there are many other great languages
out there. But I think Haskell is really unique in offering what it does.
Clojure, Go, and Erlang are all great in their own regard, but none of them
provides the degree of safety that Haskell does. For example, none of them
enforce purity, and all three of them freely allow the use of `null` values
(which is really quite surprising considering how many problems nulls cause).
Clojure and Erlang avoid mutable state like Haskell does (though not to the
same degree of rigor) but don't provide the elegant solutions for simulating
mutable state that Haskell does with its monads, which _almost_ allow you to
"have your cake and eat it too" with state. None of them encourage the degree
of abstraction that you'll find in Haskell. Also, at least according to the
Computer Benchmark game, Haskell beats all three of them in terms of speed, as
well. Haskell's "place" is in generating highly robust code with good
performance, and also works as a beautiful language for expressing certain
mathematical concepts.

This doesn't make Haskell a perfect language, but it absolutely has a lot to
offer that other languages don't. And it's so much _different_ than other
languages, that at the very least it can change your perspective on a lot of
things.

~~~
platz
I think one has to be careful about performance claims.

Of course you _can_ tweak things to be fast in hakell, but to be able to
actually program haskell in such a way to, beat other languages in
performance, is not a trivial skill.

There are numerous stackoverflow and r/haskell posts "Why is my haskell code
10x times slower than language X?" Or observe this set of web framework
benchmarks:
[http://www.techempower.com/benchmarks/](http://www.techempower.com/benchmarks/)

~~~
chongli
_Of course you can tweak things to be fast in hakell, but to be able to
actually program haskell in such a way to, beat other languages in
performance, is not a trivial skill._

It actually is trivial in a lot of cases. It's often as simple as swapping out
lists for vectors and inserting a few strictness annotations into your types.

~~~
danieldk
...and using the ST monad. In the end it pretty much ends up looking like an
imperative program.

The good news is that it stops at the function boundaries. Your quicksort may
be implemented in the ST monad, looking like some bastard child of C, but the
function type ends up being

    
    
      qsort :: Ord a => Vector a -> Vector a
    

And that's one of the likeable properties of Haskell: it doesn't deny that
real-world programs sometimes require mutability, but allow you to isolate it
through the type system. So, even though _qsort_ may use mutable memory for
sorting, it is a pure and referentially transparent function.

------
jonnybgood
Haskell's a good language, but I would add to this list the use cases as to
where Haskell is the right tool for the job. I think this would help a lot
beginners get a better grasp of Haskell.

For example, I wouldn't tell someone to write a web server backend in Haskell
if it's going to be in production. Sure, you can do it, but there are more
adequate tools for the job. On the other hand, if you were looking to create a
DSL or write a parser, Haskell would be great. This is how Galois and Facebook
are taking advantage of Haskell.

~~~
codygman
Why wouldn't you write a web server backend in Haskell? What is more adequate
than Haskell for web server backends and why?

You give no support to the claim that "There are more adequate tools than
Haskell for writing web server backends".

~~~
jonnybgood
The JVM, for one. The JVM far exceeds Haskell in this regard. Superior
libraries and equal if not better performance. I didn't say you couldn't, but
for production purposes if I had to choose.

~~~
codygman
Define superior. Making such bold claims without any proof/examples is very
poor form.

~~~
danieldk
Superior is indeed difficult to define. I think most Haskell libraries define
far more elegant abstractions than their Java counterparts.

However, as a user of both Haskell and the JVM, there are some things to be
said for the Java library ecosystem. For instance, the most widely-used Java
libraries are often more mature, maintained better (usually because its
authors are paid to do so), and more API-stable (for most of my Haskell code,
a dependency version bump usually implies updating my own code). Of course,
this is all reasonable, since the Haskell ecosystem exploded far more recently
than Java's. The older Haskell pages (bytestring, text, vector) tend to be
very stable and predictable.

Another aspect where the JVM is currently ahead is VM monitoring. E.g. if
there is a bottleneck, I can easily attach Visual VM or even my IDE to a
running Tomcat and peek around. The JVM can do code hotswap (even more
effectively with JRebel and LiveRebel).

Note: I posted this to provide some balance to the discussion. I believe
Haskell is superior in many other respects, such as the type system, REPL-
driven development, web frameworks with type-safe URLSs, etc.

