In my first year of engineering school (basically last year of undergraduate school in France), I became a fixture of the computer programming club. It was a weird nerd den, but there was always something to learn there. And not too late after I started skipping classes, a friend there talked to me about Haskell. I don't remember how much I understood of the advantages and issues of pure functional programming; but I remember I liked the language, its elegance, and also its deepness of abstraction. The math kid in me liked a programming language where each new idea required a paper to express.

Flash-forward five years, and I am not a master of Haskell. I know many of the concepts at a shallow level and I toyed with it a bit, sure. Being in a formal methods research team also ensured that I learned many ideas inherent to functional programming and the like. But for Haskell itself, I never really plunged into its deepness. Never found the time.

Until today. Or a few weeks ago, to be more precise. Because as part of my reorientation to AI safety research, I now have an incentive to learn more of Haskell: MIRI wants Haskell programmers. Even if that's not exactly the job I'm aiming at, Buck Schlegeris, one of the recruiters at MIRI, confirmed in a call that it was one of the criteria MIRI used for hiring. And since I wanted to dig deeper into it for years now, that's an awesome excuse.

Which brings me to the point of this post: explaining what I'm going to do in this sequence. My goal is to learn the deep parts of Haskell, in as much detail as I need to be a good Haskell programmer. This means I want to eventually be able to:

  • Write and read idiomatic Haskell code
  • Optimize Haskell code
  • Understand basically any Haskell code

Ideally, I would write a tutorial on every thing I study. But I want to learn fast, and writing tutorials is extremely time consuming. So I will instead post write-up of my explorations of a topic. These will generally include explanations, though without the promise of a complete narrative. Also, I will assume in the reader a general knowledge of functional programming, just not of Haskell specifics.

Finally, what will I study? Inspired by the following two study plans, I have this list for starters:

  • Common Typeclasses, like Functor and Monad
  • Concurrency
  • Laziness
  • Functional Data Structures (a la Okasaki)
  • Optimization of functional programs (a la Bird)
  • Principal GHC extensions
  • Inner Workings of GHC

This is in no particular order, although I did begin with studying Typeclasses. Feel free to propose other topics you deem important in the comments.

With that out of the ways, let's start the trip through the Haskell jungle in the first real post, on the Functor typeclass

New Comment
2 comments, sorted by Click to highlight new comments since:

I find type level programming (e.g. type families, higher kinded types) to be fairly important. For example, ghc is implemented using a technique called "trees that grow" that allows you to make slight modifications to a data structure in different places that it's used. Instead of "in this part of the codebase, we assume that the Maybe Frobnicator field has been populated with a Just", you can have "in this part of codebase, that field just has plain old type Frobnicator".

Thanks a lot for the recommendation! I'll look into it.