Hacker News Reader

Comment by kens | Hacker News Reader

I'm not sure why it's interesting to label all these things as monoids. It seems kind of the tail wagging the dog.

More concretely, "monoid" seems both too general and too specific to be useful. Things that commute and things that don't commute are lumped together as monoids, and that seems to be a much more useful distinction.

Consider the monoids described in the article. For concatenation and file paths, order is important. On the other hand, multiplication, addition, maps, sets, and the shape examples all commute, so the ordering a monoid gives you is irrelevant. How does it help to consider both concatenation and addition as monoids?

(I'm honestly trying to see the relevance of monoids.)

View on HN

I really recommend this article about designing a graphics library with a lot of monoid structures.

http://repository.upenn.edu/cgi/viewcontent.cgi?article=1773...

For me it gets interesting when you compose monoids, and that article has several elegant examples.

Otherwise I think the monoid structure is not super interesting in itself, but it's a really useful building block when thinking of software "algebraically", which to me is the most interesting aspect of Haskell as a programming tradition.

As for commutativity, I'm not sure how to answer. The monoid notion is useful in both commutative and noncommutative settings. When composing monoids one might be commutative and others noncommutative (like, say, a tuple of int and list of strings, the int being a total size and the strings being file names).

It's useful when you write functions that take generic monoids as arguments, such as many aggregation functions on data structures. For instance, finding the largest element in a tree, or the first successful result in a list of actions. Structuring the code like this separates the concerns of traversing the data structure and performing the particular type of aggregation. Haskell has the function foldMap which implements this idea.

If this is interesting to you Dan Piponi goes into significantly more detail (http://blog.sigfpe.com/2009/01/haskell-monoids-and-their-use...).

> (I'm honestly trying to see the relevance of monoids.)

https://news.ycombinator.com/item?id=15242204

I can't speak to the relevance of monoids (I don't have much experience with FP) but to me those examples are helpful in illustrating the definition. It's easy to assume associativity <=> commutativity until presented with counterexamples.

The question, though, is whether using the definition justifies its cognitive overhead, by making some class of ideas substantially easier to communicate or represent.

Yeah. I mean, I work in computer algebra, and these things strike me as trivialities.

"Early on, Peter Freyd wrote

> 'Perhaps the purpose of categorical algebra is to show that which is trivial is trivially trivial.'

"This can be taken to mean that one thing category theory does is help make the softer bits seem utterly natural and obvious, so as to quickly get to the heart of the matter, isolating the hard nuggets, which one may then attack with abandon. This is an invaluable service category theory performs for mathematics; therefore, category theory is plain good pragmatics."

https://ncatlab.org/nlab/show/nPOV

I would say equally "This is an invaluable service category theory performs for programming; therefore, category theory is plain good pragmatics."

Sure. Especially in abstract algebra we have a whole, complex edifice that builds upon semigroups and monoids. But computer science doesn't have the same edifice (or anything resembling it), so you're mostly confined to "look, this is a monoid, isn't this neat?" and then things sort of end there. Actual use cases for monoids as building blocks for more complex concepts are pretty rare in computer science. And even in mathematics, the fact that (say) a ring is also a multiplicative monoid becomes mostly irrelevant soon enough.

> in abstract algebra we have a whole, complex edifice that builds upon semigroups and monoids. But computer science doesn't have the same edifice (or anything resembling it)

Have you heard of applicative functors and monads? These are part of an edifice of concepts that builds on monoids that we do indeed have in computer science.

Yes. And this is tiny compared to what's there in mathematics, limited mostly to people who write Haskell fanfic (from Haskell proper to Scalaz), and, to be blunt: the terminology is used more as a shibboleth than as an abstraction tool. Contrast this with F#'s terminology ("computation expressions"), for example. I mean, if your goal is to have adoption levels for Haskell rival that for abstract algebra and to keep the unwashed masses out, then the more arcane and unrelatable your terminology is for the average person, the better.

To give another example. "Strength reduction" as a compiler optimization relies basically on the fact that the distributive laws apply to rings. Yet you won't find a mention of rings in compiler textbooks that explain the technique. It's unnecessary to convey the idea and confuses more than it explains, unless you're one of the few people who already are familiar with rings as algebraic structures.

I don't really think mass adoption is a goal for Haskell. It's still a really inspiring system, and I've seen it bring a lot of people into contact with the rich traditions of pure functional programming and the use of algebra in code. Which is pretty cool, even if some people think it's irritating when these people write excited blog posts about a concept they find trivial, like monads.

I linked to a paper about composing monoids to build a graphics library. For me that particular paper was, years ago, one of the most interesting things I'd seen on how to structure programs.

Maybe this whole experiment with using algebraic concepts in programming is a dead end, and maybe it is even just a way for a bunch of nerds to feel smart. But it seems like a pretty valuable tradition to me.

There probably wouldn't be "computation expressions" in F# if it hadn't been for Moggi and the Haskell gang. Sure it's great that we can take these concepts and rebrand them to make them nice and cuddly (although "computation expression" is no paragon of simple english).

Blah blah blah. I'm kinda tired of the programming forum dialectics...

> Contrast this with F#'s terminology ("computation expressions")

OK, great! And what did F# call monoids, profunctors, semigroups, free constructions, adjoints ... ? The fact is that there are a lot of concepts we use in computer science (maybe not your corner, but yes in computer science) that already have names and history in the mathematical world. If you can suggest better names that we can use in computer science then that's great! Please tell me. Otherwise it seems reasonable to stick with the existing names.

They strike me as something less charitable: a vehicle for certain coders to pretend they're engaged in higher mathematics by using the jargon when less formal language will do (often with more clarity in fact).

Reply on news.ycombinator.com