Live data from Hacker News

Monads are monoids in the category of endofunctors

sambernheim.com

111–120 of 241 posts

Re: Monads are monoids in the category of endofunctors

#111
post #41

Earlier quoted context omitted.

Functors are type constructors, not functions (which map values). But you could be forgiven the misunderstanding, because it is easy to trip over this distinction given the identical syntax. So, to make this absolutely clear, a monad is a type constructor in functional programming. This is why I personally prefer the more “creative” explanations of monads, because they attempt to explain what the monad is doing to th…

> a monad is a type constructor Now explain what a "type constructor" is, otherwise these words are worthless.

Integer is a type.

List is a type.

List is a type constructor.

In order to get a real type from a type constructor, you need to "pass it type parameters". In the example above, you need to say that T is Integer.

Re: Monads are monoids in the category of endofunctors

#113
post #97

Earlier quoted context omitted.

Not exactly dynamically - both a monad and a functor have to be a kind of "function" from type to type. The most common kind is a generic type with one type parameter. (e.g. you can see "List" as the "constructor" that takes "String" to "List ", takes "Int" to "List " and so on)

Many thanks!! So is it something like Class > thisistypeconstructor(Class strClass) And if I generify the types above, maybe something like thisistypeconstructor( )

Not quite - the type constructor is the thing that does the same thing with the types themselves, not with Class (which is sort-of-but-not-really a way to represent types as values). In Java or C# there's no way to actually represent a type constructor (e.g. you can't have a class that takes a type parameter F that could be List or Set, and then you use that type to form F within the class itself and it will be List or Set depending on whether you do new MyClass or new MyClass), but other languages are more powerful in what they let you do with types. Look up "higher-kinded types" for the general concept.

Re: Monads are monoids in the category of endofunctors

#114
post #41

Earlier quoted context omitted.

> a monad is a type constructor Now explain what a "type constructor" is, otherwise these words are worthless.

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.

Re: Monads are monoids in the category of endofunctors

#115
post #88

Earlier quoted context omitted.

I don't like creative explanations. Definitions are easier. A functor is a PAIR, please notice the emphasis, of a type constructor F and a map function with the following signature: a -> b -> f a -> f b. Its not a type constructor, it's a pair of two things, the type constructor AND its map function. Now that we said what it is we provide the usual simple example of Array, Record or Option, show the type constructors…

> `a -> b -> f a -> f b` (a -> b) -> F a -> F b; the parentheses are critical. I don't fully disagree with your point, but if you're going to emphasize rigor and definitions, it would be wise to make sure you're not setting people on the fence up for mistakes akin to those in the original post. (You also called it `F` and then used it as `f`.)

To add, I suspect that the Haskell type notation is not intuitive to people not familiar with it. For anyone wondering, (a -> b) -> f a -> f b means "A function taking a function from one type to another "(a -> b)" and a functor applied with one type "(f a)" and returns a functor applied with another type "(f b)".

Re: Monads are monoids in the category of endofunctors

#116
post #41

Earlier quoted context omitted.

> a monad is a type constructor Now explain what a "type constructor" is, otherwise these words are worthless.

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…

This is lovely, thank you

Re: Monads are monoids in the category of endofunctors

#117

Earlier quoted context omitted.

It often makes me very mad that so much gatekeeping has been sown into programming circles through the invention of pointlessly-obfuscated terminology for everything. Programmers are really arrogant most of the time, they dont want to teach beginners their craft so they just make everything difficult on purpose. They are like medieval priests yada yada. Does what I write above bother you at all? Do you feel that it a…

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 how you and others are so willing to slander a whole community based on what I perceive as not the truth at all. That's also why I wonder if you would be ok with non-programmers making the same generalization about programmers.

In my experience concepts like Functors, Monoids, Monads etc. are difficult, not because they are complicated, but because they are seemingly too simple. A Functor is pretty much something you can map, and every programmer knows list.map, so what's the point? The point is that when you have some infrastructure around using them, then you can see new ways of using them, and you can see that mapping makes sense over a lot more structures than lists. Even over something like a function "a -> b". The problem is that non-functional languages doesn't have this infrastructure around them, so they are not very useful, and so its difficult for people not using functional languages to understand what the point is. I dont really think there is any way to get past this unfortunately and the only way to get comfortable with the terms is to program in a functional language.

Re: Monads are monoids in the category of endofunctors

#118
post #103
post #89

Earlier quoted context omitted.

Not exactly. When using the I/O monad in a pure language like Haskell, your code doesn't directly have side effects, instead you're building a container (a monad) of instructions of what side effect having operations to do, and what should be done with the results. The Haskell runtime then takes this monad and unwraps it layer by layer, each layer executing the side effect having instruction and using the results of…

> instead you're building a container (a monad) of instructions of what side effect having operations to do, and what should be done with the results. The Haskell runtime then takes this monad and unwraps it layer by layer, each layer executing the side effect having instruction and using the results of the side effects as input for unwrapping the next layer. Note that this is the implementation of a specific monad -…

> But the interesting part of Haskell's I/O isn't the implementation, it's the (pure) API that it uses, and Javascript has nothing like that.

No, I insist JavaScript really has a pure approach to I/O, quite like Haskell. There is literally no side effects except for application state mutation from the perspective of a JavaScript function (if you disregard the few deprecated synchronous API's). And this pure API has proven very useful and distinctive for JavaScript (i.e. through node.js)

Re: Monads are monoids in the category of endofunctors

#119
post #104

Earlier quoted context omitted.

I would say the person you're responding to didn't come in "guns blazing". They seemed legitimately eager to learn, and expressed gratitude that the person that wrote the blog post used language they could understand. Now, I would say you showing up and openly disparaging both the blog and the person you responded to qualifies as "guns blazing".

They said "It's like when the medieval Catholic Church refused to print a bible in anything but Latin so that they'd remain the sole authority on its content." and concluded with "shame on those who maintain this status quo." That's pretty "guns blazing" in my book.

> "It's like when the medieval Catholic Church refused to print a bible in anything but Latin so that they'd remain the sole authority on its content."

The debate is about using language as a gatekeeping mechanism. The analogy is spot on...

> "shame on those who maintain this status quo."

A person shows up eager to learn, expresses gratitude, feels scorned at all of the language-based gatekeeping that goes into this topic. You don't think it's fair to feel frustrated with the people doing the gatekeeping? (I don't think _you_ will, but only because I think you're one of the gatekeepers the original poster is (fairly) shaming).

Re: Monads are monoids in the category of endofunctors

#120

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 ;-)

Post reply on HN