15 ms·

The problem with this argument is that a monoid is one of the most basic constructs you can find in abstract algebra. Using monoids as a shorthand for a couple

The problem with this argument is that a monoid is one of the most basic constructs you can find in abstract algebra. Using monoids as a shorthand for a couple of simple axioms doesn't buy you much; heck, the shape example didn't even have a use case for the neutral element, so all it basically said was: "intersection is associative". Just using a whole lot more words. Had the shapes example be modified to describe (say) a topological space via open sets, you may have a point.

mbrock 9y ago
The cool thing about algebra is that it lets you reuse concepts and computations between elementary arithmetic and a wide range of abstract or complex structures. It's probably true that most programs use only very simple monoids, but look at e.g. this article to see how composition of monoids can be a very powerful design pattern in functional programming. http://repository.upenn.edu/cgi/viewcontent.cgi?article=1773&context=cis_papers http://repository.upenn.edu/cgi/viewcontent.cgi?article=1773...
- rbehrends 9y ago
  And the article introduces a whole lot more concepts, such as homomorphisms in order to be sufficiently interesting. I don't say that you can't build interesting stuff on top of monoids (I have several colleagues that are doing just that), just that the concept of a monoid by itself isn't very interesting or deep.
  - mbrock 9y ago
    Sure. It's funny with these algebraic things. If they're simple, people complain that they're not interesting... but when you add some depth, people complain that it's too difficult!
    - tome 9y ago
      "I don't want to have to understand abstract algebra to use Haskell!" "Abstract algebra is too simple to bother writing programming blogs about!"
      - dllthomas 9y ago
        To be fair, it may not be the same people.
        tome 9y ago
        I'm sure it's not! But even so it's interesting to be caught between these two antipodes. As your probably know there's another group of people, Andrej Bauer among them, who provide a different antithesis to "I don't want to have to understand category theory to use Haskell!" by exclaiming "Haskell doesn't use real category theory!". It's just generally quite amusing to be caught in the middle of all this.
  - runeks 9y ago
    The goal of programming is to reduce all parts to such simplicity that they become boringly simple, and thus impossible to get wrong. Concepts are only interesting while we don’t fully understand them yet; when we’re done fully understanding them, they become boring and we move on to the next thing. Thus, the solution to programming is to compose programs out of boringly simple parts, using a boringly simple method of composition.
    - rbehrends 9y ago
      And how do monoids play into this? This is just a vague generality; unless you can show exactly what more complex programming concepts you can reduce to monoids and how that helps with understanding programming, that doesn't mean much.
    - kbenson 9y ago
      > The goal of programming is to reduce all parts to such simplicity that they become boringly simple, and thus impossible to get wrong. No, that's a strategy to achieve a goal of programming. Programming is about using machines that accept well defined instructions to automate processes for people. A complex and poorly understood program that still ends up reducing the overall amount of work required for individuals is still worthwhile, even if not reduced to being boringly simple.
      - lou1306 9y ago
        The main selling point is that reduction and "boring simplicity" can lead to a formally correct program, or at least one where most errors are caught by static analysis/type checking/etc.
        kbenson 9y ago
        I'm not saying it's not worth while, I'm just saying that it's not the goal (in general. Some academic exercises might have goals such as that because the point is to learn). It's sort of like saying the goal of owning a store is to match inventory to sales as closely as possible. That's a strategy or sub-goal towards reaching the real goal at best, which is to make enough money that the store pays for itself and hopefully supports the owner. Some stores don't even have inventory, so that strategy doesn't even apply to them. Similarly, that programming strategy may not apply well to some problems (and some problems cannot be proven formally correct, at least in whole). My original reply was really just meant to point out that what they viewed as the goal of programming, is really just one of many competing strategies for producing software, and many others don't care about that at all.
coldtea 9y ago
>The problem with this argument is that a monoid is one of the most basic constructs you can find in abstract algebra. That's irrelevant, because we are not naming them to use them in abstract algebra, but as abstract constructs in a different domain with its own complexity (programming).
- rbehrends 9y ago
  The lack of complexity comes from the fact that monoids are just defined by two simple axioms. Using them in a different domain does not change that. Associativity or having a neutral element do not become more complicated concepts in computer science.
  - coldtea 9y ago
    >The lack of complexity comes from the fact that monoids are just defined by two simple axioms. Using them in a different domain does not change that. You'd be surprised. A pointer (as in C) is an even simpler notion, but the complexity it represents to new programmers is big. Complexity in a programming element from the interplay it has with everything else -- not from it isolated.
    - rbehrends 9y ago
      The original argument was that naming them "monoids" reduces cognitive load. Can you explain how exactly you see this reduction in cognitive load coming to pass in programming? Because from your previous two responses, I don't see it. What aspects of associative operations with a neutral element are so central to teaching programming that naming such a construct "monoid" gives us a stepping stone towards better understanding programming?
      - tome 9y ago
        Which is easier to comprehend at a glance? * Under my Foo API you are able to combine Bars monoidally * Under my Foo API you are able to combine Bars using baz such that `baz (baz bar1 bar2) bar3 == baz bar1 (baz bar2 bar3)` for all `bar1, bar2, bar3 :: Bar`, and also `baz == Bar quux baz == Bar baz quux` for all `baz :: Bar`.
tikhonj 9y ago
The real advantage is that we can express the abstraction in the language, which lets us write libraries around it. A single function like fold is much nicer than either having one per type or having to pass in the operation and identity manually: fold :: (Monoid m, Foldable t) => t m -> m The fact that monoids are so simple is actually what makes this powerful: fold works for a large set of the types I use day-to-day, whether they're from the base library or specific to my own codebase. There is only a handful of other generic operations that rely on the Monoid class, but that's enough to make the class quite useful. It's a simple abstraction that applies to a lot of different types. I actually did a count recently; something like 30% of our modules import Data.Monoid. Many of them were just using the (<>) operator, but that's useful in and of itself: no need to define a distinct operator for each of our types that wants one. It's a simple, incredibly general abstraction that pulls its weight—partly because it doesn't have much to pull.

mbrock 9y ago

The cool thing about algebra is that it lets you reuse concepts and computations between elementary arithmetic and a wide range of abstract or complex structures. It's probably true that most programs use only very simple monoids, but look at e.g. this article to see how composition of monoids can be a very powerful design pattern in functional programming. http://repository.upenn.edu/cgi/viewcontent.cgi?article=1773&context=cis_papers http://repository.upenn.edu/cgi/viewcontent.cgi?article=1773...

rbehrends 9y ago
And the article introduces a whole lot more concepts, such as homomorphisms in order to be sufficiently interesting. I don't say that you can't build interesting stuff on top of monoids (I have several colleagues that are doing just that), just that the concept of a monoid by itself isn't very interesting or deep.
- mbrock 9y ago
  Sure. It's funny with these algebraic things. If they're simple, people complain that they're not interesting... but when you add some depth, people complain that it's too difficult!
  - tome 9y ago
    "I don't want to have to understand abstract algebra to use Haskell!" "Abstract algebra is too simple to bother writing programming blogs about!"
    - dllthomas 9y ago
      To be fair, it may not be the same people.
      - tome 9y ago
        I'm sure it's not! But even so it's interesting to be caught between these two antipodes. As your probably know there's another group of people, Andrej Bauer among them, who provide a different antithesis to "I don't want to have to understand category theory to use Haskell!" by exclaiming "Haskell doesn't use real category theory!". It's just generally quite amusing to be caught in the middle of all this.
- runeks 9y ago
  The goal of programming is to reduce all parts to such simplicity that they become boringly simple, and thus impossible to get wrong. Concepts are only interesting while we don’t fully understand them yet; when we’re done fully understanding them, they become boring and we move on to the next thing. Thus, the solution to programming is to compose programs out of boringly simple parts, using a boringly simple method of composition.
  - rbehrends 9y ago
    And how do monoids play into this? This is just a vague generality; unless you can show exactly what more complex programming concepts you can reduce to monoids and how that helps with understanding programming, that doesn't mean much.
  - kbenson 9y ago
    > The goal of programming is to reduce all parts to such simplicity that they become boringly simple, and thus impossible to get wrong. No, that's a strategy to achieve a goal of programming. Programming is about using machines that accept well defined instructions to automate processes for people. A complex and poorly understood program that still ends up reducing the overall amount of work required for individuals is still worthwhile, even if not reduced to being boringly simple.
    - lou1306 9y ago
      The main selling point is that reduction and "boring simplicity" can lead to a formally correct program, or at least one where most errors are caught by static analysis/type checking/etc.
      - kbenson 9y ago
        I'm not saying it's not worth while, I'm just saying that it's not the goal (in general. Some academic exercises might have goals such as that because the point is to learn). It's sort of like saying the goal of owning a store is to match inventory to sales as closely as possible. That's a strategy or sub-goal towards reaching the real goal at best, which is to make enough money that the store pays for itself and hopefully supports the owner. Some stores don't even have inventory, so that strategy doesn't even apply to them. Similarly, that programming strategy may not apply well to some problems (and some problems cannot be proven formally correct, at least in whole). My original reply was really just meant to point out that what they viewed as the goal of programming, is really just one of many competing strategies for producing software, and many others don't care about that at all.

coldtea 9y ago

>The problem with this argument is that a monoid is one of the most basic constructs you can find in abstract algebra. That's irrelevant, because we are not naming them to use them in abstract algebra, but as abstract constructs in a different domain with its own complexity (programming).

rbehrends 9y ago
The lack of complexity comes from the fact that monoids are just defined by two simple axioms. Using them in a different domain does not change that. Associativity or having a neutral element do not become more complicated concepts in computer science.
- coldtea 9y ago
  >The lack of complexity comes from the fact that monoids are just defined by two simple axioms. Using them in a different domain does not change that. You'd be surprised. A pointer (as in C) is an even simpler notion, but the complexity it represents to new programmers is big. Complexity in a programming element from the interplay it has with everything else -- not from it isolated.
  - rbehrends 9y ago
    The original argument was that naming them "monoids" reduces cognitive load. Can you explain how exactly you see this reduction in cognitive load coming to pass in programming? Because from your previous two responses, I don't see it. What aspects of associative operations with a neutral element are so central to teaching programming that naming such a construct "monoid" gives us a stepping stone towards better understanding programming?
    - tome 9y ago
      Which is easier to comprehend at a glance? * Under my Foo API you are able to combine Bars monoidally * Under my Foo API you are able to combine Bars using baz such that `baz (baz bar1 bar2) bar3 == baz bar1 (baz bar2 bar3)` for all `bar1, bar2, bar3 :: Bar`, and also `baz == Bar quux baz == Bar baz quux` for all `baz :: Bar`.

tikhonj 9y ago

The real advantage is that we can express the abstraction in the language, which lets us write libraries around it. A single function like fold is much nicer than either having one per type or having to pass in the operation and identity manually: fold :: (Monoid m, Foldable t) => t m -> m The fact that monoids are so simple is actually what makes this powerful: fold works for a large set of the types I use day-to-day, whether they're from the base library or specific to my own codebase. There is only a handful of other generic operations that rely on the Monoid class, but that's enough to make the class quite useful. It's a simple abstraction that applies to a lot of different types. I actually did a count recently; something like 30% of our modules import Data.Monoid. Many of them were just using the (<>) operator, but that's useful in and of itself: no need to define a distinct operator for each of our types that wants one. It's a simple, incredibly general abstraction that pulls its weight—partly because it doesn't have much to pull.