Live data from Hacker News

Monads are monoids in the category of endofunctors

sambernheim.com

141–150 of 241 posts

Re: Monads are monoids in the category of endofunctors

#141

Hands up if you've never actually seen FP out in the wild doing something. Not saying it's not out there or useful - just saying that after 20 years I'm yet to come across it once.

Ever use Facebook? WhatsApp? Discord? Telephones? Docker? Amazon EC2? Bought something in a Walmart store or on their websites? etc. etc. Some of their core, critical parts are written in functional programming languages. Just because you don't see FP out in the wild being conspicuous, doesn't mean it's not there ;-)

Which parts in particular? Genuinely curious.

Re: Monads are monoids in the category of endofunctors

#142

Earlier quoted context omitted.

Generalizations are always imperfect, and I felt I was explicit about the fact that there are exceptions (like the OP). I'll admit my emotions got a little heated. I get really frustrated thinking about all the potential out there that gets wasted just because of gaps in communication (willful or otherwise), and not because of capacity for understanding. And this very comments section demonstrates the unwillingness b…

I am a self taught programmer who first learned python and then learned Haskell. A lot of concepts in python were difficult when I was new and the same is true for Haskell. I found the Haskell community to be very welcoming and very willing to explain their terms and the reasoning behind them, and I dont find the negative characterizing from you and others about them to be true at all. That's why it really bothers me…

Good points. But I'd note that Haskell's infrastructure around Functor isn't typical of functional languages. Specifically in Haskell, I think it's pretty important to have an idea what functors, monoids and monads are, because these are typeclasses that you will almost certainly be using at some point. Not all functional languages have typeclasses or an alternative and convenient way to express these concepts, and in those, it's not so important to understand these notions abstractly.

Re: Monads are monoids in the category of endofunctors

#144
Wow, this was unexpected.

Like many, I'm still learning a lot of this - especially the formal terminology and the distinctions between the mathematical and computational variances of these ideas.

It can be tough to push past the more intense and techincal jargon and I enjoy writing about these ideas to document my learnings for myself and to try and make it more accessible to others.

I'm happy some found it useful and for the discussion here where people can help correct and inform parts that aren't as sound.

Re: Monads are monoids in the category of endofunctors

#145
post #8

Earlier quoted context omitted.

Kind of reminds me of an old saying I heard somewhere, that I'll paraphrase here: "novice writers use little words, intermediate writers use big words, and expert writers use little words." Like, it's fun to communicate in technical jargon -- and personally I'm quite proud of the vocabulary I have built up over time -- but you are totally correct in that it serves as a gatekeeper for an in-group to retain its dominan…

I very much agree with part of your point, especially the novice-intermediate-expert part on jargon. I generally favor wording that is as simple as possible, but no simpler . Sometimes technical precision is important, and when talking to colleagues and other people that are on a similar technical proficiency level as me I prefer concise and informative words. I'd rather say "ARP poisoning" than "network attack", bec…

My point wasn't so much a dig at FP as it was at programming in general. For example, I started my career writing Perl, which uses the word 'hash' to describe a dictionary-like datastructure. But Python uses the word 'dictionary' to mean the same thing. Javascript's equivalent is an 'object', though it is effectively a different. Other languages call this datastructure a 'map', others an 'associative array', and so on.

It's like, effing pick one! And if you have to have multiple why do they have to overlap with other completely different things? When I first read about a 'map' in this context I was very confused.

You also see this a lot comparing Microsoft environments to everyone else. Reading microsoft docs in the late 90s (which is where I first learned a lot of these concepts) you learn one set of vocabulary, and then in the _nix and webdev worlds you learn a whole different set. Take 'databinding', for example... I have not once heard this term used discussing shadow DOM stuff like React or Vue, yet databinding is exactly one of the services they provide. But no, they have to call it something different, making a lot of prior-art type research much more difficult than it needs to be. Perhaps it is part of the reason why the webdev world seems so intent on pointlessly repeating history. It hampers discussion and contributes to the conceptual isolation and tribalism that seems so common in this field.

(And in the perl example, yes I know it's short for hashtable and that this is because this dictionary-like thing is exactly that, but I think that from an end-user's point of view it would be best if all these different terms were unified)

Re: Monads are monoids in the category of endofunctors

#146
post #5

Wait, a functor is just a pure unary function? And an endofunctor is just one of those where the argument type and return type are the same? This could have been explained to me years ago, in five minutes? Sometimes it makes me mad that so much confusion (and as another commenter put it, gatekeeping) has been sown in FP circles through the invention of pointlessly-obfuscated terminology for everything (and through -…

Edit 2: I'm sorry for getting a little inflammatory with my original comment. I have a headache today, and one of my biggest frustrations is needlessly poor communication of concepts, especially if it's willful, and especially if it wastes the potential of capable people who could otherwise be given understanding. With that said I may have gone on a bit of a rant here and made some generalizations, and I don't feel g…

You remind me of when I started to actually get this stuff and it occurred to me that monads are just metadata+data with some special properties, and I posted about it on reddit and got downvoted to hell and told the many ways how that's wrong. The FP crowd...must be great at parties. I get this frustration.

I think a big part of it is difference in definitions. There's the mathematician's monad, which is pure and abstract and obeys all these laws. And then there's the engineer's monad: an interface you can map, ap, and flatmap over. People get so hung up over "algebraic purity" they forget why they were invented/co-opted for software in the first place: to solve the problem of applying pure functions to side-effecty operations.

> A monad is a wrapper. Anyone who tells you otherwise is being obtuse.

https://rcrowley.org/2011/09/21/monads.html

Re: Monads are monoids in the category of endofunctors

#147
post #56

Earlier quoted context omitted.

A Mappable would be anything that has a `map` function. A `Functor` is a something that has a `map` function _AND_ obeys the rule that calling `map` with the identity function produces the same result. ie: say I have some value `f` that is a functor. If I call `map identity f` I should always get back `f`. The mere existence of a `map` function doesn't imply this law holds. The identity function always returns it's a…

> They also need to preserve composition. I didn't state this because this generally comes for free, assuming no shenanigans such as runtime type reflection/type-casing (but in that case all laws go out the window). In particular in Haskell (which is what I assume you're coming from given fmap and your ML-ish syntax) this is a superfluous law. If a type constructor's `fmap` obeys the identity law, it must obey the co…

Yes that seems right, sorry.

Re: Monads are monoids in the category of endofunctors

#148
post #63

Earlier quoted context omitted.

A type constructor is something that takes a type and gives you a new type. For example, in C, if you have any type Foo, the pointer operator * will give you a new type Foo*. Another example: in Haskell, Maybe is a type constructor, since it takes a type parameter a (Maybe a). So 'Maybe' is a type constructor, but 'Maybe Int' is a type. So a type constructor is like a function, but it operates on types, not on values…

> the pointer operator * Do you mean declarator?, As in: Foo * f; // f is a pointer to a Foo The operator dereferences something - it certainly does not create a new type. And neither does the above - the concept of pointers to addressable types is innate to the C and C++ type systems - if you create a type Foo, you get pointers to Foo for free.

The fact that pointers to Foo are "free" doesn't invalidate the notion that the * is, in some sense, a semantic extension of whatever Foo is and thus a generic type. I know that this is not literally true in the "theory" of the C programming language and type system, but conceptually it matches up pretty well.

Re: Monads are monoids in the category of endofunctors

#149
post #29

If you're looking for a not-quite-monad tutorial that answers real-world programming problems, blows the gates off monad-notation gatekeeping, and pokes good-natured fun at the OP title, I highly recommend Railway Oriented Programming: https://www.slideshare.net/ScottWlaschin/railway-oriented-pr... https://fsharpforfunandprofit.com/posts/recipe-part2/ for a text version https://fsharpforfunandprofit.com/rop/ for the…

Scott Wlaschin is an excellent resource. His presentations and website are incredible.

Re: Monads are monoids in the category of endofunctors

#150

Earlier quoted context omitted.

Here's how I like to think about things: Values are things . Concrete. Since we are manipulating computers, a value is really just some abstract symbols--1s and 0s occupying a slot in memory. The meaning of the symbols exists on a higher level, what we usually call semantics . Types are a well-studied method to attach semantics to blocks of otherwise meaningless (but concrete!) symbols. By declaring a variable (which…

> then you can "lift" I would say "sigh", but you have to say what you mean.

Do you say "sigh" because the functor arrows typically go sideways in a diagram? I'm taking a classroom course in category theory right now, but it's my first exposure to actual formal instruction in this subject so I don't know all the standard terminology just yet.
Post reply on HN