> none of it matters if you hope more people use and understand functional programming

On a personal level, I couldn't care less tbh. If people want to learn it, that's great, if not that's also fine. There's plenty of room for procedural, OOP, and FP to exist side-by-side. If one domain feels complex to you, don't do it (or put extra effort into learning it), but I'd argue that OOP is much more complicated - it's just that most devs tend to grow up with OOP and so the context switch to FP is more difficult.

> you overestimate how much people actually understand oop vs just winging it, in particular, inheritance and polymorphism

Forget 'polymorphism' for a second and think about 'object'. An object in the real world doesn't have behaviours attached to it. An object in the real world doesn't mutate, in-place, in a discreet portion of time. Objects in the real world have a immutable past, a present state, and multiple possible futures based on interactions with external events. Those interactions is literally how we define time. OOP (as it's commonly practiced) does away with time and has myriad complexities because of it.

The trivial OOP explanation "an object is like a thing in the real world. A rabbit is an object, a triangle is an object, etc." combined with the unbelievable complexity artefacts (in place mutation, hidden state, attached behaviours, etc.) - is much, much worse than the upfront cost of learning about: pure functions, monadic composition, etc. (IMHO of course).

My argument would be that the so called simplicity of OOP terms and the alleged simplicity of learning them actually comes with ton of baggage. The upfront effort with monads or any of the other FP concepts at least is rewarded with code that's more 'honest', robust, and can properly model time.

> i posit that it is only "hard" because when learning about these concepts, we read shit like "a monad is a monoid in the category of endofunctors" - that's an exaggeration but one that clearly shows how absurd some fp texts sound to outsiders

There's probably an element of that. There's definitely two camps in FP. Those that come at it from an academic standpoint and they think about the abstraction and what it means for composition and the like. Then there's the jobbing FP peeps - who actually use it in real world code - they might think in terms of concrete monadic implementations, like List, Option, Either, etc. but also larger more domain specific monads: like a FrontEnd monad, or a DataLayer monad.

To fully grok monads (or at least to get the most out of them) you kinda need to know both and why they can be useful to you. So, maybe there's an element of that. Because a monad can literally encapsulate any behaviour you want it's sometimes quite hard to talk about their possibilities without going into the theory.

But I think there's another aspect. In languages that have first-class support for monads ('do' notation in Haskell, LINQ in C#, Computation Expressions in F#, etc.) they don't actually work like any other paradigm in programming. The idea that something runs 'in between the lines' of your code and the 'thing' that runs is the flavour of monad you're in; is just different to say a visitor pattern, or an adapter, etc. that have explicit invocations.

So yeah, I think it's just one of those things that takes a bit of time to get in your head. But once you do the possibilities are enormous, you give whole sections of code a 'flavour' rather than it being an explicit invocation of a behaviour. It adds a completely new tool to your programming toolkit: one that's unlike any other.

We see this turning up in things like async/await. Most people understand that once you have some awaitable code, everything around it becomes async 'flavoured'. That's what happens with all monads. An Option monad will make the whole code block optional, a List monad will iterate a list for every line of code - and the result is a List, a domain-specific monad might carry the configuration of the application, or a database connection string, so you don't have to do it manually, etc. The monad is simply the encapsulation of the flavour.

The phrase "a monad is a monoid in the category of endofunctors" is more of a joke than anything else from 'A Brief, Incomplete, and Mostly Wrong History of Programming Languages' [1]. It may actually be true, if you want to see how that phrase comes about it's worth watching Bartosz Milewski's Category Theory series [2] , he gets to it about 10 episodes in, but you need to watch them all to understand it.

However most FP programmers wouldn't know what that phrase means. It's absolutely not required to learn CT to know how monads work, or even what makes the abstraction so powerful. The same with other terms inherited from CT, like 'functor', 'monoid', 'polymorphism' (!!!), etc. The programming language version of these things are not the same as the maths versions - although they're clearly inspired by the maths.

Having said all that, I was surprised at how simple CT was when I started learning it. I am certainly no CT expert, but there's literally 3 or 4 rules to learn and you're done (in terms of what's useful for programmers). There's lots of higher maths stuff that's coming out of it that's mostly irrelevant for programming, but one thing I got from it was a new way to think about structure.

It's like a 10,000 foot view of the schema of an application where you stop thinking about the data and you start thinking about the relationships between types. This is a powerful tool when trying to get a handle on the complexity of a system.

You can't write code in CT, but, just like with monads, knowing it and knowing some of the theory behind it, gives you some programming superpowers (I know that sounds grandiose, I just couldn't think of a better description).

And the end of the day everything in FP is about function composition. Monads are functions, functors are functions, monoids are functions. The name attached just describes the shape of the functions needed for the composition to work.

Understanding why those shapes are useful is learning your craft.

[1] https://james-iry.blogspot.com/2009/05/brief-incomplete-and-...

[2] https://www.youtube.com/watch?v=I8LbkfSSR58&list=PLbgaMIhjbm...