> A Monoid can be defined a tuple (M, op, e)
This definition lost me completely because I'm not even sure what "defining it as a tuple" is meant to imply. Based on your explanation it sounds like that is fancy talk for saying it is defined by having three properties.
> In a statically typed language, we can translate the notion of set into the notion of type.
The second definition again completely lost me because I'm not even sure what "set" and "type" mean in this context and being able to "translate the notion of set" is unhelpful when the definition using a set is the one I didn't understand in the first place.
I'm a programmer with over a decade of professional experience. I don't understand the article because I have no formal education in higher math nor in anything beyond basic computer science. Your explanation proves it's possible to explain these concepts with practical examples rather than academic jargon.
Defining stuff as tuples makes sense, because then you can define the set of all such tuples (e.g. the set of all monoids for a given set M or the set of all graphs for the given vertices V) and formally reason about it :)
Yeah, in a computer science situation it's needlessly obfuscatory. It's literally just an interface with a "plus" method and an identity value.
You learn both languages. You do it because the vast majority of human invention and ingenuity consists if acts of translation. Anyone serious about working with computers should understand that.
I'm not arguing the underlying math isn't beautiful. I took grad level algebra and logic classes, so believe me when I say I know the math is awesome. But it just doesn't have any practical utility in programming, and more often than not just makes things more confusing.
edit: Also, since I majored in math, with a focus on logic, I don't think I'll have any trouble with losing sight of the foundations :)
But I'm a professional, not a CS student. I'm already spending my free time honing my craft and looking into new techniques and developments in software engineering. I can't afford spending yet more time on mostly orthogonal higher mathematics based on the hearsay of some guy on the Internet arguing it will allow me to understand a point somewhere down the line that might make me a better developer.
This is exactly the same thing people say who come to programming from playing jazz music or artistic painting or figure skating. They all claim what they did before makes them a better programmer and they're probably even right. But that doesn't mean I should pick up figure skating as a hobby at this point.
There are many different fields related to software development that can directly improve your performance as a developer. Not all of them are equally to all tasks a software developer might have to perform. I think it helps to have a mix of them, especially at the level of teams. There are times where the UX zealot can save the day and there are times where it's the one with the Master's degree in Metamathemagics. I wouldn't want to miss either of them, even they're mostly oblivious to each other's specialisation.
"I get paid, I don't learn."
You want to get paid, get paid. I won't care if you fail.
I suppose Alan Turing and Charles Babbage are just shit programmers next to you.
Eventually I figured out it is a generalisation of "couple", "triple", "quadruple", etc. It's one of those things, but we don't want to say the number.
(I just tried googling it, and the definitions I get are very maths-y and hard to understand)
In the case of configurations, "right bias" (aka Last) is probably a good choice. I don't like that Haskell chose it for the general Map instance.
reducers has a UnionWith newtype which gives you the better Map monoid. But I think it uses a lazy unionWith, which will cause your Map to leak space when used in a foldMap over many elements :(
[1] https://www.youtube.com/watch?v=WsA7GtUQeB8 [2] http://notes.asaleh.net/posts/monoid-pattern-in-python/ [3] http://notes.asaleh.net/posts/monoid-for-specifying-configur...
So all you need to do is to create the null object and the add and sub function on the type? And I can use an implementation of that type as the state for something?
How can I guarantee the order? Would I need to use something like a blockchain or is a distributed database enough, as long as only I need the data and trust myself? In a cluster would it make sense to use etcd
I think, even better would be a commutative monoid, that doesn't depend on the order. It should be possible to scale the global state in a distributed system very concurrent, because of the commutativity.
I would have to store a log (easiest part) and the current state. To sync state between the nodes in a distributed system, they would have to send update messages to each other. They're able to batch process multiple messages to improve throughput.
Vector spaces have addition over vectors and multiplication of vectors by scalars. Considering vector spaces and addition only, that is a monoid. It also happens to be further along this hierarchy as you have commutativity, inverses, and other properties.
A bit like the statement: all squares are rectangles, not all rectangles are squares. We can say that all vector spaces are monoids (under addition), but not all monoids are vector spaces.
Conceptually, a monoid is anything that:
- Has a "zero-value" (mempty, e.g., 0)
- Can be "appended" together (mappend, e.g., +)
- Has an identity with the zero-value: x + 0 == x, 0 + x == x
- Is associative: x + y + z == (x + y) + z == x + (y + z)
This isn't limited to just arithmetic with operators like +. You can define whole new types as monoids if they have these characteristics. For example, we can merge together configuration files by using monoid operators (in pseudo-code):
There's no need to break out the really formal definitions if you're just trying to get some nice working code.Borrowing from mathematics is beneficial because we can work with structures that have simple but useful guarantees. In Haskell, you can expect all the above to be true for correct type instances of Monoid, without the implementation details at hand. It's a core tenet of functional programming to disarm complexity with simplicity.