But words like "incapsulation" or "polymorphism" or even "autoincrement" also sound unfamiliar and scary to a young kid who encounters them the first time. But the kid learns their meaning along the way, in a desire to build their own a game, or something. The feeling that one already knows a lot, sort of enough, and it'd be painful and boring to learn another abstract thing is a grown-up problem :-\

▲

Nevermark 2 hours ago | parent [-]

Those words need definitions, but they can both be defined using words most people know.

Casual attempts at defining Monads often just sweep a pile of confusion around a room for a while, until everything gets hidden behind whatever odd piece of furniture that is familiar to the person generating the definition. They then imagine they have cleared up the confusion, but it is still there.

	▲	nine_k an hour ago \| parent [-]
		Most engineers don't have too much trouble understanding things like List<T>, or Promise<T>, or even Optional<T>, which all demonstrate vividly what a monad does (except Promise in JS that auto-flattens). A monad is a generalization of all them. It's a structure that covers values of type T, some "payload" (maybe one, like Promise, maybe many, like List, maybe even none, like List or Optional sometimes). You can ask it to do some operations on these values "inside", it's the map() operation. You can ask it to do similar thing when operation on each value produces a nested structure of the same kind, and flatten them into one level again: this is flatMap(). This is how Promises are chained. The result is again a structure of the same kind, maybe with "payload" of a different type. This is a really simple abstraction, simpler than most GoF patterns, to my mind, and more fundamental and useful.