Haskell for a New Decade [pdf]

I think the difficulty of Haskell is overrated. It's just different. The crowd who complain about Haskell being hard despite x years experience are the same people who speak English and think Mandarin is hard.

And yet 1.7+ billion people speak Mandarin, and most linguists agree that English is actually the harder language owing to its more branched roots.

Haskell is what happens when you go full lambda calculus, and the dedication to referential transparency really forces you down some interesting paths/abstractions. It's also worth noting that other functional languages like OCaml and lisp do not force purity so the idioms are not as extreme.

The impedance mismatch essentially boils down to Turing Machine vs Lambda Calculus and as such you don't find many familiar friends when switching camp (to begin with, at least!) The Haskell idioms are very different and the consequences of referential transparency ripple throughout the way you need to think about computation.

It's also worth noting that Haskell is a language laid bare - much of the features and abstractions are plain-old functions which means you can "just" duck into them, implement them for yourself or read them as libraries. But what we often forget is all the abstractions we needed to learn when grokking "programming" (which was probably imperative style programming) the first time round. Most people have moved on from the time when trying to conceptualise what an object is or how methods work or even working with mutable state. When you get to design patterns - some of the implementations are quite complex the first time round. Eg the visitor pattern/double dispatch is not particularly simple when you sit down and manually expand the execution of those calls and yet when you use it, it's quite simple.

When we program with objects, most of us don't stop to think about vtables anymore* we just use the object to solve our immediate problem.

The more I see of Haskell, the more confident I am that it just uses a very different set of abstractions that you can just use and forget about except you get the benefit of a HM type system and referentially transparent code. It's also nice that that itself somewhat forces you towards a more functional-core imperative style architecture where your business logic is pure and mostly happy path code and your boundary is a bunch of monad imperative glue.

I think at the end of the day FP makes the hard things easy and the easy things hard. But as the Turing Machine and Lambda Calculus are equivalent then being adept at both schools is like having twice the arsenal for dealing with a given problem.

*naturally when performance becomes a problem you start to unravel abstractions.

1. Talk about it in isolation: we enjoy Haskell, here's where we think it should go.

2. Place it in the context of the wider software ecosystem, as in these are the pros and cons, barriers to adoption etc.

What isn't effective is doing #2 while not trying to really engage with reality. If you just assume, contrary to evidence, that Haskell is the right way and the reason it's not adopted more is that everyone insists on doing things the wrong way, you will not convince anyone who doesn't believe this fairy tale already, and worse, you'll ensure you won't help yourself, because you focus on the issues you wish you had rather than the issues you actually have. Self-reflection is supposed to help you, and it only helps if it's a long hard look in the mirror. The approach of, "things aren't going the way we hoped but our assumptions could not possibly be wrong so we'll just examine everyone else's" is not generally useful, as it's nothing but a waste of time: you know you'll end up exactly where you started.

Has finally Haskell the problem of how to do destructive updates or not?

If it cannot do destructive updates, I am not interested. The kind of software I am called to build always requires destructive updates for performance reasons and secondly I am so used to assignment and all the design patterns around it that I don't think I should bother with something that does not provide that.