What is Nostr?
Panicz Maciej Godek /
npub1t3p…cyhf
2025-01-21 22:28:52
in reply to nevent1q…f5hv

Panicz Maciej Godek on Nostr: nprofile1q…72gd0 I just had a quick look at the free sample, and my impression is ...

nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpq3dyy3r0j8duxhwduyxhw9yjkkf7eu2hw44nn3k0cuuzu9ldp2qqqr72gd0 (nprofile…2gd0) I just had a quick look at the free sample, and my impression is it just copies the same pedagogical mistakes that can be found almost everywhere else.

"Monad is an abstract concept, which we programmers discovered after many at-
tempts to refactor and generalize code." - this is not true (not in my experience anyway), and not very helpful.

The notion of a monad wasn't born from generalization of different "cases of monads", as many tutorials try to explain.

It was created in the "abstract-nonsense-like" style of reasoining with category theory: a monad is (literally) an awkward generalization of function composition operator.

The type of function composition is
(b -> c) x (a -> b) -> (a -> c)

It looks nicer when we flip the order of arguments:

(a -> b) x (b -> c) -> (a -> c)

We can get one particular type of generalization by considering an extended composition operator that would be able to compose functions which can add "one particuar kind" of "something extra" to their result. This way, we would obtain the signature:

(a -> m b) -> (b -> m c) -> (a -> m c)

which is how we essentially arrive at the notion of monad.

Now, what "adding something extra might mean" - this is something that you can get from studing particular examples (such as Maybe).

But the attempt to arrive at the general notion of monads from looking at particular examples and generalizing from them is crazy, needlessly difficult and historically inaccurate.
Author Public Key
npub1t3pucnsn50uyh4dw3ye38wqekm0a6rf05nkmlrwq8tlf4ty86frsk5cyhf