Haskell could be both...funny and daunting.

Haskell type terminology is not that hard.

An ADT, algebraic data type, is a type which can be constructed algebraically, a "composite type". A list, an enum, a balanced tree, a union, a deck of cards, an optional/maybe value, etc.

An (endo)functor is a "mappable". Not strictly just that — it's any algebraic datatype which allows functions to be applied to it's "wrapped value(s)". In practice, all functors are endofunctors because you always map between things in the category of "types".

A monad... Is just a "flatmappable". It allows you to apply functions which take a wrapped value, and return a wrapped value, and you don't end up with more "wrapping" than you started out with.

Technically a bit more generic than flatmap — a monad is free to define how to "map", and also free to define how to "flat", and technically that flattening (join) doesn't just strip wrapping, it might melt, compose or replace wrapping in other interesting ways.

A Python list is a monad. A Rust Result is a monad. A Swift Optional is a monad. Fuck it, a Laravel Collection is a monad.

Now, people argue: "Is the type the monad, or is the function the monad?".

Mathematically speaking, that question doesn't make sense.

A functor/monad would be what you picture in your head when you think of a room, the process of reorganizing the furniture, and the resulting new room. The whole operation. The morphism. Both rooms, and what happens to them. (Also: A catamorphism is just a "reduce", an anamorphism is a "generator")

Now, you hear about "monad laws"... Which are basically mathy FP definitions which an OOP person would define as "The type (class) can be constructed, composed and mapped over".