9 ms·

It's always amusing to watch programmers learn a tiny piece of mathematics and turn into a totem. All those data structures would work just as fine without a mo

by dkural 9y ago

It's always amusing to watch programmers learn a tiny piece of mathematics and turn into a totem. All those data structures would work just as fine without a monoid formalization, and one can use all their power with no attention given to algebraic axioms that define a monoid.

tw1010 9y ago
You don't need to give names to things, but often it's useful. It can reduce cognitive load (if you're comfortable with the terminology) and it can be useful when communicating to other engineers. Mathematicians did their thing without symbols (only words) a few hundred years ago, but once everyone agrees to use them you can start worrying about higher-order problems.
- rbehrends 9y ago
  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.
  - 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.
- dkural 9y ago
  I think it increases the cognitive load. These things already have names. A Monoid is an abstract category that doesn't 1-1 correspond to the particulars of each data structure, increasing overall cognitive load. It's not like I'm going to forget how sets work otherwise. I'm a mathematician. I like category theory. Mathematicians in fact strive for the right level of generality. I've never seen an algorithmic or programming challenge where thinking of something as a monoid helped me solve it better.
  - tw1010 9y ago
    I only think it is useful once you're comfortable with it. Before you are you are probably better off using whatever mental intuition you already have about the idea. Personally I consider it useful to associate the concept to the idea of distributed systems (together with other concepts like commutativity). Having this association can help guide me towards either common appropriate ways of solving problems in that space, or as a good search-phrase to include when I google for algorithms.
  - nimih 9y ago
    In contrast, I, personally, have run into programming/design problems where monoids or semigroups seemed to be the correct level of abstraction to work at. People aren't appropriating language and concepts from algebra/category theory for no reason (well, perhaps some are), they're doing so because they find them to be useful tools when building and thinking about systems.
    - romwell 9y ago
      Please provide examples of such problems, because TFA is lacking in those.
- skybrian 9y ago
  Of course we invent new words all the time, but the downside to using specialized jargon is that many people won't understand you. Many good writers will intentionally avoid obscure vocabulary to reach a larger audience. This is a judgment to be made on a case-by-case basis. For example, when writing programs, I don't think the word "monoid" is useful enough to be worth explaining, so I would avoid using it in API's or documentation and see if I can get the point across in some clearer way.
whipoodle 9y ago
Right, like one of the examples is summing two amounts of money. As far as I know, that's just adding integers if you're doing it right. It's not clear what all the formalisms are bringing to the table there.
- jstimpfle 9y ago
  I agree. But in some cases it might be nice to omit an explicit 0 or use some higher order combinator that is ergonomic just because it expects a monoid instance to be already prepared.
  - whipoodle 9y ago
    So they make things a bit nicer, sometimes. Alrighty then.
    - tome 9y ago
      Amongst the things they do is that they sometimes make things a bit nicer in a completely generic way which is reusable across many problem domains.
- tome 9y ago
  If you know that amounts of money are a monoid under addition then you know that sum (map sum xs) == sum (concat xs) And there starts a whole slew of possible optimizations, including MapReduce. See, for example, https://userpages.uni-koblenz.de/~laemmel/MapReduce/paper.pdf https://userpages.uni-koblenz.de/~laemmel/MapReduce/paper.pd...
  - whipoodle 9y ago
    I don't really know what you are trying to say.
    - deleted 9y ago
      [deleted]
platz 9y ago
Similarly, All those GoF patterns would work just as fine without a pattern formalization, and one can use all their power with no attention given to the common pattern that all instances share.
- jstimpfle 9y ago
  When recruiters / interviewers ask me whether I know "Design Patterns" I shy away. It's sort of a red flag. I could just say "Singleton" and package them a cat in an object and the interview would go on. I've recently preferred to be reluctant about this and just tell them I really don't like these words (OOD / Design Patterns)... One interview was over really quick, while at another place, I've actually signed now. Any thoughts?
  - mbrock 9y ago
    Hit them back with a question about how they conceive the difference between design patterns as a general concept and methodology stemming from Alexander's work in collaborative architecture, and the one specific GoF pattern language for OO coding that accidentally took over the whole meme.
    - jstimpfle 9y ago
      Link? I mean, I can't tell which Alexander you mean.
      - Jtsummers 9y ago
        https://en.wikipedia.org/wiki/Christopher_Alexander https://en.wikipedia.org/wiki/Christopher_Alexander
      - mbrock 9y ago
        Sorry, Christopher Alexander, who wrote the book called "A Pattern Language" (and several others) which was the origin of the inspiration for design patterns in coding. He also later wrote a foreword for a book by Richard P. Gabriel, "Patterns of Software", with this gem of a quote: (the book itself I really recommend for anyone interested in design patterns) ... In my life as an architect, I find that the single thing which inhibits young professionals, new students most severely, is their acceptance of standards that are too low. If I ask a student whether her design is as good as Chartres, she often smiles tolerantly at me as if to say, “Of course not, that isn’t what I am trying to do. . . . I could never do that.” Then, I express my disagreement, and tell her: “That standard must be our standard. If you are going to be a builder, no other standard is worthwhile. That is what I expect of myself in my own buildings, and it is what I expect of my students.” Gradually, I show the students that they have a right to ask this of themselves, and must ask this of themselves. Once that level of standard is in their minds, they will be able to figure out, for themselves, how to do better, how to make something that is as profound as that. Two things emanate from this changed standard. First, the work becomes more fun. It is deeper, it never gets tiresome or boring, because one can never really attain this standard. One’s work becomes a lifelong work, and one keeps trying and trying. So it becomes very fulfilling, to live in the light of a goal like this. But secondly, it does change what people are trying to do. It takes away from them the everyday, lower-level aspiration that is purely technical in nature, (and which we have come to accept) and replaces it with something deep, which will make a real difference to all of us that inhabit the earth. I would like, in the spirit of Richard Gabriel’s searching questions, to ask the same of the software people who read this book. But at once I run into a problem. For a programmer, what is a comparable goal? What is the Chartres of programming? What task is at a high enough level to inspire people writing programs, to reach for the stars? Can you write a computer program on the same level as Fermat’s last theorem? Can you write a program which has the enabling power of Dr. Johnson’s dictionary? Can you write a program which has the productive power of Watt’s steam engine? Can you write a program which overcomes the gulf between the technical culture of our civilization, and which inserts itself into our human life as deeply as Eliot’s poems of the wasteland or Virginia Woolf’s "The Waves"?
gbacon 9y ago
You’re right that there’s not much to monoids. Though much hay has been made about monads, they barely rate having a name either, and you’d be surprised if they didn’t work the way they do. That being said, they are useful abstractions and in Haskell, for example, open up all of Control.Monad[0] and Data.Monoid[1] to your code for free. [0]: https://hackage.haskell.org/package/base-4.10.0.0/docs/Control-Monad.html https://hackage.haskell.org/package/base-4.10.0.0/docs/Contr... [1]: https://hackage.haskell.org/package/base-4.10.0.0/docs/Data-Monoid.html https://hackage.haskell.org/package/base-4.10.0.0/docs/Data-...
coldtea 9y ago
>All those data structures would work just as fine without a monoid formalization That was has happening in the last 50+ years. >and one can use all their power with no attention given to algebraic axioms that define a monoid. Not really. When you can actually identify a pattern, and treat different instances of the same phenomenon as a single concept, you get much more power over simple using those individual instances as different cases. It's the very reason why we create and use abstractions.
- dkural 9y ago
  Yes, I know that as a mathematician. Imagine you are a military strategist. And some engineer says, you know what all our tanks, rifles, and missiles have in common? They are all WEAPONS satisfying a few simple formal properties!
  - coldtea 9y ago
    Well, the military has its own share of "simplistic" abstractions exactly like that, that are nonetheless extremely useful to its operations.
    - mcphage 9y ago
      Good ol' "Rock or something"
  - jpfed 9y ago
    And then you start wondering whether there are other kinds of weapons you could be exploring, and hey, turns out that's pretty useful.
    - romwell 9y ago
      That's absolutely how it would go, and of course, the generals would never think of exploring weapons without the engineer enlightening them.
      - 9y ago
KirinDave 9y ago
Not if you're constraining yourself to parametric polymorphism. In that case the mzero property is pretty significant and comes up a lot. There's this whole discussion about "theorems for free" and why these formalisms are quite useful and relevant to languages like Haskell.
chowells 9y ago
It's always baffling to watch programmers learn something new and immediately reject it as useless. When did the search for knowledge and better ways to think about code become a reason to mock someone? Any decent programming language will let you write code that uses an abstraction, limiting your interaction with some of its input values to only operations defined in the abstraction. Then the question becomes "how interesting is this abstraction free of concrete details?" It turns out monoids allow you to write general code that gives you incredible flexibility when you later choose a concrete instance of the abstraction to work in. See http://www.soi.city.ac.uk/~ross/papers/FingerTree.html http://www.soi.city.ac.uk/~ross/papers/FingerTree.html for an example of how you can specialize a general data structure to do a number of specific functions based on a choice of monoid. The best abstractions are the ones that introduce a lot of flexibility based on choices that code doesn't depend on. A lot of the deepest abstractions in that sense come from math. This isn't an accident. Math is about searching for good abstractions. When one of them is found to be applicable to programming, that should be celebrated. Don't mock the ones who are celebrating.
- romwell 9y ago
  Well, the article certainly doesn't give one enough to chew on to celebrate. I don't at all get what the hype is about from this article, the concept of "you can combine two things and get a thing" isn't novel or radical. I get a feeling that the kicker is about associativity, which is to say "when combining a bunch of things in a row, you can combine them any way as long as you only combine the adjacent ones". The kicker being that if you have that, you can parallelize. So, seeing associativity allows one to identify parallelizable problems.
  - nullren 9y ago
    it's weird how the article neglected that at all. maybe it was assumed to be obvious? I've given brownbags about monoids and they were all focused on parallelization. things like summingbird were good examples i've used.
- dkural 9y ago
  Ah. "Flexibility." This is a much deeper debate, but through my subjective experience programming for two decades, stand-alone as PhD, and also leading a 200-person engineering team, I thing flexibility is by and large the last thing to optimize for, and almost always a sign of a novice engineer. You don't know the future. You don't know what will work with the end users of your software, or where your research will take you. The best thing you can do is to accomplish the task in front of you in the simplest, most directly performant way possible, and put it to use - in front of customers, or in doing your research. True flexibility is not having to wait for every iteration so engineers can program in every iteration of the future. There is a huge cost you pay today for 'flexibility', most things advertised as such are not in fact flexible, and the trend in designing complex real world systems is in fact for each project to do exactly ONE thing and do it very well. Btw you're assuming I've rejected algebra, and I've done so immediately. I have no objections to using abstract algebra or category theory in designing and thinking about programming languages, and none of my opinions are a jerk-reaction to anything.

by dkural 9y ago

tw1010 9y ago

You don't need to give names to things, but often it's useful. It can reduce cognitive load (if you're comfortable with the terminology) and it can be useful when communicating to other engineers. Mathematicians did their thing without symbols (only words) a few hundred years ago, but once everyone agrees to use them you can start worrying about higher-order problems.

rbehrends 9y ago
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.
- 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.
dkural 9y ago
I think it increases the cognitive load. These things already have names. A Monoid is an abstract category that doesn't 1-1 correspond to the particulars of each data structure, increasing overall cognitive load. It's not like I'm going to forget how sets work otherwise. I'm a mathematician. I like category theory. Mathematicians in fact strive for the right level of generality. I've never seen an algorithmic or programming challenge where thinking of something as a monoid helped me solve it better.
- tw1010 9y ago
  I only think it is useful once you're comfortable with it. Before you are you are probably better off using whatever mental intuition you already have about the idea. Personally I consider it useful to associate the concept to the idea of distributed systems (together with other concepts like commutativity). Having this association can help guide me towards either common appropriate ways of solving problems in that space, or as a good search-phrase to include when I google for algorithms.
- nimih 9y ago
  In contrast, I, personally, have run into programming/design problems where monoids or semigroups seemed to be the correct level of abstraction to work at. People aren't appropriating language and concepts from algebra/category theory for no reason (well, perhaps some are), they're doing so because they find them to be useful tools when building and thinking about systems.
  - romwell 9y ago
    Please provide examples of such problems, because TFA is lacking in those.
skybrian 9y ago
Of course we invent new words all the time, but the downside to using specialized jargon is that many people won't understand you. Many good writers will intentionally avoid obscure vocabulary to reach a larger audience. This is a judgment to be made on a case-by-case basis. For example, when writing programs, I don't think the word "monoid" is useful enough to be worth explaining, so I would avoid using it in API's or documentation and see if I can get the point across in some clearer way.

whipoodle 9y ago

Right, like one of the examples is summing two amounts of money. As far as I know, that's just adding integers if you're doing it right. It's not clear what all the formalisms are bringing to the table there.

jstimpfle 9y ago
I agree. But in some cases it might be nice to omit an explicit 0 or use some higher order combinator that is ergonomic just because it expects a monoid instance to be already prepared.
- whipoodle 9y ago
  So they make things a bit nicer, sometimes. Alrighty then.
  - tome 9y ago
    Amongst the things they do is that they sometimes make things a bit nicer in a completely generic way which is reusable across many problem domains.
tome 9y ago
If you know that amounts of money are a monoid under addition then you know that sum (map sum xs) == sum (concat xs) And there starts a whole slew of possible optimizations, including MapReduce. See, for example, https://userpages.uni-koblenz.de/~laemmel/MapReduce/paper.pdf https://userpages.uni-koblenz.de/~laemmel/MapReduce/paper.pd...
- whipoodle 9y ago
  I don't really know what you are trying to say.
  - deleted 9y ago
    [deleted]

platz 9y ago

Similarly, All those GoF patterns would work just as fine without a pattern formalization, and one can use all their power with no attention given to the common pattern that all instances share.

jstimpfle 9y ago
When recruiters / interviewers ask me whether I know "Design Patterns" I shy away. It's sort of a red flag. I could just say "Singleton" and package them a cat in an object and the interview would go on. I've recently preferred to be reluctant about this and just tell them I really don't like these words (OOD / Design Patterns)... One interview was over really quick, while at another place, I've actually signed now. Any thoughts?
- mbrock 9y ago
  Hit them back with a question about how they conceive the difference between design patterns as a general concept and methodology stemming from Alexander's work in collaborative architecture, and the one specific GoF pattern language for OO coding that accidentally took over the whole meme.
  - jstimpfle 9y ago
    Link? I mean, I can't tell which Alexander you mean.
    - Jtsummers 9y ago
      https://en.wikipedia.org/wiki/Christopher_Alexander https://en.wikipedia.org/wiki/Christopher_Alexander
    - mbrock 9y ago
      Sorry, Christopher Alexander, who wrote the book called "A Pattern Language" (and several others) which was the origin of the inspiration for design patterns in coding. He also later wrote a foreword for a book by Richard P. Gabriel, "Patterns of Software", with this gem of a quote: (the book itself I really recommend for anyone interested in design patterns) ... In my life as an architect, I find that the single thing which inhibits young professionals, new students most severely, is their acceptance of standards that are too low. If I ask a student whether her design is as good as Chartres, she often smiles tolerantly at me as if to say, “Of course not, that isn’t what I am trying to do. . . . I could never do that.” Then, I express my disagreement, and tell her: “That standard must be our standard. If you are going to be a builder, no other standard is worthwhile. That is what I expect of myself in my own buildings, and it is what I expect of my students.” Gradually, I show the students that they have a right to ask this of themselves, and must ask this of themselves. Once that level of standard is in their minds, they will be able to figure out, for themselves, how to do better, how to make something that is as profound as that. Two things emanate from this changed standard. First, the work becomes more fun. It is deeper, it never gets tiresome or boring, because one can never really attain this standard. One’s work becomes a lifelong work, and one keeps trying and trying. So it becomes very fulfilling, to live in the light of a goal like this. But secondly, it does change what people are trying to do. It takes away from them the everyday, lower-level aspiration that is purely technical in nature, (and which we have come to accept) and replaces it with something deep, which will make a real difference to all of us that inhabit the earth. I would like, in the spirit of Richard Gabriel’s searching questions, to ask the same of the software people who read this book. But at once I run into a problem. For a programmer, what is a comparable goal? What is the Chartres of programming? What task is at a high enough level to inspire people writing programs, to reach for the stars? Can you write a computer program on the same level as Fermat’s last theorem? Can you write a program which has the enabling power of Dr. Johnson’s dictionary? Can you write a program which has the productive power of Watt’s steam engine? Can you write a program which overcomes the gulf between the technical culture of our civilization, and which inserts itself into our human life as deeply as Eliot’s poems of the wasteland or Virginia Woolf’s "The Waves"?

gbacon 9y ago

You’re right that there’s not much to monoids. Though much hay has been made about monads, they barely rate having a name either, and you’d be surprised if they didn’t work the way they do. That being said, they are useful abstractions and in Haskell, for example, open up all of Control.Monad[0] and Data.Monoid[1] to your code for free. [0]: https://hackage.haskell.org/package/base-4.10.0.0/docs/Control-Monad.html https://hackage.haskell.org/package/base-4.10.0.0/docs/Contr... [1]: https://hackage.haskell.org/package/base-4.10.0.0/docs/Data-Monoid.html https://hackage.haskell.org/package/base-4.10.0.0/docs/Data-...

coldtea 9y ago

>All those data structures would work just as fine without a monoid formalization That was has happening in the last 50+ years. >and one can use all their power with no attention given to algebraic axioms that define a monoid. Not really. When you can actually identify a pattern, and treat different instances of the same phenomenon as a single concept, you get much more power over simple using those individual instances as different cases. It's the very reason why we create and use abstractions.

dkural 9y ago
Yes, I know that as a mathematician. Imagine you are a military strategist. And some engineer says, you know what all our tanks, rifles, and missiles have in common? They are all WEAPONS satisfying a few simple formal properties!
- coldtea 9y ago
  Well, the military has its own share of "simplistic" abstractions exactly like that, that are nonetheless extremely useful to its operations.
  - mcphage 9y ago
    Good ol' "Rock or something"
- jpfed 9y ago
  And then you start wondering whether there are other kinds of weapons you could be exploring, and hey, turns out that's pretty useful.
  - romwell 9y ago
    That's absolutely how it would go, and of course, the generals would never think of exploring weapons without the engineer enlightening them.
    - 9y ago

KirinDave 9y ago

Not if you're constraining yourself to parametric polymorphism. In that case the mzero property is pretty significant and comes up a lot. There's this whole discussion about "theorems for free" and why these formalisms are quite useful and relevant to languages like Haskell.

chowells 9y ago

It's always baffling to watch programmers learn something new and immediately reject it as useless. When did the search for knowledge and better ways to think about code become a reason to mock someone? Any decent programming language will let you write code that uses an abstraction, limiting your interaction with some of its input values to only operations defined in the abstraction. Then the question becomes "how interesting is this abstraction free of concrete details?" It turns out monoids allow you to write general code that gives you incredible flexibility when you later choose a concrete instance of the abstraction to work in. See http://www.soi.city.ac.uk/~ross/papers/FingerTree.html http://www.soi.city.ac.uk/~ross/papers/FingerTree.html for an example of how you can specialize a general data structure to do a number of specific functions based on a choice of monoid. The best abstractions are the ones that introduce a lot of flexibility based on choices that code doesn't depend on. A lot of the deepest abstractions in that sense come from math. This isn't an accident. Math is about searching for good abstractions. When one of them is found to be applicable to programming, that should be celebrated. Don't mock the ones who are celebrating.

romwell 9y ago
Well, the article certainly doesn't give one enough to chew on to celebrate. I don't at all get what the hype is about from this article, the concept of "you can combine two things and get a thing" isn't novel or radical. I get a feeling that the kicker is about associativity, which is to say "when combining a bunch of things in a row, you can combine them any way as long as you only combine the adjacent ones". The kicker being that if you have that, you can parallelize. So, seeing associativity allows one to identify parallelizable problems.
- nullren 9y ago
  it's weird how the article neglected that at all. maybe it was assumed to be obvious? I've given brownbags about monoids and they were all focused on parallelization. things like summingbird were good examples i've used.
dkural 9y ago
Ah. "Flexibility." This is a much deeper debate, but through my subjective experience programming for two decades, stand-alone as PhD, and also leading a 200-person engineering team, I thing flexibility is by and large the last thing to optimize for, and almost always a sign of a novice engineer. You don't know the future. You don't know what will work with the end users of your software, or where your research will take you. The best thing you can do is to accomplish the task in front of you in the simplest, most directly performant way possible, and put it to use - in front of customers, or in doing your research. True flexibility is not having to wait for every iteration so engineers can program in every iteration of the future. There is a huge cost you pay today for 'flexibility', most things advertised as such are not in fact flexible, and the trend in designing complex real world systems is in fact for each project to do exactly ONE thing and do it very well. Btw you're assuming I've rejected algebra, and I've done so immediately. I have no objections to using abstract algebra or category theory in designing and thinking about programming languages, and none of my opinions are a jerk-reaction to anything.