shel

The Transsexual Chofetz Chaim

Mutant, librarian, poet, union rabble rouser, dog, Ashkenazi Jewish. Neuroweird, bodyweird, mostly sleepy.


I write about transformative justice, community, love, Judaism, Neurodivergence, mental health, Disability, geography, rivers, labor, and libraries; through poetry, opinionated essays, and short fiction.


I review Schoolhouse Rock! songs at @PropagandaRock


Website (RSS + Newsletter)
shelraphen.com/
You must log in to comment.

in reply to @shel's post:

i've had to look this up enough times that i can say with middling confidence: monads are basically just template types.

optional<T> is a monad. vector<T> is a monad. python's list is a monad. but they want to fit everything into the abhuman mindspace of category theory so they obfuscate the practical reality of "it's mostly the idea of a containing type with behaviors" behind a bunch of nonsense about "functors"

at the risk of starting Serious Discourse in a shitpost, monads are not just template types: there's a set of requirements on the semantics. for example, Predicate<T> = T -> Bool is not a monad because you can't write a function of type T -> Predicate<T>

templated classes then. things that define a distinct containing type.

i still don't think it's a helpful concept because, again, it's obscured by abhuman nonsense, digging hard into abstractions unique to a very peculiar way of thinking about problems that is (i have to say it) kind of neat but struggles with practicality

but StringArg<T> = String -> T is a monad, and you generally don't really say that a function "contains" its return values

the abstraction is weird but as someone who's done Haskell for years, it is pretty useful in the context of that language (along with all the other ones like functors, applicatives, etc)

I think I'd be a little horrified if you knew what a monad was, ngl. Poorly explained programming deep lore doesn't need to escape to other folks, lol.

(Unless you're a programmer on the side of all of the other stuff)