Hacker News Reader

"Addable" will not actually be more informative than "Monoid", to someone who doesn't know "Monoid".

"Monoid" will be very informative to anyone who learned it from mathematics.

A "Monoid" is a type which supports an associative operation (`m -> m -> m`) and a neutral element (`m`) which forms its identity element.

"Addable" suggests it is an "addition". Does this mean it is commutative? For the sake of preciseness, I'd hope so! (Monoids aren't commutative). Does this mean it has a negation? No. So it is not "addition", why use a misleading name for the sake of some false sense of "intuition"?

The actual explanation of what a Monoid is precisely is so short and simple, it makes no sense to try to appeal to inaccurate intuitions.

That's a completely valid point of view. You're not wrong at all. I'm guessing, though, that you had learned it before from mathematics. My point is one of pragmatic, not theoretical, distinction. To those without a mathematical background (most people are not going to learn monoid unless they've studied abstract algebra), or who are less interested in mathematics in general, an obscure term like that is discouraging. I know that the Haskell community is heavily mathematical, and have little interest in "dumbing down" the language for the sake of those who are put off by theory, but it is a real tradeoff and one of the things that is likely to impede the introduction of Haskell into the mainstream.

I've learned Monoid in Haskell, not maths. It's just so simple and easy that there's really no dumbing down necessary.

Monad is simple and hard, but Monoid is simple and easy.

With respect to monoid, you're right. It's really quite simple when you get down to it. I don't have any arguments there. In fact, the fact that monoids are really so simple is kind of my point. In almost any other language, were such a thing to exist, monoids would not be called monoids but by some descriptive term which conveyed an intuitive sense of their meaning and use; it would be the purview of the mathematically inclined to write articles explaining how "actually, what we call the Joinable type class is known in abstract algebra as a Monoid, and its use extends beyond just joining things; for example..."

My point isn't really specifically about monoids; they're just an example of what often goes on in Haskell, which is that people put theory before practicality and mathematical (and hence often esoteric) definitions before practical, real-world definitions. Like I've said a few times, this isn't incorrect at all. Nor is it surprising given Haskell's origins, nor is it without purpose since it deepens your understanding of what's going on in the language. It's just a simple fact that the mathematical jargon is a turn-off to newcomers and those who don't feel they want to be forced to learn math while they're programming, or might think they're incapable of doing so.

As it turns out, I'm not one of those people; I love the mathematical side of Haskell and I love that I've learned what a Monoid is and developed an interest in type theory, category theory and all kinds of other things. But not everyone is like that, and that's the point I'm making.

>In almost any other language, were such a thing to exist, monoids would not be called monoids but by some descriptive term which conveyed an intuitive sense of their meaning and use

There is no such term, that is the point. Offering up misleading terms that do not convey a sense of their meaning is much worse than a word that is unfamiliar.

>My point isn't really specifically about monoids; they're just an example of what often goes on in Haskell, which is that people put theory before practicality and mathematical (and hence often esoteric) definitions before practical, real-world definitions.

But it isn't an example of that. It is quite bizarre to see people insist that this goes on, and give examples that do not support that claim, while being fully convinced in their proof.

>As it turns out, I'm not one of those people; I love the mathematical side of Haskell and I love that I've learned what a Monoid is and developed an interest in type theory, category theory and all kinds of other things. But not everyone is like that, and that's the point I'm making.

You don't need to be like that, that is the point we're making. I am not a math person. I am not a CS person. I am a high school drop out who taught himself to code in PHP and C. I learned haskell just fine. I learned monoids and functors and monads just fine. I am no more mathematically inclined now than I was before. I know nothing of category theory, and care nothing of it. They are very general abstractions that do not reflect a narrow, specific use case, and thus do not benefit from a word that describes some narrow, specific use case.

Well, yeah, but... the term "monoid" already exists, and has a definite meaning. A different name might give people an intuition for it--but it will be a wrong one that they'll have to unlearn later, like the infamous burrito (not that you or anyone has suggested that monads be renamed burritos, I am happy to say!).

We must have different ideas about what "practicality" is.

I hate to say this sort of, because it is going to sound snobby, and I do not believe in being snobby. But the undeniable truth is, there's a fraction of the world's population of programmers who simply do not have the particular mental traits that would allow them to ever be completely comfortable and confident with a concept as abstract as monad.

Some people will call me Satan now, and others will jump on what I said and say, "Hell yeah, the world is full of dumb blub programmers." But both those groups are misunderstanding me.

I think a programmer who cannot understand this level of abstraction can still do plenty of valuable things as a programmer. I would not call them dumb. They may be -- and many are -- fabulously creative, driven, capable and highly productive.

There's a certain type of programmer who is more comfortable with abstraction and whose brain is more wired to deal with these amorphous, unnamed concepts. The same kind of brain wiring is needed to go far with mathematics.

But as FP becomes more prominent, this is going to become a dividing issue. Some will not make the transition, or will do so only partially. I think it's great to try to communicate better where possible, but even the best communication is not going to completely erase the issue.

Isaac Asimov, in one of his essays, gave an analogy for those unfamiliar with, or perhaps frightened by the scary name of, the "complex" numbers: street addresses. Should programming languages get rid of that scary name and refer to complex numbers as "addressable"?

Hence why Monads have been named "Warm Fuzzy Things" in some Haskell papers about outreach.

> explaining it further as "something with an identity and an associative operation" really doesn't help much either

My 3rd grade daughter learns about associativity and identity. Is it too much to expect adults to not get all defensive over 3rd grade terminology?

What is so scary about monoid? A classical monoid is precisely a category with one object, hence the name. "Addable" and "Joinable" do not quite cut it - not all monoids are defined on numbers (or generalizations of them such as vectors or matrices) or sets (or generalizations of them such as categories or topological spaces).

Like I said, it's a scary term, because hearing the word "monoid" conveys exactly zilch about what it is, and it sounds strange and abstract. And like I said, the definition I gave is not a precise one, but it's an intuitive one. Once you have an intuitive understanding as a starting point, you can abstract to other things.

This is just my opinion, of course.

Hearing the word "dog" conveys exactly zilch about what it is, and it sounds strange and abstract. Maybe we should call these animals "barkables".

Except that it doesn't sound strange and abstract, because it's a word that everyone is familiar with. My point is about accessibility, not theoretical correctness.

My point is that a monoid is a monoid. It's an abstraction that's so basic that it cannot be broken down. It's a concept that you learn, like how you learn what a dog is or what integers, loops, functions, sets, hashmaps, etc are.

A very large part of our job is to apply abstractions. I don't often hear lawyers complaining about how accessible the name of some law is, or from doctors about how accessible the name of some disease is. I've never heard an American football player say "We should call the pistol formation something else. Calling it pistol is potentially confusing". They just learn what a pistol formation is and carry on.

As programmers, abstraction is a very large part of our job. We owe it to ourselves to learn the basics and to improve our abilities with respect to our craft, even though sometimes it's hard.

Most of what you learn in CS is a bunch of words you have no idea what they mean until someone gives you a precise definition. Deterministic Finite Automata, regular expression, static typing, serialization, compilation, singleton pattern, etc. are all terms we use every day in our profession, but it's not clear what they mean. But we read the definition, forget it, someone reminds us, we forget it again, we implement it and we remember. Same with monoids, functors or monads, we need to take some time to learn what they mean and then we can include them in our vocabulary.

Welcome to engineering. We use specialized jargon to talk about concepts that laymen might not find obvious, but are indispensable for us to get our work done.

I think some people should at least try to get over their math-phobia. I am trying to myself, and math is an uphill battle for me even without that kind of fear. The sloppy, opaque, inconsistent and often overloaded notation is an impediment, the 'let the reader infer most of this' proofs are an impediment... but if people are turned off to such a degree over a few names, they wouldn't last long in something which is such a mathy language anyway, relatable names or not.

You are using the exact reasoning I was talking about. Monoids are monoids. That is what they are. 99% of programmers are not familiar with them. If you call it "addable" or "joinable" or "appendable" then you are just making people think that one subset of some monoids is the definition of monoids when it isn't. They still don't know what monoids are, now they just also don't know what they are called. You are literally giving it an incorrect and misleading name. All that does is confuse people. You have to learn what monoids actually are even if you call them "addable"s. Rather than learning a misleading name for them, it is quite simple to learn a new term like "monoid". Considering there is really only 3 that people need to learn (monoid, functor, monad) this is not an overwhelming burden.

Check yourself before you try to say that "appendable" is an inappropriate name for Monoid.

http://hackage.haskell.org/package/base-4.6.0.1/docs/Data-Mo...

    Methods
      mempty 
      mappend
      mconcat

Haskell people like their mathy terms. Mathy terms aren't universally unambigious ("group"? "ring"? "field"?), but they are mostly unambiguous within math. Haskell people tend to pretend Haskell is the same as math, ignoring the programming part of its heritage.

probably because 'mappend' was defined while thinking about usage for lists, but is hardly appropriate for the general case. So, 'Appending' 5 to 3 gives 8; it could be better.

The choices are to either abuse an existing word, or make up new one (possibly a homograph).

What is '+' ? Addition? Modular addition? Logical OR? Concatenaton? Sometimes, any of these.

There where always be more concepts than distinct labels, since the space of concept is exponential combination (power set) of words.

I didn't say it had to be plus.

I don't have the perfect answer, but append certainly seems like choosing a specific concept , rather than trying to come up with a more general name.

In practical Haskell people rarely use mappend eschewing it for the more generic (<>) operator. Personally I think it's exactly for the reason stated above—monoid is far more general than "appending".

In particular, it's easy to define a reverse monoid for any (non-commutative) monoid such that append becomes prepend. It's easy to construct monoids which have different spacial properties like Diagrams' "stacking" monoid (they have many others, too, see this entire paper http://www.cis.upenn.edu/~byorgey/pub/monoid-pearl.pdf). It's also easy to construct monoids which don't have any spatial sense at all like set union.

Everyone hates the name mappend but it's still more commonly used than <> which iirc is relatively recent.

For the record, I agree. There's a lot of older code where `mappend` is used commonly. More accurately, I should have said that (<>) has taken modern coding style by storm.

I am fully aware of what the typeclass defines. It is an inappropriate name. I don't think there is anyone who likes those names. Everyone uses <> instead of mappened. Append is inappropriate because you do not append lots of monoids, like Product and Sum for example.