What I Wish I Knew When Learning Haskell

http://dev.stephendiehl.com/hask/

by andars • 11 years ago

202 60 11 years ago

dev.stephendiehl.com

greenyoda• 11 years ago

Readers may be interested in the extensive comments from when this article was posted in previous years:

https://new-hn.algolia.com/?experimental&sort=byDate&prefix&...

agumonkey2• 11 years ago

Digression, nice 'experimental' flag.

jack9• 11 years ago

So before learning Haskell, you wished you had already known over 325 pages of what? That seems like a motivation to not try to learn it at all.

BadassFractal2• 11 years ago

In Haskell you can get most work done without the advanced concepts, but you can always choose to dig into the meaty stuff and get even more leverage from the type system. Easy to start, hard to master, keeps things very interesting for a a very long time. By the time you think you've mastered most of what it has to offer, the next version of GHC comes out with new goodies, now you can learn even more superpowers.

Btw, the title says "when", not "before", big difference.

zenocon• 11 years ago

I find articles like this pretty useful and always bookmark them. They are useful for me when I've already invested the time to learn the rudimentary basics of a language; after that, each of these tips usually provides an 'a-ha' moment and saves me from learning something the hard way...but I wouldn't start reading this before getting yourself to at least an elementary understanding of the material.

coolsunglasses8• 11 years ago

This isn't a beginner resource, Stephen himself has said that. It's a great post-learning-the-basics supplemental.

Gabriel4392• 11 years ago

The title should really be "Stuff that I wish I had quick reference material for when learning Haskell". You might need a few of those sections for specific application areas (and that's how they are organized), but you can safely ignore the rest.

danellis2• 11 years ago

Is he kidding with that title-text-as-an-image? I was going to C&P it into an IM, but nope.

iso8859-1• 11 years ago

Used to be very common when you wanted a fancy font and had no way to bring it to the user. No joke, just old-fashioned.

danellis2• 11 years ago

It might be an old fashioned thing to do, but that web site is not old fashioned. It actually uses web fonts.

theophrastus• 11 years ago

syntax. of the dozen languages i've taught myself, (which is a super-set of the half dozen i've used to write significant things), Haskell's syntax has been, and remains, the largest barrier for me (and this includes perl!). For example, just a clear equivalence, like this one given by the very helpful linked article here, would've helped enormously ("sugared form" for monad):

    do { a <- f ; m } ≡ f >>= \a -> do { m }

Sometimes i think the authors of Haskell had a completely different glyph set. I'm sure some of you folks can read this like a book, but this sort of thing still throws me into the ditch:

    M2 :: (Monad m) => (a1 -> a2 -> r) -> m a1 -> m a2 -> m r

BadassFractal2• 11 years ago

It takes a while to master reading math notation or music notation. Mastering reading Haskell isn't that different. Some people are served well enough by just learning guitar tabs, others feel they're better off mastering music notation.

skimpycompiler2• 11 years ago

This is not true, unlike C++, Haskell's syntax is enormously clean and easy to parse.

It's in no way comparable to learning math notation or music notation.

iheartmemcache• 11 years ago

APL/J/K is way more "operator soup-y" than Haskell, but there are pages like this http://www.jsoftware.com/jwiki/action/show/Vocabulary/AET?ac... that for the newbie followed by http://www.jsoftware.com/jwiki/NuVoc. Someone needs to make Typeclassopedia for operator soup.

For the record, I can read both standard notation music and guitar tabs. I'm fairly competent at Haskell have written APL/J/K derivative languages for a living. "Mastering reading Haskell" certainly has to do with a lack of "go to this page on the wiki/hoogle/haddock and you can read the meaning and idiomatic usage of the 95% most common operators", not a lack of conceptual grasp of anything difficult.

coolsunglasses8• 11 years ago

This is my favorite post on desugaring Haskell syntax: http://www.haskellforall.com/2014/10/how-to-desugar-haskell-...

evincarofautumn3• 11 years ago

Well, just for the sake of discussion, would you prefer something like this?

    def M2<T1, T2, Result, Action : Monad>(
      f: (T1, T2) => Result,
      a: Action<T1>,
      b: Action<T2>): Action<Result>
    {
      …
    }

The Haskell notation is a simple, concise representation of the actual semantics. If you try to transpose those semantics to a more conventional notation intended for different semantics, it gets complicated due to the mismatch.

This notation I’ve suggested doesn’t even accurately express such details as currying and typeclasses, which the original notation conveys neatly.

pekk• 11 years ago

Just for the sake of discussion, what is actually wrong with the syntax you just invented?

eximius• 11 years ago

Aw, the Rust people will be either happy or sad about this.

dragonwriter• 11 years ago

Sometimes i think the authors of Haskell had a completely different glyph set.

Well, its an ML-derived syntax rather than the more common Algol-derived syntax, which forms something of a familiarity obstacle for programmers whose background is largely in Algol-derived syntaxes.

Its probably somewhat easier if you've learned another ML family language first -- especially given that idiomatic Haskell often involves wrapping your head around semantics that are unfamiliar as well, so that you aren't trying to take on both at once.

OTOH, I think the kind of ML-based syntax Haskell uses is a good fit, and its worth learning.

yawaramin• 11 years ago

It's funny you should ask this, because you're right that some types really are quite hard to read and there was a great discussion a few days ago where someone mentioned that the types tell you a lot about what the function is doing, and then someone retorted that most examples of types guiding you are usually very simple, and posted a really complex type for people to decipher, and the more proficient Haskellers actually worked it out--based partly on their previous knowledge of similar types! See http://www.reddit.com/r/haskell/comments/3ijtej/any_tips_for...

Now, I'm not at that level of proficiency, but I can tell that your example above takes a binary function and 'lifts' it into a higher (monadic) context, so that it can work on monadic values. And the reason I can work this out is because I know about the Functor typeclass which has the function fmap :: (a -> b) -> f a -> f b, which does a similar job of lifting an input function into a higher context (in this case a functor context).

spopejoy• 11 years ago

But ... but ... Haskell has the least syntax of any "mainstream" language (save LISP, without macros).

Your example of course is `do` notation which is tricky, and is really kind of advanced -- it's much better to use `>>=` `>>` and `return` as long as you can stand before breaking out `do`. If nothing else avoiding `do` will make you write smaller functions!

By "syntax" of course I mean "keywords". Haskell allows for infix operator creativity which you might see as a drawback. I would rather have a language be maximally expressive, allow me to define my own infix swear-word "operators", than be coddled and censored like almost every other language outside C++. But as for built-in syntax, there's hardly any. `$` and `.` are freaking library functions.

As for types, well, types are hard to read. Why shouldn't they be? It's not like templates are easy in C++ once you leave the most trivial exercises. At least Haskell's are formally consistent and fundamentally related to your definitions -- unlike templates which are really macro soup.

In any case, I would find your `M2` definition a lot easier to read with `a` and `b` instead of `a1` and `a2` ...

skimpycompiler2• 11 years ago

What I still do not know and always wished to know when I learned Haskell was how to write efficient code easily. I wrote huge projects with thousands of lines knowing nothing about C++ execution model and had insanely fast code (that could have been made even faster - but I was not that kind of expert) but with Haskell I have to be an expert to really write code that is as performant as something that would take me much less time to write in C/C++.

Just writing simple efficient matrix multiplication is a pain. It took me a couple of days to write a working quicksort.

I couldn't find any resources that provide a very serious introduction to optimizing Haskell code.

I found out way too late in my adventures with Haskell that Monad Transformers and similar abstractions have a significant runtime overhead and aren't free, I thought I was just playing with types that won't get in the way when the code compiles.

No one seems to cover this aspect of Haskell.

coolsunglasses8• 11 years ago

Don't do something that generates thunks in a long-running loop which'll hold references to them. (This applies to JS...virtually any language with GC and first-class functions as well). This is pretty easy to fix and identify once you know what you're doing.

Don't use String. Use Text for Text, ByteString for raw bytes.

Related to String: don't use lists for large datasets unless you're intentionally modeling and reasoning about your data as an infinite space. Use Vector if it's finite, fits in memory, and you're going to comprehend it all at once. Vector gives you cache-friendliness as well.

As a safe default: lazy in the spine, strict in the leaves.

Use streaming libraries (Pipes, Conduit) for processing large datasets. I did a test with a csv parsing library and compared the non-streaming (default) interface and the streaming interface provided by pipes-csv for summing columns in a ~6mb CSV.

No streaming used 30mb of heap.

Naive streaming used 10mb.

Pipes used 600kb.

monad-control and mtl (monad transformer libraries) are pretty fast and can be used without much (any?) worry in 99.999% of circumstances.

Use attoparsec and be mindful of backtracking anytime you're doing perf sensitive parsing. If you hit a limit, you may need to use a parser generator but this is almost never the case. If you need to parse something huge...use a streaming parser.

Sometimes CPS transformation can be a huge boon. Read what Bryan O'Sullivan was written about this for the parsing side of it. Kmett has good examples of CPS transformation for performance in his libraries as well.

Use async.

Default to using TVars (STM containers) for correctness until you know what specific properties you need. If you get perf sensitive but still want transactions, turn the scope of your transactions into cells of a data structure. Cf. http://hackage.haskell.org/package/stm-containers when you have composable concurrency abstractions, it can become just yet another data structures problem.

If you're writing a (very) hot loop, you'll probably end up looking to avoid boxing (just like Java) and touching the heap (just like Java, C, C++). Don Stewart has written good, thorough examples of this.

Resources:

Anything Don Stewart has ever written

Kmett's libraries and blog

Bryan O'Sullivan's libraries (particularly attoparsec and aeson) and blog

Johan Tibell is the strictness perf honcho. Check his libraries for ideas if you're making something strict. Don Stewart has written along these lines too.

http://book.realworldhaskell.org/ is out of date but the stuff on perf and debugging are some of the best in the book.

My own book http://haskellbook.com/ will explain how to reason about performance and laziness, though it's primarily a practical beginner's book. Focus WRT perf will be more on understanding the foundations, how things evaluate, how the runtime works so you can absorb all the other information as easily as possible.

Koalafications:

Every backend I work on in ad tech, including the public facing adserver, is written in Haskell. Our adserver latencies range 12-17ms with some pretty gentle 99th percentiles. The average DSP we talk to has response times in the low hundreds (100-400).

agumonkey2• 11 years ago

How out of date is RWH ?

imakesnowflakes• 11 years ago

Apologies, if this is a bit off topic.

I am a freelance computer programmer from India. I have been teaching Haskell myself for the past 3-4 months. I have stopped for a while, because I am hard pressed to find a job where I can work remotely. Can you look at some code I have written and let me know if I can put Haskell as something I can put in my resume? If yes, what is the best way to put it.

Here is the code.

1. A simple neural network with back propogation algorithm that recognizes alphabets letters on a 8x8 grid.

https://bitbucket.org/sras/haskell-stuff/src/default/snn.hs?...

2. A port (partial) of my side project web application in PHP/MySQL to Haskell using Spock framework.

https://bitbucket.org/sras/babloos-hs/src/06bffa288865af1fc3...

What are my chances of getting a remote Haskell job? Based on my experience, What kind of position/pay can I expect to get? If it matters, I have 9 years of professional experience in developing web applications.

j42• 11 years ago

Hey, thank you for this!

Bought your book a while ago -- didn't realize your background was in ad tech. I personally eeked out ~30ms avg latencies with PHP by modifying ReactPHP (non-blocking event loop) and getting creative with Redis and nginx.

It's performing comparably at high loads, and saving us a ton of money but obviously... it's PHP. I'm obsessed with Haskell and have spent a bit of time playing around with HLearn as I think SVM is an obvious use case where it would excel (though in terseness/structure more than performance relative to C).

Any advice on selling a rewrite and/or challenges as one nears 1B daily queries for which Haskell would be uniquely advantageous?

I want to integrate Haskell in our high-frequency serving arm (or as a backup, for machine learning), but honestly don't know enough about it relative to performance to sell its advantages over Erlang, Go or even C. Aside from the obvious "functional is better" and "types are great," which tend to appeal to the folks who see beauty in the language, is it feasible to claim that Haskell will result in a faster, more performance program in less time? ... And not to wear out my welcome, but I'm interested in reading more about performant Haskell (as per your post); any resources you recommend?

MyRealName• 11 years ago

there's an adtech haskell shop?

Kenji• 11 years ago

My desire to be productive is at odds with my appreciation for Haskell. Don't get me wrong, I love the language, it's elegant, absolutely awesome (apart from whitespaces with semantic meaning). But sometimes I feel like the language, despite its expressiveness, is like a tight straitjacket. And then I just write some JavaScript or Java or C++ or PHP and feel so much freer.

coolsunglasses8• 11 years ago

That's down to comfort, yes. Haskell lets me work faster because I'm over the "hump". Just a question of investment.

Gabriel4392• 11 years ago

I like to think of Haskell's types as traffic lights. They might get in the way if you're the only driver on the road but the moment you have to deal with other people they are a life saver.

That's why people favor Haskell in enterprise environments because types keep everything sane when you have multiple people working on the same project or you have large third-party dependency trees.

chrisra• 11 years ago

"All of Haskell"

harry8• 11 years ago

pandoc, shellcheck and xmonad. is this still the list of things you can install that were written in haskell that are used for something that isn't writing haskell code?

zeckalpha• 11 years ago

Stuff you can install: Hakyll, Gitit, Git-annex, Propellor, Pugs.

Haskell is an enterprise language, not an application language. The benefits of Haskell have played out better there.

kryptiskt• 11 years ago

You can install Yesod, Snap or Spock and make a website.

Check out Servant while you're at it, it's awesome.

If you don't like writing the client-end in Javascript, you can use Haste or GHCJS and do it in Haskell.

WAI already supports HTTP/2.0 (before Apache has got around to it).

danidiaz• 11 years ago

shake, an alternative to make.

smichael• 11 years ago

hledger, an accounting tool. shelltestrunner, a command tester. rss2irc, a feed-announcing IRC bot. Nikki and the Robots, a game.

mijoharas2• 11 years ago

What I wish I knew now that I know Haskell: Where I can find Haskell jobs that aren't in banking! I have grown a love of the language through using it, but I don't know how to find many job positions that aren't either in banking or research.

scroy• 11 years ago

Why is it popular in banking?

mijoharas2• 11 years ago

My understanding is that it's the expressiveness and the type safety along with being functional and immutable (by default) in order to ensure correct programs are being written (which is obviously a concern when lots of money is moving about.)

mark_l_watson• 11 years ago

The author covers cabal sandbox, which I used until recently when I converted my few Haskell projects to use stack. I was really happy with stack until a few days ago when I tried to add some old Haskell code to a new yesod web app. Dependency hell that took a while to sort out.

This article discussed getting everything working and then doing a cabal freeze which is something I hadn't seen before. I would like to be able to simply update a project to new library versions but maybe I should drop that desire. Any advice?

jumpwah• 11 years ago

I'm not sure cabal can really be considered a package manager as the article here states [1]. Stack helps, but I think just using a dedicated package manager to manage haskell things is probably the way to go.

Nix has a lot of haskell packages in it already, and guix has a hackage 'import' tool which helps you with writing a new package definition for a project that hasn't already been packaged.

You may think that's overkill, and fair enough. But I've been through cabal hell before, and I'd honestly rather not anymore, ever.

[1] https://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after...

erik14th• 11 years ago

Would add stackage[0] as first item if it was my list.

[0]https://www.stackage.org/

okasaki• 11 years ago

I wish I hadn't bothered learning Haskell. I spent years thinking I was an idiot because I struggled and failed to make any even moderately complex programs. Now I'm using C++ and things are so much easier. I think leaving Haskell feels like leaving an abusive partner who always puts you down.

What I Wish I Knew When Learning Haskell

Related Stories