News for hackers. Stuff that matters.
Re:What Monoids teach us about software by tw1010 on Wednesday September 13, 2017 @02:10PM (#15240942)
Not sure about monoids themselves. But learning about monoids was a stepping stone towards mastering parts of pure mathematics, which has definitely contributed to my problem solving abilities. Sometimes you need to just bite your tongue and learn some stuff that short-term feels useless but long-term becomes valuable.
Re:What Monoids teach us about software by vertex-four on Wednesday September 13, 2017 @02:20PM (#15241065)
Or if people are generally incapable of explaining how something they learned has helped them solve a problem in a domain I work in/close to, perhaps it's not that necessary to learn after all.
Re:What Monoids teach us about software by theoh on Wednesday September 13, 2017 @03:08PM (#15241551)
Here's an example of a monoidal structure used in the design of an elegant algebra for manipulating graphs (the network-of-nodes kind)

https://blogs.ncl.ac.uk/andreymokhov/an-algebra-of-graphs/

Representing graphs is a bit of a problem in Haskell, due to the difficulty of creating/working with cyclical structures, and the previous solutions were not really convincing. So in some ways this might be seen as a problem immutable data purists created for themselves. (Not my opinion)

But, either way, the ability to reason about and derive algebraic models for some problem domain is worth pursuing in general. Mathematically structured software is a fast track to robust, reliable, verified solutions to problems. That's propaganda but there's a fair amount of support for it.

An idea that comes up in functional programming that has a similar algebraic quality to monoids etc. is the notion of a type which contains only one value (usually called "Unit") and a type which contains no values ("Bottom" or _|_). The latter is described as "uninhabited" and is used, among other things, to usefully describe the type of a function which never returns. https://en.wikipedia.org/wiki/Bottom_type

Unit represents a value which is like a point in a space which contains only one point. It gets used to send signals with no content. For example, in predecessors of Go, there's the pattern of sending on a "channel of unit" as a way to essentially indicate an event to the receiver. Obviously in that use case, a type with any distinguishable values would be superfluous.

Re:What Monoids teach us about software by Koshkin on Wednesday September 13, 2017 @03:43PM (#15241875)
Interesting, although I am not sure how Unit and Bottom are related to monoids. Also, how does this translate, say, into C or C++? Unit is easy:

  struct Unit {};
but what about Bottom?
Re:What Monoids teach us about software by theoh on Wednesday September 13, 2017 @04:41PM (#15242407)
Even Haskell doesn't have a way to declare a value precisely of type Bottom.

As far as the connection with monoids goes, Bottom is a subtype of all types in the same way that the empty element of a monoid is a "zero" of the elements of the monoid. I don't know if that helps, but the similarity is that the types form a lattice, and so do the elements of the monoid. AIUI lattices (in the mathematical sense) have top and bottom elements, and in between they look like a DAG...

Re:What Monoids teach us about software by kbaldor on Wednesday September 13, 2017 @04:10PM (#15242123)
How about:

class Bottom { private: Bottom(){} };

Re:What Monoids teach us about software by Koshkin on Wednesday September 13, 2017 @04:27PM (#15242261)
This does not look right. If I understand correctly, the position of Bottom in the hierarchy of types is exactly the opposite to that of Unit: the latter could serve as the "universal base" (like the type Object), whereas the former could be seen as the "universal descendant" (some kind of Null type). In other words, Unit is "anything" and Bottom is "nothing".
Re:What Monoids teach us about software by theoh on Wednesday September 13, 2017 @04:44PM (#15242438)