6 ms·

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. Th

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.
DonaldPShimoda 7y ago
I completely agree with your take on this. If you know what a "map" is in the CS context, "mappable" makes perfect sense. Names are absolutely critical to the synthesis of knowledge, as they provide a simple symbol by which to refer to complex concepts, which gives you greater power in wielding those concepts. --- Whenever the topic of names comes up, I reread one of my favorite blog posts I've ever come across: "What's in a Name" by Olin Shivers [0]. Here's the thesis statement: > [My thesis advisor, Allen] Newell [...] explained his understanding of names: “They provide distal access.” That is, a name is a local piece of data that stands for some other piece of data, which is presumably large and remote. You can now use that small, convenient, local datum instead of the large, remote thing for which it stands. (If, like me prior to reading this, you're unfamiliar with the word "distal", it means "Remote from the point of attachment or origin." [1]) [0] https://blog.janestreet.com/whats-in-a-name/ https://blog.janestreet.com/whats-in-a-name/ [1] https://en.wiktionary.org/wiki/distal#Adjective https://en.wiktionary.org/wiki/distal#Adjective
- sdrothrock 7y ago
  > Whenever the topic of names comes up, I reread one of my favorite blog posts I've ever come across: "What's in a Name" by Olin Shivers [0]. Thank you for this! It was a really engrossing read. > When he said “distal access,” he assumed that you, too, have structures on one side of your head representing what you know about, say, Neil Armstrong, and a smaller structure on the other side of your brain encoding the name “Neil Armstrong,” and cognitive mechanisms allowing you to fetch the former given the latter. I thought this was an interesting example that glossed over some (to me) really interesting things in cross-contextual (usually cultural?) miscommunication. This assumption that the other person you're talking to has the same concept in mind for a word is at the root of all communication we do. A simple example would just be UK to US English -- something as simple as "fanny," which has differing meanings to both populations. For a non-geographical contextual gap, we can look at slang like "salty." a "salty meal," "salty boy," and "salty dog" are all completely different things. Some of the biggest difficulties I run into with communication aren't with people who speak no English at all (I live in Japan), but people who speak English in a dialect(?) that's close to what I expect, but slightly different and used differently (e.g. as high context instead of low context). Sometimes I can be speaking with someone from India who has perfectly grammatically correct, fluent English, and suddenly be thrown for a loop when I realize that a word had a completely different meaning for both of us without either of us realizing it. It's just a really interesting concept I think about a lot since I do a lot of cross-cultural communication.
dmit 7y ago
In Scala a Set is "mappable" because it has a `map` method that goes over its elements and transforms them using the provided function. But it is not a functor, because its `map` does not obey the functor laws. If you take a Set of integers and pass an `isEven` function to `map` you will get a Set with a different structure (as long as there were originally at least two odd or two even numbers of course). `Mappable` provides short-term comfort due to familiarity, but to do so it sacrifices precision that is essential in the long term.
- guerrilla 7y ago
  > it sacrifices precision that is essential in the long term. Definitions are precise, not names. Names aren't what makes math work, it's the precise definitions, inference rules and theorems, regardless of the language in which they are written. 'printf' does not work the same in all programming language yet everyone knows what that name means.
- TJSomething 7y ago
  The very concept of functors was created to describe sets that did exactly that. The functor laws only require that there is an operator that can wrap a value from one category into the functor's target category, that mapping with the identity function is the same as the identity function, and that the results of composition of mapping with two functions is the same as the results of mapping with the composition of the two functions. Set fulfills these laws perfectly. There is no law for maintaining cardinality, because the functor laws don't care if cardinality is a concept that even makes sense for the target category in question.
- joshlemer 7y ago
  I am also really annoyed by how Set and Map's map methods work in Scala (and have argued about it here: https://contributors.scala-lang.org/t/set-map-deduping-and-possibly-unsafe-behavior/3436 https://contributors.scala-lang.org/t/set-map-deduping-and-p...), I actually don't think that for all the shortcomings of the Set map method, it actually violates any of the Functor laws: 1) For all sets s, s.map(identity) == s ==> true 2) For all sets s, functions f and g, s.map(x => f(g(x)) == s.map(g).map(f) ==> true On the other hand, Map's map method is much more horrible, and does violate the 2nd functor law where f == g == _.swap : Map(1 -> 2, 2 -> 2).map(_.swap).map(_.swap) ==> Map(2 -> 2) Map(1 -> 2, 2 -> 2).map(_.swap.swap) ==> Map(1 -> 2, 2 -> 2) Further, it behaves differently depending on if it is known to be a Map at compile-time, or if it is only known to be an Iterable[(K, V)], due to overloading: Map(1 -> 2, 2 -> 2).map(_.swap) ==> Map(2 -> 2) (Map(1 -> 2, 2 -> 2): Iterable[(Int, Int)]).map(_.swap) ==> List(2 -> 1, 2 -> 2)
ex3xu 7y ago
Open question: if Functor should be called Mappable, what would you call Applicative? EvenMoreMappable? Similarly, if Semigroup should be called Appendable, what would you call Monoid? And is there a consensus on Monad as well?
- guerrilla 7y ago
  As it is now, Applicative is really an applicative functor. In general, if a term covers a subset then there is a property which distinguishes the subset from its ambient set and we can use that property to qualify the term as being such. On the other hand, obviously Monad should be called Burrito.
empath75 7y ago
Right, names without context don’t have any meaning, but once you’re in the world of everyday workmanlike programming, mappable is a perfectly clear concept, where as functors as they are usually explained do not. If you were to take someone who is new to programming and talk about mappable datastructures they would look at you blankly, but any random JavaScript programmer should know what you mean instantly.
quickthrower2 7y ago
Interesting the name of the function you define in Haskell for a type to use the Functor typeclass is "fmap", so the core library designers must agree with you to some extent. I can forgive Haskell for using the word "functor" because it came from academic roots, it isn't a language like Go designed specifically to make things easy for programmers to pick up.
danharaj 7y ago
Why does Mappable mean "something that you can apply functions to" and not "something that you can apply as if it were a function"?
cryptonector 7y ago
+1. A portmanteau, a verbified noun, a nounified verb, and so on -- these "abuses" of language can help carry meaning in a way that random names cannot. That said, "functor" perhaps did sound to its originators like what "mappable" does to you (and me) now.

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.

DonaldPShimoda 7y ago

I completely agree with your take on this. If you know what a "map" is in the CS context, "mappable" makes perfect sense. Names are absolutely critical to the synthesis of knowledge, as they provide a simple symbol by which to refer to complex concepts, which gives you greater power in wielding those concepts. --- Whenever the topic of names comes up, I reread one of my favorite blog posts I've ever come across: "What's in a Name" by Olin Shivers [0]. Here's the thesis statement: > [My thesis advisor, Allen] Newell [...] explained his understanding of names: “They provide distal access.” That is, a name is a local piece of data that stands for some other piece of data, which is presumably large and remote. You can now use that small, convenient, local datum instead of the large, remote thing for which it stands. (If, like me prior to reading this, you're unfamiliar with the word "distal", it means "Remote from the point of attachment or origin." [1]) [0] https://blog.janestreet.com/whats-in-a-name/ https://blog.janestreet.com/whats-in-a-name/ [1] https://en.wiktionary.org/wiki/distal#Adjective https://en.wiktionary.org/wiki/distal#Adjective

sdrothrock 7y ago
> Whenever the topic of names comes up, I reread one of my favorite blog posts I've ever come across: "What's in a Name" by Olin Shivers [0]. Thank you for this! It was a really engrossing read. > When he said “distal access,” he assumed that you, too, have structures on one side of your head representing what you know about, say, Neil Armstrong, and a smaller structure on the other side of your brain encoding the name “Neil Armstrong,” and cognitive mechanisms allowing you to fetch the former given the latter. I thought this was an interesting example that glossed over some (to me) really interesting things in cross-contextual (usually cultural?) miscommunication. This assumption that the other person you're talking to has the same concept in mind for a word is at the root of all communication we do. A simple example would just be UK to US English -- something as simple as "fanny," which has differing meanings to both populations. For a non-geographical contextual gap, we can look at slang like "salty." a "salty meal," "salty boy," and "salty dog" are all completely different things. Some of the biggest difficulties I run into with communication aren't with people who speak no English at all (I live in Japan), but people who speak English in a dialect(?) that's close to what I expect, but slightly different and used differently (e.g. as high context instead of low context). Sometimes I can be speaking with someone from India who has perfectly grammatically correct, fluent English, and suddenly be thrown for a loop when I realize that a word had a completely different meaning for both of us without either of us realizing it. It's just a really interesting concept I think about a lot since I do a lot of cross-cultural communication.

dmit 7y ago

In Scala a Set is "mappable" because it has a `map` method that goes over its elements and transforms them using the provided function. But it is not a functor, because its `map` does not obey the functor laws. If you take a Set of integers and pass an `isEven` function to `map` you will get a Set with a different structure (as long as there were originally at least two odd or two even numbers of course). `Mappable` provides short-term comfort due to familiarity, but to do so it sacrifices precision that is essential in the long term.

guerrilla 7y ago
> it sacrifices precision that is essential in the long term. Definitions are precise, not names. Names aren't what makes math work, it's the precise definitions, inference rules and theorems, regardless of the language in which they are written. 'printf' does not work the same in all programming language yet everyone knows what that name means.
TJSomething 7y ago
The very concept of functors was created to describe sets that did exactly that. The functor laws only require that there is an operator that can wrap a value from one category into the functor's target category, that mapping with the identity function is the same as the identity function, and that the results of composition of mapping with two functions is the same as the results of mapping with the composition of the two functions. Set fulfills these laws perfectly. There is no law for maintaining cardinality, because the functor laws don't care if cardinality is a concept that even makes sense for the target category in question.
joshlemer 7y ago
I am also really annoyed by how Set and Map's map methods work in Scala (and have argued about it here: https://contributors.scala-lang.org/t/set-map-deduping-and-possibly-unsafe-behavior/3436 https://contributors.scala-lang.org/t/set-map-deduping-and-p...), I actually don't think that for all the shortcomings of the Set map method, it actually violates any of the Functor laws: 1) For all sets s, s.map(identity) == s ==> true 2) For all sets s, functions f and g, s.map(x => f(g(x)) == s.map(g).map(f) ==> true On the other hand, Map's map method is much more horrible, and does violate the 2nd functor law where f == g == _.swap : Map(1 -> 2, 2 -> 2).map(_.swap).map(_.swap) ==> Map(2 -> 2) Map(1 -> 2, 2 -> 2).map(_.swap.swap) ==> Map(1 -> 2, 2 -> 2) Further, it behaves differently depending on if it is known to be a Map at compile-time, or if it is only known to be an Iterable[(K, V)], due to overloading: Map(1 -> 2, 2 -> 2).map(_.swap) ==> Map(2 -> 2) (Map(1 -> 2, 2 -> 2): Iterable[(Int, Int)]).map(_.swap) ==> List(2 -> 1, 2 -> 2)

ex3xu 7y ago

Open question: if Functor should be called Mappable, what would you call Applicative? EvenMoreMappable? Similarly, if Semigroup should be called Appendable, what would you call Monoid? And is there a consensus on Monad as well?

guerrilla 7y ago
As it is now, Applicative is really an applicative functor. In general, if a term covers a subset then there is a property which distinguishes the subset from its ambient set and we can use that property to qualify the term as being such. On the other hand, obviously Monad should be called Burrito.

empath75 7y ago

Right, names without context don’t have any meaning, but once you’re in the world of everyday workmanlike programming, mappable is a perfectly clear concept, where as functors as they are usually explained do not. If you were to take someone who is new to programming and talk about mappable datastructures they would look at you blankly, but any random JavaScript programmer should know what you mean instantly.

quickthrower2 7y ago

Interesting the name of the function you define in Haskell for a type to use the Functor typeclass is "fmap", so the core library designers must agree with you to some extent. I can forgive Haskell for using the word "functor" because it came from academic roots, it isn't a language like Go designed specifically to make things easy for programmers to pick up.

danharaj 7y ago

Why does Mappable mean "something that you can apply functions to" and not "something that you can apply as if it were a function"?

cryptonector 7y ago

+1. A portmanteau, a verbified noun, a nounified verb, and so on -- these "abuses" of language can help carry meaning in a way that random names cannot. That said, "functor" perhaps did sound to its originators like what "mappable" does to you (and me) now.