I’ve recently started having a play with haskell, and I have to say I quite like it. The big problem I am having with haskell is not haskell. It‘s the documentation and guides people write about haskell, coupled with the names it uses for things.
Now, I say I have a problem with the name that Haskell uses for things, but I also don’t. That’s because the writers of Haskell are keen that their abstract math concepts are given the same name as everyone else’s abstract math concepts, so that people who work in that space can port their understanding to the use of Haskell. I think that’s a good thing.
However, when you read about applicative functors and and monads and monoids and you aren’t someone who operates in the abstract mathematical space, it doesn’t really help you because it is not a name which describes what the properties of the monad are, and so doesn’t help you use the abstraction.
However, on a software engineering level, that may matter less than is immediately obvious, and it is my suspicion that trying to grapple monads early is actually an unhelpful manouvre.
For the first few programs I wrote, I wasn’t using Monads directly. Moreover, for those first few programs, that didn’t matter at a functional (aha) level, the code fundamentally worked, and it wasn’t bad. I definitely didn’t need to create any novel monads.
Eventually, it did get to a point where I needed to write a function which accepted an arbitrary object which matched the abstract properties of a monad. And this is when the realisation struck that an abstraction is ultimately just a named bag of properties - the word itself is a bit of a moot point.
I had ultimately maneuvred my brain into a point where I needed to write a function that accepted objects of n types, all of those types happen to belong to that typeclass (because that describes the bag of properties that those types share) and that was, at a practical level, all that mattered.
Now, it is definitely worth mentioning that up until this point, lots of the code I had written would have been possibly more elegantly written if it had simply accepted monads and not dealt directly with say, lists, but it wasn’t necessary.
I suspect, to an extent, that this is why we are left with the maxim that anyone who understands monads instantly loses the ability to explain monads to anyone who doesn’t understand monads. They become ”just monads” - a bag of properties. Importantly in an engineering context, they are also a category of concrete types, and more often for engineers it is the concrete types that will matter just as much as the bag of properties.
I do wonder, therefore, if a guide to haskell might not be better placed in trying to introduce a handful of concrete types, and then place them in categories and describe how they fit into those categories, and what common properties that class of types (see what I did there?) have, and how they might be utilised. Alas, this is a blog and not a haskell guide, so I won’t be giving that a run here just yet.