7 ms·

> the people who designed Haskell decided they weren’t going to pretend they didn’t use math This is almost certainly the decision that has kept the most peopl

> the people who designed Haskell decided they weren’t going to pretend they didn’t use math This is almost certainly the decision that has kept the most people from successfully learning Haskell. If you write "Appendable", many programmers go "oh, okay, got it." If you write "Monoid", many programmers go "yeeeah, I don't know if I have time to learn all this." This is either a perfectly acceptable cost of avoiding redefining the wheel, or a cautionary tale for future language developers, depending on your perspective.

anaphor 13y ago
It's not really Appendable though, because e.g. you can write a Monoid instance for various number-y things like Sum and Product.
- srl 13y ago
  And you could write an Appendable instance for them as well, it would just fly in the face of what the word "append" means to most people. (Nitpick, of course.)
  - dllthomas 13y ago
    Sure, but is that more understandable than using "monoid"?
    - chilldream 13y ago
      Don't know enough to know that the current name is optimal, but at least "Monoid" correctly says to the initiated "you don't understand this yet." "Appendable" lies to you and says "you understand this" even if you don't.
      - dllthomas 13y ago
        "Monoid" also has the advantage of being very searchable. First result on Google (from a private browser window) is the Wikipedia page with the snippet "In abstract algebra, a branch of mathematics, a monoid is an algebraic structure with a single associative binary operation and an identity element". DDG gives similar results, though the Doctor Who aliens are higher up...
    - lmm 13y ago
      Yes. If I've got used to the idea that lists are appendable and then someone tells me I can "append" two numbers by adding them and that will fit the interface... yeah, that makes sense. It might be a bit confusing on the way, but better to use a term that covers the most common case than a term that's completely alien.
cscheid 13y ago
But "Appendable" is a terrible way to describe what a monoid is. Some of the really cool tricks in the way abstractions in Haskell match mathematical notions come from extending the abstractions beyond what you would expect. For example, integers under sum are monoids; naturals under the maximum operation too. And so is the "over" operator from computer graphics. All of these find applicability as general monoids in Haskell, but you'd have a hard time calling them "Appendable". All of these just need a binary operation that's associative and with an identity element. The same thing happens for functors and monads: their use come from the properties they respect. And if you accept that abstractions will be defined as a set, some operations, and some algebraic laws respected by those operations, well, then, you arrived at abstract algebra, and you might as well use the right terms.
- yohanatan 13y ago
  I think Combinable is more appropriate as 'append' pertains to only one of many associative binary operations.
  - cscheid 13y ago
    What about a group? Is that combinable too? Monoid is short, precise, and googlable. Which also happens to be the case with group, monad, functor, etc. Why invent new vocabulary? Have you noticed how little sense the words "class", "struct", "union", "object" make to someone who hasn't programmed before? It's just that we got used to them.
    - lmm 13y ago
      Classes, unions and objects are all everyday words. I knew them from mathematics and everyday life before I ever used them in programming.
  - dllthomas 13y ago
    AssociativeCombinableWithIdentity ... but I would rather learn what a "monoid" is, than type that out every time.
  - 13y ago
yongjik 13y ago
Kinda off-topic, but I also have to say "appendable" is a terrible choice. It would mean that those objects (or variables, or whatever) support efficient appending operation, which is usually not the case. (Sorry, I couldn't get over the fact that appending a character to a string (or a list) is O(N) operation in Haskell.) Now, if you named them "prependable", then maybe...
- dllthomas 13y ago
  "Max 3 <> Max 5" isn't really appending or prepending, though.
codeflo 13y ago
I also think that there's a clash of naming conventions going on. Programmers are used to name types for their values are, as in "4 is an Int", or even abstractly, "4 is Serializable". Haskell conforms to this convention with type and class names like "Int", "String", or "Num". But classes with names like Monoid don't conform to that, as 4 is not "a Monoid". The set of integers with + is a monoid, but that's a property of the type itself, not of its values. (Edit: And don't get me started about "IO". What's "an IO" even supposed to be?)
- Chattered 13y ago
  And similarly, the list [1,2,3,4] is not a monad, and that's why "flatmappable" isn't a sensible alternative to "monad", as Bracha recently suggested. Though some have argued that this confusion indicates a hole in our vocabulary: http://blog.plover.com/prog/haskell/monad-terminology.html http://blog.plover.com/prog/haskell/monad-terminology.html
  - codeflo 13y ago
    Great link, that's about what I'm getting at. MJD states it more clearly than I could.
- nbouscal 13y ago
  You noted a pattern in how programmers name types, and then complain that the naming of a type class doesn't conform to that pattern. Of course 4 isn't a Monoid, rather, Sum is a Monoid. As for IO, the best way to read it would be as an "IO action", which is what much of the literature refers to it as. Yes, this isn't trivial to understand, but IO in Haskell isn't trivial, and you can avoid the formalism if needed until once you understand things a bit better.
  - codeflo 13y ago
    I'm fine with Haskell using a different convention if there actually is one. And your other explanation proves my point: If an "IO" instance is best described as an "IO Action", then why is the type not called "IOAction"?
Perseids 13y ago
And maybe it is a tale promoting more theoretical computer science in the education of programmers. For example monoids should be familiar because the states of a minimal DFAs are essentially the elements of the syntactic monoid [1] of the accepted language and the transition function is essentially the monoid operation. [1] https://en.wikipedia.org/wiki/Syntactic_monoid https://en.wikipedia.org/wiki/Syntactic_monoid
- deleted 13y ago
  [deleted]
chongli 13y ago
The problem with analogies is that they only work in one direction on the abstract<->concrete spectrum. It's perfectly fine to talk about lists under the append operation as an example of a monoid. It makes no sense whatsoever to try to reverse that relationship because not all monoids have anything remotely analogous to appending. This principle applies to pretty much all ways of categorizing objects. We can say that dogs are an example of mammals but to turn around and call all mammals "doglikes" or "doggables" would be silly.
runT1ME 13y ago
Appendable is more akin to a semi-group than a monoid though, no?
- rtfeldman 13y ago
  Yes, but the point stands. :)
- dllthomas 13y ago
  Yes, "appendable" to me doesn't imply the existence of an identity.
Dewie 13y ago
If this is all it takes to turn people away, then I would say that the problem is that those people have an irrational fear of mathematics. At that level, it's not about having a tool that is too abstract or difficult, or not being gifted at abstract thinking; it's about those people having a conditioned knee-jerk reaction to math-sounding things. Mathematics is hard, at least for me, but I have accepted that I have to get over my preconceived notions and at least try to look beyond the jargon. And these are mere names, not "let's cook up an ad-hoc notation and heavily overload and abuse it in places because 'the meaning is obvious from the context'...". this is only a question about choosing name A, or name B. I can't imagine it will get any harder by choosing either of them. At least Haskell clearly states, with it's esoteric naming; "what you are about to get into is quite strange, and quite different from anything you've probably encountered in programming before." And if they can't look beyond scary-sounding words, maybe that kind of programming is not for them - and in that case, it's good that they found out straight away - or maybe they need to work on their own phobias.

anaphor 13y ago

It's not really Appendable though, because e.g. you can write a Monoid instance for various number-y things like Sum and Product.

srl 13y ago
And you could write an Appendable instance for them as well, it would just fly in the face of what the word "append" means to most people. (Nitpick, of course.)
- dllthomas 13y ago
  Sure, but is that more understandable than using "monoid"?
  - chilldream 13y ago
    Don't know enough to know that the current name is optimal, but at least "Monoid" correctly says to the initiated "you don't understand this yet." "Appendable" lies to you and says "you understand this" even if you don't.
    - dllthomas 13y ago
      "Monoid" also has the advantage of being very searchable. First result on Google (from a private browser window) is the Wikipedia page with the snippet "In abstract algebra, a branch of mathematics, a monoid is an algebraic structure with a single associative binary operation and an identity element". DDG gives similar results, though the Doctor Who aliens are higher up...
  - lmm 13y ago
    Yes. If I've got used to the idea that lists are appendable and then someone tells me I can "append" two numbers by adding them and that will fit the interface... yeah, that makes sense. It might be a bit confusing on the way, but better to use a term that covers the most common case than a term that's completely alien.

cscheid 13y ago

But "Appendable" is a terrible way to describe what a monoid is. Some of the really cool tricks in the way abstractions in Haskell match mathematical notions come from extending the abstractions beyond what you would expect. For example, integers under sum are monoids; naturals under the maximum operation too. And so is the "over" operator from computer graphics. All of these find applicability as general monoids in Haskell, but you'd have a hard time calling them "Appendable". All of these just need a binary operation that's associative and with an identity element. The same thing happens for functors and monads: their use come from the properties they respect. And if you accept that abstractions will be defined as a set, some operations, and some algebraic laws respected by those operations, well, then, you arrived at abstract algebra, and you might as well use the right terms.

yohanatan 13y ago
I think Combinable is more appropriate as 'append' pertains to only one of many associative binary operations.
- cscheid 13y ago
  What about a group? Is that combinable too? Monoid is short, precise, and googlable. Which also happens to be the case with group, monad, functor, etc. Why invent new vocabulary? Have you noticed how little sense the words "class", "struct", "union", "object" make to someone who hasn't programmed before? It's just that we got used to them.
  - lmm 13y ago
    Classes, unions and objects are all everyday words. I knew them from mathematics and everyday life before I ever used them in programming.
- dllthomas 13y ago
  AssociativeCombinableWithIdentity ... but I would rather learn what a "monoid" is, than type that out every time.
- 13y ago

yongjik 13y ago

Kinda off-topic, but I also have to say "appendable" is a terrible choice. It would mean that those objects (or variables, or whatever) support efficient appending operation, which is usually not the case. (Sorry, I couldn't get over the fact that appending a character to a string (or a list) is O(N) operation in Haskell.) Now, if you named them "prependable", then maybe...

dllthomas 13y ago
"Max 3 <> Max 5" isn't really appending or prepending, though.

codeflo 13y ago

I also think that there's a clash of naming conventions going on. Programmers are used to name types for their values are, as in "4 is an Int", or even abstractly, "4 is Serializable". Haskell conforms to this convention with type and class names like "Int", "String", or "Num". But classes with names like Monoid don't conform to that, as 4 is not "a Monoid". The set of integers with + is a monoid, but that's a property of the type itself, not of its values. (Edit: And don't get me started about "IO". What's "an IO" even supposed to be?)

Chattered 13y ago
And similarly, the list [1,2,3,4] is not a monad, and that's why "flatmappable" isn't a sensible alternative to "monad", as Bracha recently suggested. Though some have argued that this confusion indicates a hole in our vocabulary: http://blog.plover.com/prog/haskell/monad-terminology.html http://blog.plover.com/prog/haskell/monad-terminology.html
- codeflo 13y ago
  Great link, that's about what I'm getting at. MJD states it more clearly than I could.
nbouscal 13y ago
You noted a pattern in how programmers name types, and then complain that the naming of a type class doesn't conform to that pattern. Of course 4 isn't a Monoid, rather, Sum is a Monoid. As for IO, the best way to read it would be as an "IO action", which is what much of the literature refers to it as. Yes, this isn't trivial to understand, but IO in Haskell isn't trivial, and you can avoid the formalism if needed until once you understand things a bit better.
- codeflo 13y ago
  I'm fine with Haskell using a different convention if there actually is one. And your other explanation proves my point: If an "IO" instance is best described as an "IO Action", then why is the type not called "IOAction"?

Perseids 13y ago

And maybe it is a tale promoting more theoretical computer science in the education of programmers. For example monoids should be familiar because the states of a minimal DFAs are essentially the elements of the syntactic monoid [1] of the accepted language and the transition function is essentially the monoid operation. [1] https://en.wikipedia.org/wiki/Syntactic_monoid https://en.wikipedia.org/wiki/Syntactic_monoid

deleted 13y ago
[deleted]

chongli 13y ago

The problem with analogies is that they only work in one direction on the abstract<->concrete spectrum. It's perfectly fine to talk about lists under the append operation as an example of a monoid. It makes no sense whatsoever to try to reverse that relationship because not all monoids have anything remotely analogous to appending. This principle applies to pretty much all ways of categorizing objects. We can say that dogs are an example of mammals but to turn around and call all mammals "doglikes" or "doggables" would be silly.

runT1ME 13y ago

Appendable is more akin to a semi-group than a monoid though, no?

rtfeldman 13y ago
Yes, but the point stands. :)
dllthomas 13y ago
Yes, "appendable" to me doesn't imply the existence of an identity.

Dewie 13y ago

If this is all it takes to turn people away, then I would say that the problem is that those people have an irrational fear of mathematics. At that level, it's not about having a tool that is too abstract or difficult, or not being gifted at abstract thinking; it's about those people having a conditioned knee-jerk reaction to math-sounding things. Mathematics is hard, at least for me, but I have accepted that I have to get over my preconceived notions and at least try to look beyond the jargon. And these are mere names, not "let's cook up an ad-hoc notation and heavily overload and abuse it in places because 'the meaning is obvious from the context'...". this is only a question about choosing name A, or name B. I can't imagine it will get any harder by choosing either of them. At least Haskell clearly states, with it's esoteric naming; "what you are about to get into is quite strange, and quite different from anything you've probably encountered in programming before." And if they can't look beyond scary-sounding words, maybe that kind of programming is not for them - and in that case, it's good that they found out straight away - or maybe they need to work on their own phobias.