They are indeed simple and intuitive. You can explain them in terms of cooking.

Curry: f(x, y) = f(x)(y)

For cookies, whip butter with sugar. Curried version: whip /f/ the butter /x/, then whip the result while adding sugar /y/.

Composition: f ⭘ g = f(g(x))

To produce nicely shaped cookies, shape the cookies /x/ on a tray first /g/, then bake them /f/.

The fact that you originally swapped /f/ and /g/ in your comment then edited it to fix there mistake is perfect example of why this is a dangerous and bug prone approach to writing programs.

It's just f and g being poor names, also on keys next to each other. The circle is a good symbol for a whiteboard, but it's a poor identifier.

Normally you write composition like readFile().then(stripComments).then(sort).then(takeFirst), or compose using shell pipes.

Composition is so widespread and so trivial-looking that it's even easy to miss.

Strange take -- the whole basis of FP is dangerous and bug-prone?

Unlike the imperative `;`, which sequences commands in an absolutely obvious way, right?

While I understand curry and compose, I just don't consider them simple or intuitive in usage because normally I get cleaner result by not using them. I don't understand your recipe explanation unfortunately.

> because normally I get cleaner result by not using them

i doubt it. composition and currying are so fundamental.

Just to be clear, I don't use it in a pure form you'd see in many Haskell, etc. environments. I still use them when appropriate, with context-specific names and full arguments, because .then and "x => x<4" are more readable even if less terse.

> Composition: f ⭘ g = g(f(x))

This should be reversed. It is not defined this way in mathematics nor in Haskell.

Thanks! Reversing.

I don't find these analogies compelling at all:

> whip /f/ the butter /x/, then whip the result while adding sugar /y/

That's not a valid explanation, since curried functions don't "act" until they've got all their arguments; i.e. we do not whip any butter until the sugar has been added.

> shape the cookies /x/ on a tray first /g/, then bake them /f/

Whilst this is accurrate, I think introducing a notion of time ("then") makes things much harder than they need to be. (That's one reason I find imperative programs hard to understand)