8 ms·

Names do not transmit meaning

51 points by dmit 7y ago

WillDaSilva 7y ago
Naming things is one of the hardest problems in programming. No matter how much experience I get, I still run into problems where I can't think of a decent name for something on a regular basis.
- dmit 7y ago
  Some thoughts on the matter: 1) Are there domains where naming things is easier? Perhaps even trivial? As a layman in both, biology and astronomy come to mind. Where you just find a Latin word vaguely describing what you see, and if nothing comes up you just pick a name of a famous person from your field that doesn't already have something named after them. 2) If non-English languages are also considered, are there any where naming things is easier? Have to keep in mind that a "good" name maintains a balance between descriptiveness and brevity. 3) Can this be considered as an advantage of point-free style? 4) Is naming things in programming hard as in "building a spaceship" or as in "making the NBA"? That is, can you name all the things if you put in enough effort, or are some things simply unnameable?
  - falsedan 7y ago
    Naming is hard because communicating is hard: you have to build a mental model in the mind of the future programmer that’s useful enough to allow them to work on the project and get stuff done reasonably quickly and not accidentally break something due to a misunderstanding. I see a lot of people struggle with naming because they’re trying to materialise the ‘right’ name, when all you really need is one that’s good enough, unlikely to be misinterpreted, easy to find/look up docs, etc.
  - maoeurk 7y ago
    > If non-English languages are also considered, are there any where naming things is easier? Have to keep in mind that a "good" name maintains a balance between descriptiveness and brevity. As a native English speaker with a relatively very weak understanding of Chinese, I find Chinese names to be generally understandable and English names to be completely opaque. This is most pronounced when dealing with technical topics: For example, because I know essentially no Latin or Greek, a name like "Bilirubin" means absolutely nothing to me. Whereas the Chinese word, 膽紅素 (膽 - gall bladder, 紅 - red, 素 - essence), is actually something I can break down and have any idea at all what it is. Japanese is also generally better than English in this regard in my experience, but unfortunately it often borrows words from other languages. In this case, ビリルビン (birirubin), so it can be even more opaque than English. In the case of "functor", I also find the Chinese (函子) more obvious than the Japanese (関手) or English.
    - diegoperini 7y ago
      > In the case of "functor", I also find the Chinese (函子) more obvious than the Japanese (関手) or English. If not too much to ask, can you please explain how those non-latin characters form the meaning for the word "functor"? In my native tongue (Turkish), we borrow the word "functor" without applying a translation to it, thus it becomes one of those things you simply memorize and move on. Do these Chinese and Japanese words form a meaning similar to something like "function-izer" or "function+abler" or something else?
      - lioeters 7y ago
        I attempted to dig into the meaning of the Japanese word for functor, 関手. https://ja.wikipedia.org/wiki/%E9%96%A2%E6%89%8B https://ja.wikipedia.org/wiki/%E9%96%A2%E6%89%8B 関 - Checkpoint or barrier, for example at customs and borders; "bolt" for closing a door; to relate. (https://kanji.jitenon.jp/kanji/463.html https://kanji.jitenon.jp/kanji/463.html) 手 - Hand, method, to do something "by oneself" as in by own's own hands. (https://kanji.jitenon.jp/kanji/033.html https://kanji.jitenon.jp/kanji/033.html) So roughly/possibly "a method of relating". "Function" in Japanese is 関数. Same first character as functor, and the second one means "number". It's also written as 函数, which comes from the Chinese word for it. In the Chinese word for functor, 函子, the second character means "child".
      - dwohnitmok 7y ago
        函子 should probably be analyzed as an abbreviation of "函数" (function) + "子" ("essence of" or "atomic unit of"). This meaning of "子" is the predominant one when used in technical contexts. See molecule "分子" （unit of separation） atom "原子" (the original/fundamental unit) electron "电子" (unit of electricity) or monad "单子" (essence/unit of oneness) where the second character is third tone not neutral. Many of these originate in Japanese and are re-borrowed back into Chinese, but that's a story for another time. A sibling comment points out that 子 can mean child. This is the original, ancient meaning of the character. This usage is still productive in modern Chinese (usually to mean sons), but the previous examples are examples of how the meaning has undergone some transformations to form derived, related meanings. The original meaning can also be found in technical contexts. Examples of this are 子集 (child + set = subset) and again 分子 (fraction + child = numerator) with the counterpart 分母 (fraction + mother = denominator). This is not how I scan functor 函子 though. In the Chinese programming community, you'll usually just see the English words "Functor" and "Monad" used. I wouldn't be surprised if some Chinese programmers familiar with "Functor" do not recognize "函子." I've only ever seen 函子 used in math articles and occasional FP tutorials (and even then, given how dominant English is, it is often glossed by "Functor").
guerrilla 7y ago
I like the article but I disagree: Mappable is the correct name in this case and does transmit the meaning which is contained in the "grammatical" expansion. The confusion here is that there are prerequisites to knowing what Mappable means. One should know what map, the more primitive concept, means first. This is how derivational morphemes work. The productive suffixes still remaining in the English language such as "-able" do in fact have meanings, as do verbs such as "map", and they combine to form new meanings. Furthermore, a bunch of things being named terribly doesn't support the thesis that names don't transmit meaning. It supports the thesis that a bunch of people failed to communicate and they should have put much more effort into naming things accurately. > Names don’t make them any easier or harder to understand If we renamed every variable in Firefox, for example, with numbers, people would find it more difficult to understand, so this is an absurd thing to say. The reason we use names is because they do convey meaning. That meaning (index into our conceptual map) is what differentiates them from the numerical value of the string of letters which make up their textual representations and makes them so much easier to remember and understand contextually!
- dllthomas 7y ago
  The thing the article misses that I personally like about Haskell's drawing interface names from math is that it makes the edges sharper. There's more room for argument about whether something is "really Mappable" then whether something is "really a Functor", and more room to be uncertain about what guarantees I have in using the interface.
  - guerrilla 7y ago
    Something is Mappable in Haskell when it instantiates the class and satisfies the necessary and sufficient conditions it is obligated to by informal yet explicit contract of the class. That is to say that definitions are what guarantee validity, not connotational semantics.
    - dllthomas 7y ago
      This misses the social component, which I think is pretty important. Why isn't Set a Functor? Because it doesn't obey the functor laws (because a == b doesn't imply f a == f b). Why are those the functor laws? Because that's all that Functor means. Why isn't Set a Mappable? Because it doesn't obey the Mappable laws. Why are those the Mappable laws? Because they're the Functor laws? Why should that be the case? Maybe we should pick (or have picked) different laws for Mappable? Maybe we'll find better laws for Mappable, but we've given up that rarefied connotative linguistic real estate. There's extra room for drama and bike-shedding that isn't present when we're using already established names that precisely describe the interface even if they happen to be unfamiliar.
ta1234567890 7y ago
> Names can’t transmit meaning Sure, if you completely ignore context. However, context is very important and is what we use to get meaning from a name. Read this name: Donald Trump Does it not have meaning?
ACow_Adonis 7y ago
Names clearly CAN transmit meaning once a context and a vocabulary are a given, to quote Leslie Nielsen, isn't that right mr-poopy-pants? Even five year olds know this, and for some reason math- educated-types (look, i did it again!) are especially against combining symbolic representation AND semantic content in the same symbolic medium, even though the lesson from programming is that even though it can be hard, when it's done well, it's infinitely superior for humans to actually use in practice. In defense of Haskell however, author does have a point. Names for abstractions and anything you cannot touch and hold and easily categorise as a human in everyday life are really hard because current English is almost void of good words that capture or describe these concepts. Map and reduce, as two examples he rightly points out, are no more meaningful to most people than any other name we could give, and the only reason we think they are or might be is when we come from a context that has already learnt them. The same could be said for add, minus, subtraction, division, if they weren't essentially universally taught in universal education. Who knows, maybe in the future, when abstract programming becomes widely taught, maybe words and concepts around abstract operations will enter the mainstream language. Although, as a controversial counter-proposal to that (which I am merely putting forth, not necessarily advocating, i admit ignorance in this regard) if it turns out that various levels of abstract thought are not universally learnable by humanity, which is to say, are there thoughts and concepts some/most people can't think, then such words and vocabulary will always be an 'elitist' language... /random thoughts
xaedes 7y ago
Names are one part of a two-part code. The name transmits meaning to people with enough knowledge of the other part. Liken them to other analogies using other names can help build up the required knowledge
k__ 7y ago
It's probably just a quesion of what you are used to. OOP terminology feels more "Software Engineer"-y to me and FP terminology feels more "Math"-y. So OOP feels more at home and FP feels more foreign. On the other hand, in OCaml feels at home and Haskell/PureScript feels very theory-heavy.
ex3xu 7y ago
> Names can’t transmit meaning, and so a name shouldn’t be judged on how well it transmits meaning. That doesn’t mean that names can’t be judged at all - there are good and bad aspects to names. Names can't transmit the complete meaning of a concept, but they can still transmit a partial or ballpark representation of that concept. In the world of linguistics it's easy to see how many names come from the composition of Greek or Latin roots, prefixes and suffixes, or Chinese composition of radicals. I don't find it particularly compelling to try to make the case that names cannot transmit ANY meaning at all -- therefore let's choose some other arbitrary criteria for judging names. If you think about the concept of affordances/signifiers from HCI and interaction design, people do draw upon their past experience when encountering new, unknown concepts, and in the PL space a good name can streamline the process for learning a new concept. It's just that Functor has affordances from category theory and, well, most people haven't taken enough advanced math to access those affordances before encountering Functor. I think Matt would have been better off calling this article "New Concepts Deserve New Names", rather than try to say that all names transmit no meaning whatsoever. I think I would agree that it's not a huge price to develop new affordances for Functor, Applicative, Monad, Semigroup, and Monoid, in comparison to the potential pitfalls of choosing a name that points to a potentially vague or incorrect meaning. And I personally like the names because although they were poor pointers to meaning, they were good pointers to their mathematical roots, and that makes me curious to learn more category theory.
- mdip 7y ago
  Names can't transmit the complete meaning of a concept Exactly. It seems the author is stuck in a sort of "precision trap", where in their ideal world, there would be no ambiguity in names and when I referred to a foobaz, I'd be pointed only at a foobaz as it relates to xyzzy, and not ... I'm running out of silly variables. Names are the first point that you often encounter a subject. Arguably, it's more important that a name be more familiar at the expense of precision. As the developer becomes more familiar with the concept, they'll understand, for instance, that "Select" in C# is for converting one object to another, and "Where" is for limiting the results. Sure, at first glance, one might think "Select" is for filtering, but the release of LINQ coincided with language features centered around reducing the need to write SQL, so the name "Select" and "Where" were used rather than "Map" and "Filter" because they correlated directly to keywords in SQL. I'd argue both that "Familiarity is the reason names are chosen" and that in the context of software development, choosing familiar names that easily transfer to a concept that is "good enough" has greater value than picking an obscure, but precise word.
duffmancd 7y ago
I think one of the best counterexamples is The Jabberwocky by Lewis Carroll. If names (and more generally English words) conveyed no meaning on their own and were simply keys in a large fuzzy hash table, the poem would be completely opaque. However, despite the fact that almost every word in it is made-up (new, never a be foreseen keys), I'd argue that most English speakers, after reading the poem, would have a reasonably common understanding of what "slithy" meant or what a "borogrove" was. If names fit well with what a person already knows, they can aid memory and even impart understanding. If names are poorly chosen they can instead confuse.
- dmit 7y ago
  Even more impressively, the poem is also sometimes used (untranslated) in classes teaching English as a second language. So you don't need to be a native speaker to intuit the intended meaning.
astanway 7y ago
Saul Kripke built an entire career on what exactly names are, as covered in Naming and Necessity (https://en.wikipedia.org/wiki/Naming_and_Necessity https://en.wikipedia.org/wiki/Naming_and_Necessity), building on earlier work by Frege (https://en.wikipedia.org/wiki/Sense_and_reference https://en.wikipedia.org/wiki/Sense_and_reference). OP touches on some concepts they cover - it's definitely worth reading these two if you are interested in the philosophy behind names!
eveningcoffee 7y ago
Functor is a good enough name. Much better than for example quark from particle physics with its colors. Mappable is definitely better in one specific context but contrary to the author I think that Iterable may be even better as it is a more generic name (Iterable can be also Foldable). Or does Mappable mean that you will mutate the state? But why not refer to multiple names? Functor also known as Mappable or Iterable?
- mdip 7y ago
  Honestly, I think Mappable and Iterable are both fine. Are they perfect? Maybe to one or two developers who's past experience precisely matched up. They're "good enough" because the reason we tend to name things the way that we do is because (1) we're trying to help the developer create/learn/form a mental model of the concept we're introducing and (2) we're providing experienced developers with a name that, when context is provided, allows for quick recall of the details of what was learned. A word that is very unusual (Monoid and Monad come to mind in that -- for me -- there wasn't a part of that word that conveyed meaning), might as well be a "magic number". I have to remember the concept, and this odd word that I'm only ever going to see in the context of this concept. That's OK when it's infrequent or when the concept is so far off from anything else that it necessitates a new word (Internet)[0]. Had they chosen the word "Mappable" over "Functor", it would be unimportant that in "language X" a Mappable is a Functor and in "language Y" it's something similar, but not exactly the same. Hell, even distant similarities (like Visitor pattern or Map) are useful. To remember what "map", in JavaScript did, I thought "C# 'Select'", since I had used that more frequently, but I also remembered that "thing X maps to thing Y", or "A map gets me provides a way for me to get from location A to location B". I can explain most of that with the word "map" and they have a quick way to remember it. I don't have an easy way to do that with functor. I don't even have a terribly good way to do that with the word "function". When I tell my kids to "Open the door" when they knock, I'm referring to the door they knocked on, not the front door, the garage door, or the sliding back patio door. They're all wildly different concepts for "door" but I can refer to each of them as a "door" with either implied (as-in the nearest door to where I'm standing) or by providing additional explicit context (the "back" door is enough for everyone who has visited my home, thus far, to understand that I'm referring to the sliding-glass patio door). [0] Note that I'm not referring to business names or names for people. They serve different purposes.
mdip 7y ago
I really didn't have much of an opinion on the subject but after reading this, I'm finding that the author effectively demonstrated why Functor, Monoid, Monad and most of the terms used in FP are terrible and why it's so hard to get people to explore pure functional languages. This is the opposite of what the author intended, but I was unable to find anything other than evidence against the argument the author was trying to make. The author's central point and most of the arguments they make, throughout, prove the opposite of what they're trying to argue. The purpose of a name is a pointer The author then goes on to use this statement as though they had actually said "The only purpose" or "the primary purpose". Context, here, is really, really important. The purpose of a person's name is an attempt to be a unique pointer to a person. From there we twist in to how ineffective the way we name things is at being a unique pointer. But how unique of a pointer does a name have to be? If that was the primary, only or main focus, our language would reflect that. I wouldn't tell the kids to "open the door" when I'm in the bedroom, I'd tell them to "turn the kwikset lever handle on the master bedroom door". Or I'd use the fancy name for the kind of door (it's got a french name of some kind) we have in our bedroom. In the first case, I'd be providing unnecessary information. In the second, my use of a unique name to describe a unique door in our home would land in this articles "nirvana", but my kids would stand there confused since they would not be familiar with the term. Names can't transmit *meaning* Of course they can! The author is more-or-less trying to make the argument that "names shouldn't convey meaning", but you don't get to control what your readers do with what you provide[0]. In fact, it's clear that the main goal that language authors place on naming things is specifically to convey meaning. The author's argument now becomes "Names regularly transmit meaning and often the meaning they transmit isn't as accurate as I'd like it to be". In fact, that an unfamiliar name was used for something where a more common, familiar term was available made understanding what a Functor was much more difficult. Had it been called Mappable, I would have been most of the way there[1]. Upon researching what a "Functor" was, I didn't trust any of the first several, simple, short answers because I assumed "if that's all it is, they wouldn't have used such an obscure name". So the very use of a name unfamiliar to me conveyed meaning that it must be a much more complicated topic, or they would have used a term that landed on the 80% mark. [0] Newspeak, aside. [1] I didn't actually struggle with Functor, but that was the author's chosen term to focus on. For me, I think it was Monoid and Monad. I had been using F# for two years before I actually looked up the exact definition of those two terms. Knowing what they meant was, evidently, not important but that they were named something unfamiliar to me didn't immediately make me explore what they meant.
phkahler 7y ago
>> I’m about to go on a bikepacking trip ... When I read that, I had never seen the word "bikepacking" before, but I think I've got a decent idea what it means. Words matter. Technical terms exist in a context and are not just arbitrary identifiers. If we called monoids broccoli and other concepts had other random words, programming would be harder. Not everything can get a great name, but we should try.
mantap 7y ago
In my humble opinion, Haskell uses big words and obscure category theory terminology for simple concepts in order to make Haskell programmers look smart. It's actually rather selfish because it reflects poorly on other FP languages, people start to think that all functional programming languages are about applicative functors and kleisli arrows.
deleted 7y ago
[deleted]
tomlockwood 7y ago
One of the funny things about "Monad" is that philosophers will probably come to it with a fairly rich concept of what a monad is, since it has been used since ancient Greece. https://en.wikipedia.org/wiki/Monad_(philosophy) https://en.wikipedia.org/wiki/Monad_(philosophy)
- openfuture 7y ago
  This is called Unit in the context which we are discussing. A monad is a different concept in this context.
james_s_tayler 7y ago
Isn't a Functor just a morphism from one category to another?

51 points by dmit 7y ago

Naming things is one of the hardest problems in programming. No matter how much experience I get, I still run into problems where I can't think of a decent name for something on a regular basis.

dmit 7y ago
Some thoughts on the matter: 1) Are there domains where naming things is easier? Perhaps even trivial? As a layman in both, biology and astronomy come to mind. Where you just find a Latin word vaguely describing what you see, and if nothing comes up you just pick a name of a famous person from your field that doesn't already have something named after them. 2) If non-English languages are also considered, are there any where naming things is easier? Have to keep in mind that a "good" name maintains a balance between descriptiveness and brevity. 3) Can this be considered as an advantage of point-free style? 4) Is naming things in programming hard as in "building a spaceship" or as in "making the NBA"? That is, can you name all the things if you put in enough effort, or are some things simply unnameable?
- falsedan 7y ago
  Naming is hard because communicating is hard: you have to build a mental model in the mind of the future programmer that’s useful enough to allow them to work on the project and get stuff done reasonably quickly and not accidentally break something due to a misunderstanding. I see a lot of people struggle with naming because they’re trying to materialise the ‘right’ name, when all you really need is one that’s good enough, unlikely to be misinterpreted, easy to find/look up docs, etc.
- maoeurk 7y ago
  > If non-English languages are also considered, are there any where naming things is easier? Have to keep in mind that a "good" name maintains a balance between descriptiveness and brevity. As a native English speaker with a relatively very weak understanding of Chinese, I find Chinese names to be generally understandable and English names to be completely opaque. This is most pronounced when dealing with technical topics: For example, because I know essentially no Latin or Greek, a name like "Bilirubin" means absolutely nothing to me. Whereas the Chinese word, 膽紅素 (膽 - gall bladder, 紅 - red, 素 - essence), is actually something I can break down and have any idea at all what it is. Japanese is also generally better than English in this regard in my experience, but unfortunately it often borrows words from other languages. In this case, ビリルビン (birirubin), so it can be even more opaque than English. In the case of "functor", I also find the Chinese (函子) more obvious than the Japanese (関手) or English.
  - diegoperini 7y ago
    > In the case of "functor", I also find the Chinese (函子) more obvious than the Japanese (関手) or English. If not too much to ask, can you please explain how those non-latin characters form the meaning for the word "functor"? In my native tongue (Turkish), we borrow the word "functor" without applying a translation to it, thus it becomes one of those things you simply memorize and move on. Do these Chinese and Japanese words form a meaning similar to something like "function-izer" or "function+abler" or something else?
    - lioeters 7y ago
      I attempted to dig into the meaning of the Japanese word for functor, 関手. https://ja.wikipedia.org/wiki/%E9%96%A2%E6%89%8B https://ja.wikipedia.org/wiki/%E9%96%A2%E6%89%8B 関 - Checkpoint or barrier, for example at customs and borders; "bolt" for closing a door; to relate. (https://kanji.jitenon.jp/kanji/463.html https://kanji.jitenon.jp/kanji/463.html) 手 - Hand, method, to do something "by oneself" as in by own's own hands. (https://kanji.jitenon.jp/kanji/033.html https://kanji.jitenon.jp/kanji/033.html) So roughly/possibly "a method of relating". "Function" in Japanese is 関数. Same first character as functor, and the second one means "number". It's also written as 函数, which comes from the Chinese word for it. In the Chinese word for functor, 函子, the second character means "child".
    - dwohnitmok 7y ago
      函子 should probably be analyzed as an abbreviation of "函数" (function) + "子" ("essence of" or "atomic unit of"). This meaning of "子" is the predominant one when used in technical contexts. See molecule "分子" （unit of separation） atom "原子" (the original/fundamental unit) electron "电子" (unit of electricity) or monad "单子" (essence/unit of oneness) where the second character is third tone not neutral. Many of these originate in Japanese and are re-borrowed back into Chinese, but that's a story for another time. A sibling comment points out that 子 can mean child. This is the original, ancient meaning of the character. This usage is still productive in modern Chinese (usually to mean sons), but the previous examples are examples of how the meaning has undergone some transformations to form derived, related meanings. The original meaning can also be found in technical contexts. Examples of this are 子集 (child + set = subset) and again 分子 (fraction + child = numerator) with the counterpart 分母 (fraction + mother = denominator). This is not how I scan functor 函子 though. In the Chinese programming community, you'll usually just see the English words "Functor" and "Monad" used. I wouldn't be surprised if some Chinese programmers familiar with "Functor" do not recognize "函子." I've only ever seen 函子 used in math articles and occasional FP tutorials (and even then, given how dominant English is, it is often glossed by "Functor").

guerrilla 7y ago

I like the article but I disagree: Mappable is the correct name in this case and does transmit the meaning which is contained in the "grammatical" expansion. The confusion here is that there are prerequisites to knowing what Mappable means. One should know what map, the more primitive concept, means first. This is how derivational morphemes work. The productive suffixes still remaining in the English language such as "-able" do in fact have meanings, as do verbs such as "map", and they combine to form new meanings. Furthermore, a bunch of things being named terribly doesn't support the thesis that names don't transmit meaning. It supports the thesis that a bunch of people failed to communicate and they should have put much more effort into naming things accurately. > Names don’t make them any easier or harder to understand If we renamed every variable in Firefox, for example, with numbers, people would find it more difficult to understand, so this is an absurd thing to say. The reason we use names is because they do convey meaning. That meaning (index into our conceptual map) is what differentiates them from the numerical value of the string of letters which make up their textual representations and makes them so much easier to remember and understand contextually!

dllthomas 7y ago
The thing the article misses that I personally like about Haskell's drawing interface names from math is that it makes the edges sharper. There's more room for argument about whether something is "really Mappable" then whether something is "really a Functor", and more room to be uncertain about what guarantees I have in using the interface.
- guerrilla 7y ago
  Something is Mappable in Haskell when it instantiates the class and satisfies the necessary and sufficient conditions it is obligated to by informal yet explicit contract of the class. That is to say that definitions are what guarantee validity, not connotational semantics.
  - dllthomas 7y ago
    This misses the social component, which I think is pretty important. Why isn't Set a Functor? Because it doesn't obey the functor laws (because a == b doesn't imply f a == f b). Why are those the functor laws? Because that's all that Functor means. Why isn't Set a Mappable? Because it doesn't obey the Mappable laws. Why are those the Mappable laws? Because they're the Functor laws? Why should that be the case? Maybe we should pick (or have picked) different laws for Mappable? Maybe we'll find better laws for Mappable, but we've given up that rarefied connotative linguistic real estate. There's extra room for drama and bike-shedding that isn't present when we're using already established names that precisely describe the interface even if they happen to be unfamiliar.

ta1234567890 7y ago

> Names can’t transmit meaning Sure, if you completely ignore context. However, context is very important and is what we use to get meaning from a name. Read this name: Donald Trump Does it not have meaning?

ACow_Adonis 7y ago

Names clearly CAN transmit meaning once a context and a vocabulary are a given, to quote Leslie Nielsen, isn't that right mr-poopy-pants? Even five year olds know this, and for some reason math- educated-types (look, i did it again!) are especially against combining symbolic representation AND semantic content in the same symbolic medium, even though the lesson from programming is that even though it can be hard, when it's done well, it's infinitely superior for humans to actually use in practice. In defense of Haskell however, author does have a point. Names for abstractions and anything you cannot touch and hold and easily categorise as a human in everyday life are really hard because current English is almost void of good words that capture or describe these concepts. Map and reduce, as two examples he rightly points out, are no more meaningful to most people than any other name we could give, and the only reason we think they are or might be is when we come from a context that has already learnt them. The same could be said for add, minus, subtraction, division, if they weren't essentially universally taught in universal education. Who knows, maybe in the future, when abstract programming becomes widely taught, maybe words and concepts around abstract operations will enter the mainstream language. Although, as a controversial counter-proposal to that (which I am merely putting forth, not necessarily advocating, i admit ignorance in this regard) if it turns out that various levels of abstract thought are not universally learnable by humanity, which is to say, are there thoughts and concepts some/most people can't think, then such words and vocabulary will always be an 'elitist' language... /random thoughts

xaedes 7y ago

Names are one part of a two-part code. The name transmits meaning to people with enough knowledge of the other part. Liken them to other analogies using other names can help build up the required knowledge

k__ 7y ago

It's probably just a quesion of what you are used to. OOP terminology feels more "Software Engineer"-y to me and FP terminology feels more "Math"-y. So OOP feels more at home and FP feels more foreign. On the other hand, in OCaml feels at home and Haskell/PureScript feels very theory-heavy.

ex3xu 7y ago

> Names can’t transmit meaning, and so a name shouldn’t be judged on how well it transmits meaning. That doesn’t mean that names can’t be judged at all - there are good and bad aspects to names. Names can't transmit the complete meaning of a concept, but they can still transmit a partial or ballpark representation of that concept. In the world of linguistics it's easy to see how many names come from the composition of Greek or Latin roots, prefixes and suffixes, or Chinese composition of radicals. I don't find it particularly compelling to try to make the case that names cannot transmit ANY meaning at all -- therefore let's choose some other arbitrary criteria for judging names. If you think about the concept of affordances/signifiers from HCI and interaction design, people do draw upon their past experience when encountering new, unknown concepts, and in the PL space a good name can streamline the process for learning a new concept. It's just that Functor has affordances from category theory and, well, most people haven't taken enough advanced math to access those affordances before encountering Functor. I think Matt would have been better off calling this article "New Concepts Deserve New Names", rather than try to say that all names transmit no meaning whatsoever. I think I would agree that it's not a huge price to develop new affordances for Functor, Applicative, Monad, Semigroup, and Monoid, in comparison to the potential pitfalls of choosing a name that points to a potentially vague or incorrect meaning. And I personally like the names because although they were poor pointers to meaning, they were good pointers to their mathematical roots, and that makes me curious to learn more category theory.

mdip 7y ago
Names can't transmit the complete meaning of a concept Exactly. It seems the author is stuck in a sort of "precision trap", where in their ideal world, there would be no ambiguity in names and when I referred to a foobaz, I'd be pointed only at a foobaz as it relates to xyzzy, and not ... I'm running out of silly variables. Names are the first point that you often encounter a subject. Arguably, it's more important that a name be more familiar at the expense of precision. As the developer becomes more familiar with the concept, they'll understand, for instance, that "Select" in C# is for converting one object to another, and "Where" is for limiting the results. Sure, at first glance, one might think "Select" is for filtering, but the release of LINQ coincided with language features centered around reducing the need to write SQL, so the name "Select" and "Where" were used rather than "Map" and "Filter" because they correlated directly to keywords in SQL. I'd argue both that "Familiarity is the reason names are chosen" and that in the context of software development, choosing familiar names that easily transfer to a concept that is "good enough" has greater value than picking an obscure, but precise word.

duffmancd 7y ago

I think one of the best counterexamples is The Jabberwocky by Lewis Carroll. If names (and more generally English words) conveyed no meaning on their own and were simply keys in a large fuzzy hash table, the poem would be completely opaque. However, despite the fact that almost every word in it is made-up (new, never a be foreseen keys), I'd argue that most English speakers, after reading the poem, would have a reasonably common understanding of what "slithy" meant or what a "borogrove" was. If names fit well with what a person already knows, they can aid memory and even impart understanding. If names are poorly chosen they can instead confuse.

dmit 7y ago
Even more impressively, the poem is also sometimes used (untranslated) in classes teaching English as a second language. So you don't need to be a native speaker to intuit the intended meaning.

astanway 7y ago

Saul Kripke built an entire career on what exactly names are, as covered in Naming and Necessity (https://en.wikipedia.org/wiki/Naming_and_Necessity https://en.wikipedia.org/wiki/Naming_and_Necessity), building on earlier work by Frege (https://en.wikipedia.org/wiki/Sense_and_reference https://en.wikipedia.org/wiki/Sense_and_reference). OP touches on some concepts they cover - it's definitely worth reading these two if you are interested in the philosophy behind names!

eveningcoffee 7y ago

Functor is a good enough name. Much better than for example quark from particle physics with its colors. Mappable is definitely better in one specific context but contrary to the author I think that Iterable may be even better as it is a more generic name (Iterable can be also Foldable). Or does Mappable mean that you will mutate the state? But why not refer to multiple names? Functor also known as Mappable or Iterable?

mdip 7y ago
Honestly, I think Mappable and Iterable are both fine. Are they perfect? Maybe to one or two developers who's past experience precisely matched up. They're "good enough" because the reason we tend to name things the way that we do is because (1) we're trying to help the developer create/learn/form a mental model of the concept we're introducing and (2) we're providing experienced developers with a name that, when context is provided, allows for quick recall of the details of what was learned. A word that is very unusual (Monoid and Monad come to mind in that -- for me -- there wasn't a part of that word that conveyed meaning), might as well be a "magic number". I have to remember the concept, and this odd word that I'm only ever going to see in the context of this concept. That's OK when it's infrequent or when the concept is so far off from anything else that it necessitates a new word (Internet)[0]. Had they chosen the word "Mappable" over "Functor", it would be unimportant that in "language X" a Mappable is a Functor and in "language Y" it's something similar, but not exactly the same. Hell, even distant similarities (like Visitor pattern or Map) are useful. To remember what "map", in JavaScript did, I thought "C# 'Select'", since I had used that more frequently, but I also remembered that "thing X maps to thing Y", or "A map gets me provides a way for me to get from location A to location B". I can explain most of that with the word "map" and they have a quick way to remember it. I don't have an easy way to do that with functor. I don't even have a terribly good way to do that with the word "function". When I tell my kids to "Open the door" when they knock, I'm referring to the door they knocked on, not the front door, the garage door, or the sliding back patio door. They're all wildly different concepts for "door" but I can refer to each of them as a "door" with either implied (as-in the nearest door to where I'm standing) or by providing additional explicit context (the "back" door is enough for everyone who has visited my home, thus far, to understand that I'm referring to the sliding-glass patio door). [0] Note that I'm not referring to business names or names for people. They serve different purposes.

mdip 7y ago

I really didn't have much of an opinion on the subject but after reading this, I'm finding that the author effectively demonstrated why Functor, Monoid, Monad and most of the terms used in FP are terrible and why it's so hard to get people to explore pure functional languages. This is the opposite of what the author intended, but I was unable to find anything other than evidence against the argument the author was trying to make. The author's central point and most of the arguments they make, throughout, prove the opposite of what they're trying to argue. The purpose of a name is a pointer The author then goes on to use this statement as though they had actually said "The only purpose" or "the primary purpose". Context, here, is really, really important. The purpose of a person's name is an attempt to be a unique pointer to a person. From there we twist in to how ineffective the way we name things is at being a unique pointer. But how unique of a pointer does a name have to be? If that was the primary, only or main focus, our language would reflect that. I wouldn't tell the kids to "open the door" when I'm in the bedroom, I'd tell them to "turn the kwikset lever handle on the master bedroom door". Or I'd use the fancy name for the kind of door (it's got a french name of some kind) we have in our bedroom. In the first case, I'd be providing unnecessary information. In the second, my use of a unique name to describe a unique door in our home would land in this articles "nirvana", but my kids would stand there confused since they would not be familiar with the term. Names can't transmit *meaning* Of course they can! The author is more-or-less trying to make the argument that "names shouldn't convey meaning", but you don't get to control what your readers do with what you provide[0]. In fact, it's clear that the main goal that language authors place on naming things is specifically to convey meaning. The author's argument now becomes "Names regularly transmit meaning and often the meaning they transmit isn't as accurate as I'd like it to be". In fact, that an unfamiliar name was used for something where a more common, familiar term was available made understanding what a Functor was much more difficult. Had it been called Mappable, I would have been most of the way there[1]. Upon researching what a "Functor" was, I didn't trust any of the first several, simple, short answers because I assumed "if that's all it is, they wouldn't have used such an obscure name". So the very use of a name unfamiliar to me conveyed meaning that it must be a much more complicated topic, or they would have used a term that landed on the 80% mark. [0] Newspeak, aside. [1] I didn't actually struggle with Functor, but that was the author's chosen term to focus on. For me, I think it was Monoid and Monad. I had been using F# for two years before I actually looked up the exact definition of those two terms. Knowing what they meant was, evidently, not important but that they were named something unfamiliar to me didn't immediately make me explore what they meant.

phkahler 7y ago

>> I’m about to go on a bikepacking trip ... When I read that, I had never seen the word "bikepacking" before, but I think I've got a decent idea what it means. Words matter. Technical terms exist in a context and are not just arbitrary identifiers. If we called monoids broccoli and other concepts had other random words, programming would be harder. Not everything can get a great name, but we should try.

mantap 7y ago

In my humble opinion, Haskell uses big words and obscure category theory terminology for simple concepts in order to make Haskell programmers look smart. It's actually rather selfish because it reflects poorly on other FP languages, people start to think that all functional programming languages are about applicative functors and kleisli arrows.

deleted 7y ago

[deleted]

tomlockwood 7y ago

One of the funny things about "Monad" is that philosophers will probably come to it with a fairly rich concept of what a monad is, since it has been used since ancient Greece. https://en.wikipedia.org/wiki/Monad_(philosophy) https://en.wikipedia.org/wiki/Monad_(philosophy)

openfuture 7y ago
This is called Unit in the context which we are discussing. A monad is a different concept in this context.

james_s_tayler 7y ago

Isn't a Functor just a morphism from one category to another?