[GhostWhisperer]

if people cannot learn the concepts when presented with the monad and functor names, but somehow are able to understand them when given different names, it seems the issue is the names are bad

what is creating confusion is this need to sound like a pompous academic by sticking to old terminology that serves no purpose but to make their users sound enlightened and the subject hard to grok

the functional programming community could gain a lot from making it's subject more accessible, not less

[louthy]

How is it any different to someone learning OOP?

* Objects

* Class

* Interface

* Polymorphism

* Parametric polymorphism

* Methods

* Method dispatch

* Inheritance

* Singleton

These bear no relationship to the real world usage of these words and some are straight out of mathematics/academia also.

Would you expect FP people landing in OOP land to rename all of these concepts just so FP people can understand OOP languages? Or would you expect them to learn the shared lexicon of OOP-land?

It isn't pompous to have a name for something and then expect people to learn those names if they want to learn the subject. Pomposity would be attaching "oriented programming" to the end of all concepts that you don't understand and telling the world to use your new terminology whilst trampling over the existing community.

Clearly grokking monads is hard. But it's nothing to do with the terminology. This presentation has over 150 slides - so even when it's called 'Railway Oriented Programming' it takes 150 slides worth of exposition to get the point across. I'd argue that the reader/listener would be in the same place if they'd have used railways as an analogy whilst telling the reader that they're learning their first monad.

'Monad' may well be an awkward word but it's clearly the mental model of the monad that's the problem. I suspect (as someone who's taught how monads work many times) that part of the problem is that once we learn how monads work, we realise they're unbelievably trivially simple. And at that moment we instantly lose the ability to explain it to somebody else because of the 'mental perspective switch' that's just happened in our brains.

So we end up with a 1000 'Yet Another Monad' tutorials. This may well be the best one. But it shouldn't mean you get to change the shared lexicon.

[thewix]

When I was trying to learn monads no one ever gave me an example of mapping a list-returning function to a list. Everyone went on about 'effects', monad laws, etc. For some of us it's best to work backwards from something concrete and then show why the laws are important.

I love how simple most things are in FP compared to OO. I also hate how poorly FP concepts are explained.

I'm not saying you're wrong about people learning terminology. However, you definitely get more strange looks from FP terms than OO terms. Class, interface and object are common terms. When I mention a word like 'monad', 'monoid', 'magma', or 'functor' people look at me like I'm nuts. It's not logical. A new word is a new word. It's just FP words sound almost alien and trigger extra confusion in people.

[piaste]

Hot take: some of those names are bad too (e.g. 'polymorphism' is very vague), and OOP would be easier to learn if there was a beginner's vocabulary.

Yes, "dynamic structural typing" is a coherent and logical name when you're familiar with type theory.

But a learner can understand "duck typing" much faster. The jargon can come later.

> 'Monad' may well be an awkward word but it's clearly the mental model of the monad that's the problem. I suspect (as someone who's taught how monads work many times) that part of the problem is that once we learn how monads work, we realise they're unbelievably trivially simple.

I'm on team "join is way easier to understand than bind".

[GhostWhisperer]

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

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

but back to fp, if monads are, and i'm growing to agree with you this, "unbelievably trivially simple," how can it be that "grokking monads is hard"?

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

edit: i get worked up with folks that write about fp the way you argue it must be written. for the few concepts i have been able to grasp i have been thoroughly impressed, but i am being impedded from learning more, or faster because of the hard to parse lingo

[louthy]

> 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...

[GhostWhisperer]

i'm not reading any of that