Thread by @trupill

Here is my take on teaching #Haskell and what should we do better. Please engage in helpful criticism and discussion 😀

So, thread below 👇

For me, "functional style" requires of these three things:
- focus on immutability and separation of side-effects,
- higher-order functions,
- data types with support for sums/choices.
Everything but the last point is available in many mainstreams languages *now*.

We should acknowledge that the whole concept of higher-kinded abstractions (functor, applicative, monads) is not *easy*.

In my experience, "length applies to any list, whatever the type of the contents" (in other words, length :: [a] -> Int) seems intuitive to most people.

On the other hand, abstracting on the type of container/context/computation is harder to grasp. What does "liftA2 (+) :: Applicative f => f Int -> f Int -> f Int" do?

My take on this is that we should take time to teach each of the main instances of each concept (for lists, optionals, readers...) and what how each abstraction concretizes.

For example, I like to say that "do" notation:
- is black magic when using IO,
- chains validations when used with optionals,
- gives several results back when used with lists,
- threads a value with used with reader,
- ...

For me, this is information I explicitly state, not something that I expect people to understand at first sight. My goal is that they can start using the tools of the language on each concrete case, and they develop their (own) intuition from there.

We should be careful when leading people to complicated ideas too soon:
- records are terrible and boring, but "lens" is quite hard to use;
- GADTs are cool, but at first we can just validate input as anywhere else;
- LambdaCase rocks, but \x -> case x of is not that bad;
- ...

We often forget about teaching IO well!

My favorite exercise for students is to write a small concurrent TCP server using "network-simple", so they learn about IO and STM.

Very often, our teaching material reads as academic material (since very often it's the only one we have!). But do I really need to understand the implementation of van Laarhoven lenses to use "microlens"? No, and I should not.

Going back to my first point, we should make clear that if you can:
- define your own sum types,
- use map, folds, and other higher-order functions well,
- use "fmap" and "do notation" for a bunch of concrete examples,
you are more than prepared to write good #Haskell!