Interestingly, since meaning itself is a functor from syntax to semantics, there’s a bootstrapping problem where one must grok functors before one can ignore the word “functor” as others use it.
and this makes Haskell an elitist, non-inclusive language, (it is, but this isn’t why)
This is an incredibly frustrating thing for me to read. I should probably ask Matt to elaborate before I jump to conclusions, but I suspect this is another example of common ignorance among educated people.
I write Haskell full-time and employ others to write it too, but I didn’t go to school for this. I self-taught as a programmer, starting with WordPress and jQuery. I’ve asked for help on about 15,000 programming things over the past decade with various technologies. Relative to the others, Haskell people have been some of the least elitist, and most inclusive.
And anyway, who exactly is going to read Matt’s flippant remark above and think “Oh yeah! Elitist and non-inclusive? Count me in! I’ll get started learning right away!”
I’m about to go on a bikepacking trip with two other Matts. I suspect my first name will be dropped entirely on this trip.
I don’t buy this name analogy preamble. Humans (and likely any other reasonably intelligent animal) aren’t robots that only respond to specific names. If I’m Matt A and I address Matt B by David, he’s just going to think I’ve forgotten his name but he’d still respond. If I’m Matt A, I’m talking to Matt B, and I refer to Matt, Matt B is going to have a good amount of confidence that I’m referring to Matt C — otherwise I’m likely a weirdo talking about myself in third person.
The Wiktionary page relates it to maps, suggesting that it means you “can make a geographical map of a thing,” or that you can construct a “mapping” between two sets of things. Grammatically, it implies that you can use a verb “map” over the thing.
…What? What hypothetical world does the author imagine in which its inhabitants can understand functors but can’t understand homonyms?! Children understand homonyms.
This name, Mappable, points to a bunch of potential meanings already, and none of them are really right.
Yes they are. Most boring industrial Haskell work uses functor in a way that is consistent with the mapping over containers analogy. The analogy isn’t perfect, but it’s good enough for practical purposes. Being an elitist here about analogies is a little funny given the allusion to the Haskell community being too elitist in general at the top of the blog post.
But we still have to explain what a Mappable is. “What’s a Mappable? Well, it’s something you can map over!” is a terrible explanation!
No, it isn’t. This explanation actually works in practice. There are caveats that also need to be explained like the functor of functions or why you can only map over the right side of an Either.
The audience’s familiarity with any of these words seems arbitrarily chosen by the author to support his point.
Wait, “map over”? This is unfamiliar terminology. I know about “maps” like Google Maps. I know that I can ‘map’ a space out and provide information about how to get from here to there.
Wait, Matt Parsons? You were named after a piece of coarse material placed on a floor for people to wipe their feet on!?
Honestly, I don’t see obvious potential to get my brain and Haskell working together. It’d require me to learn a whole slew of mappings between existing concepts and new words for them that are almost entirely unrelated to learning new ideas to do the actual task I want to do. Worse, I have to make sure I don’t let that mapping leak back into my work with… well… most other languages. On the other hand, I suspect folks with a linguistics or math background might be feeling the same way about C or Java, and they see languages like Haskell as a route to that kind of brain compatibility.
Speaking of heavily overloaded names.. math means a lot of things too! :D
I was also terrible at high school math, but the abstract algebra and category theory concepts that Haskell borrows were quite natural for me. And, uh, these are math too? Some would say category theory is more fundamental than those pesky continuous and real-number things…
I reckon I know why you find Haskell easier that mscs:
“I write Haskell full-time”
Put any developer in a team of Haskellers, every day having people to ask questions and get help from and I’m sure they’d pick it up.
I say this as someone who struggled to learn basic Haskell in my spare time, and am still intimidated by the more advanced concepts but I think if I did it full time I’d grok it.
Put any developer in a team of Haskellers, every day having people to ask questions and get help from and I’m sure they’d pick it up.
Right, but that’s not what I did. I learned Haskell in my spare time, made side projects in it, and then began building businesses with it. Nobody gave me a job writing Haskell.
I say this as someone who struggled to learn basic Haskell in my spare time, and am still intimidated by the more advanced concepts but I think if I did it full time I’d grok it.
I am also intimidated by the more advanced concepts. That’s ok. There’s a lot to learn. I’ll learn little by little in due course. When I started trying to build side projects, I didn’t even grok basic things like the more obvious uses of functors. I just wrote bad Haskell at the term level, but even that served me better than the side projects I had done in Rails — and I knew Ruby and Rails, and had been hired by companies to write it.
Interestingly enough, FPers used “functor” because it was a familiar word from math for a similarish concept. But mathematicians borrowed it from “function words” in linguistics, which was a similarish concept, too! It’s only an “pointer” name if you don’t have that background, and otherwise it leverages your intuition as much as “class” does.
If we want to avoid familiarity, though, why “functor” at all? “Flurp” has even fewer collisions, and is shorter to boot!
The point is that a movement to rename Functor to Mappable is misled because these connections lead to more confusion than clarity. That the author doesn’t make this argument against the name Functor doesn’t invalidate the argument. I can’t tell if Flurp is throw-away sarcasm, but why not? Many symbols in APL seem arbitrary. I would guess that some are not. Most of the time, I can’t tell the difference. But (seemingly) arbitrary symbols are no harder to learn. So whether it’s Flurp or a name like Functor, which is just as inscrutable to many people, the name “doesn’t matter.”
That human beings can attach meaning to arbitrary symbols in tight contexts (as happens everywhere in math) is not an argument that arbitrary names are just as good as thoughtfully chosen ones. These are basically unrelated phenomena.
It’s a pointer with an ambiguous address space… It’s a database ID column
Names are part of a complex web of concepts, overlapping analogies, social and linguistic history, and biological associations we have with sounds (see the Bouba/Kiki effect). They transmit countless meanings in countless ways.
I find a word like ‘illuminate’ pretty and ‘buzzfeed’ gross, which is totally just because I am weird and have opinions about this.
It’s because you are a human being. I’d rank those words the same. I’d bet most people would. Sensitivity to this kind of thing is the bread and butter of poets and writers. And it’s a talent you need to choose good names.
There is something spock-like about the article’s thesis.
It’s the linguistic equivalent of the CS-centric worldview that produced soylent and holds that food is about nutrition, nothing more. If that works for you, ok, but all the people who care about wine and meals and the way food looks and smells aren’t making a logical error.
Most people find the name “functor” confusing and ugly. It’s viscerally distasteful. It makes the concept more intimidating than it needs to be. It’s not because those people don’t understand the true nature of names. It’s because it’s a bad name.
And it matters because it has consequences. It makes communication more difficult. It hampers interest in functional programming.
In fairness, finding good names at the peak of Mount Abstraction is hard (because often the best names rely concrete, everyday analogies), and it may be the case that there’s no great alternative to “functor”. But we probably could have done better.
The statement “Names can’t transmit meaning” is not even wrong.
This reads like something written by someone that knows programming languages and perhaps programming language design and thinks they can therefore say sensible things about linguistics or the philosophy of language. Or they have a really weird and non-mainstream view of how words relate to meaning.
The article itself fails to distinguish different meanings of the overloaded word ‘name’ and treats them as if they are the same thing.
As someone who very occasionally types a line or two of Haskell, but never committed any of the basic types to memory, I have to say that ironically I couldn’t remember what a functor actually was until this bit:
The best (but still extremely bad) alternative name to Functor is Mappable.
This is anecdotal and subjective and all, but the name Mappable is just so much more obvious to me. The point of “well what about cartography” also seems to be contradicted by a previous point
Reliability is also subjective. It all depends on context and familiarity.
In context, there is no confusion between printed on paper maps and the type. “Mappable is a type that can be mapped over” is much more consistent than “Functor is a type that can be mapped over”, and should be clear to most developers. Yes, beginners will still need to learn the meaning of “mapping over”, but once they do, why not give them a memorable (if imprecise) name instead of another conceptual pointer they need to keep in their heads.
I understand the desire for precise, unambiguous language by Haskell folks, but it really just doesn’t resonate well with me. I’d much rather optimize for readability and ergonomics.
why not give them a memorable (if imprecise) name instead of another conceptual pointer they need to keep in their heads.
I don’t think the name should be changed, because functor is a perfectly good word with plenty of relevant educational material pointing to it. It’s more precise than “mappable”, because functors actually go further than the concept of mapping functions over containers.
However, the analogy of mapping functions over containers is useful, because it allows the student to actually get to work with this algebra rather than navel-gaze on the meanings and origins of names.
Mappable is good, but I think Functor is better still because we can recall the “functor laws” from category theory (functors preserve identity and composition). These laws aren’t just abstract curiosities—they are actually useful for reasoning about programs. Mappable doesn’t really convey the fact that these laws should hold.
To me, the key detail is: when you hear the word “functor” for the first time, you aren’t led into a false sense of familiarity. If it’s a new word to you, you can Google it and learn about the functor laws. But if we just called it “mappable”, you might think “ok I know what this is doing” and never learn the proper definition. And if you already know what functors are, you can immediately start using them without having to learn a “friendlier” neologism when learning a new language.
When I was younger and double the asshole I am now, I used to scorn Harry Potter for not being a “true fantasy” like Witcher and LoTR. I also used to scorn Python because of the whitespace and prefer PHP because curly braces and so on.
All these conversations seem to me like a 100% in-group/out-group signalling and 0% technical discussion. Is Fruux a good name for frobnicating bars? Is casting spells without mana or fatigue true fantasy?
Firstly, I agree with the fundamental point here that using a familiar word for a new concept may be misleading. It privileges one analogy over others. It may even force you to unlearn an immediate misconception before you can truly learn the concept, and even then you may continue to mentally trip over it afterwards. This phenomenon is frequently used on purpose in advertising or propaganda.
However, with respect to Functor vs. Mappable:
class Functor f where
fmap :: (a -> b) -> f a -> f b
For people coming from more mainstream languages, “map” has been learned as an iteration over a collection. That is not the correct base intuition for Functor, though incidentally map does iterate over instances that are collections. Many common instances are not collections, and the name Mappable may lead to confusion with iteration.
I eventually understood what a monoid is and none of haskeller helped. I just discovered that it was a mathematical term, looked on wikipedia page, and that was cristal clear.
I wonder how haskell can hide that :
A monoid is just (a.b).c=a.(b.c) and e.a=a.e=a
And that the typical example is string concatenation and empty strings
I just read the haskell wiki on the subject and appart the term Sum nothing still males sense, despite the fact that I far as know monoids in haskell are exactly same things than in math.
Sorry, haskell you are doing a lot of things very wrong.
(As far as I know, it is not the only occurence, rust use quite a lot of functional programming/haskell things, and rust is perfectly clear).
I would say that a lot of confusion has root on overgeneralisations of concept: in a typical program, one need an object which has two or three properties, some expert discover that if it has this three properties it has hundreds of useless others, so haskell teach you the hundreds of properties and good luck to recognize the familiar and obvious object.
Interestingly, since meaning itself is a functor from syntax to semantics, there’s a bootstrapping problem where one must grok functors before one can ignore the word “functor” as others use it.
This is an incredibly frustrating thing for me to read. I should probably ask Matt to elaborate before I jump to conclusions, but I suspect this is another example of common ignorance among educated people.
I write Haskell full-time and employ others to write it too, but I didn’t go to school for this. I self-taught as a programmer, starting with WordPress and jQuery. I’ve asked for help on about 15,000 programming things over the past decade with various technologies. Relative to the others, Haskell people have been some of the least elitist, and most inclusive.
And anyway, who exactly is going to read Matt’s flippant remark above and think “Oh yeah! Elitist and non-inclusive? Count me in! I’ll get started learning right away!”
I don’t buy this name analogy preamble. Humans (and likely any other reasonably intelligent animal) aren’t robots that only respond to specific names. If I’m Matt A and I address Matt B by David, he’s just going to think I’ve forgotten his name but he’d still respond. If I’m Matt A, I’m talking to Matt B, and I refer to Matt, Matt B is going to have a good amount of confidence that I’m referring to Matt C — otherwise I’m likely a weirdo talking about myself in third person.
…What? What hypothetical world does the author imagine in which its inhabitants can understand functors but can’t understand homonyms?! Children understand homonyms.
Yes they are. Most boring industrial Haskell work uses functor in a way that is consistent with the mapping over containers analogy. The analogy isn’t perfect, but it’s good enough for practical purposes. Being an elitist here about analogies is a little funny given the allusion to the Haskell community being too elitist in general at the top of the blog post.
No, it isn’t. This explanation actually works in practice. There are caveats that also need to be explained like the functor of functions or why you can only map over the right side of an Either.
The audience’s familiarity with any of these words seems arbitrarily chosen by the author to support his point.
Wait, Matt Parsons? You were named after a piece of coarse material placed on a floor for people to wipe their feet on!?
Come on.
Honestly, I don’t see obvious potential to get my brain and Haskell working together. It’d require me to learn a whole slew of mappings between existing concepts and new words for them that are almost entirely unrelated to learning new ideas to do the actual task I want to do. Worse, I have to make sure I don’t let that mapping leak back into my work with… well… most other languages. On the other hand, I suspect folks with a linguistics or math background might be feeling the same way about C or Java, and they see languages like Haskell as a route to that kind of brain compatibility.
I don’t have a linguistics or mathematics background.
I failed high school maths.
I start with C-like languages.
I find Haskell easier.
Speaking of heavily overloaded names.. math means a lot of things too! :D
I was also terrible at high school math, but the abstract algebra and category theory concepts that Haskell borrows were quite natural for me. And, uh, these are math too? Some would say category theory is more fundamental than those pesky continuous and real-number things…
I reckon I know why you find Haskell easier that mscs:
“I write Haskell full-time”
Put any developer in a team of Haskellers, every day having people to ask questions and get help from and I’m sure they’d pick it up.
I say this as someone who struggled to learn basic Haskell in my spare time, and am still intimidated by the more advanced concepts but I think if I did it full time I’d grok it.
Right, but that’s not what I did. I learned Haskell in my spare time, made side projects in it, and then began building businesses with it. Nobody gave me a job writing Haskell.
I am also intimidated by the more advanced concepts. That’s ok. There’s a lot to learn. I’ll learn little by little in due course. When I started trying to build side projects, I didn’t even grok basic things like the more obvious uses of functors. I just wrote bad Haskell at the term level, but even that served me better than the side projects I had done in Rails — and I knew Ruby and Rails, and had been hired by companies to write it.
Interestingly enough, FPers used “functor” because it was a familiar word from math for a similarish concept. But mathematicians borrowed it from “function words” in linguistics, which was a similarish concept, too! It’s only an “pointer” name if you don’t have that background, and otherwise it leverages your intuition as much as “class” does.
If we want to avoid familiarity, though, why “functor” at all? “Flurp” has even fewer collisions, and is shorter to boot!
The point is that a movement to rename Functor to Mappable is misled because these connections lead to more confusion than clarity. That the author doesn’t make this argument against the name Functor doesn’t invalidate the argument. I can’t tell if Flurp is throw-away sarcasm, but why not? Many symbols in APL seem arbitrary. I would guess that some are not. Most of the time, I can’t tell the difference. But (seemingly) arbitrary symbols are no harder to learn. So whether it’s Flurp or a name like Functor, which is just as inscrutable to many people, the name “doesn’t matter.”
Names don’t matter but consistency matters, so please no Flurp!
The symbols perhaps (though even there: many of them are intentionally suggestive) but not the names of the symbols. J’s vocab page:
https://www.jsoftware.com/help/dictionary/vocabul.htm
“Tally”, “Ravel”, “Stitch”, “Cut”, etc….
That human beings can attach meaning to arbitrary symbols in tight contexts (as happens everywhere in math) is not an argument that arbitrary names are just as good as thoughtfully chosen ones. These are basically unrelated phenomena.
Names are part of a complex web of concepts, overlapping analogies, social and linguistic history, and biological associations we have with sounds (see the Bouba/Kiki effect). They transmit countless meanings in countless ways.
It’s because you are a human being. I’d rank those words the same. I’d bet most people would. Sensitivity to this kind of thing is the bread and butter of poets and writers. And it’s a talent you need to choose good names.
There is something spock-like about the article’s thesis.
It’s the linguistic equivalent of the CS-centric worldview that produced soylent and holds that food is about nutrition, nothing more. If that works for you, ok, but all the people who care about wine and meals and the way food looks and smells aren’t making a logical error.
Most people find the name “functor” confusing and ugly. It’s viscerally distasteful. It makes the concept more intimidating than it needs to be. It’s not because those people don’t understand the true nature of names. It’s because it’s a bad name.
And it matters because it has consequences. It makes communication more difficult. It hampers interest in functional programming.
In fairness, finding good names at the peak of Mount Abstraction is hard (because often the best names rely concrete, everyday analogies), and it may be the case that there’s no great alternative to “functor”. But we probably could have done better.
The statement “Names can’t transmit meaning” is not even wrong.
This reads like something written by someone that knows programming languages and perhaps programming language design and thinks they can therefore say sensible things about linguistics or the philosophy of language. Or they have a really weird and non-mainstream view of how words relate to meaning.
The article itself fails to distinguish different meanings of the overloaded word ‘name’ and treats them as if they are the same thing.
Throwing in straw men doesn’t help either.
As someone who very occasionally types a line or two of Haskell, but never committed any of the basic types to memory, I have to say that ironically I couldn’t remember what a functor actually was until this bit:
This is anecdotal and subjective and all, but the name
Mappableis just so much more obvious to me. The point of “well what about cartography” also seems to be contradicted by a previous pointIn context, there is no confusion between printed on paper maps and the type. “Mappable is a type that can be mapped over” is much more consistent than “Functor is a type that can be mapped over”, and should be clear to most developers. Yes, beginners will still need to learn the meaning of “mapping over”, but once they do, why not give them a memorable (if imprecise) name instead of another conceptual pointer they need to keep in their heads.
I understand the desire for precise, unambiguous language by Haskell folks, but it really just doesn’t resonate well with me. I’d much rather optimize for readability and ergonomics.
I don’t think the name should be changed, because functor is a perfectly good word with plenty of relevant educational material pointing to it. It’s more precise than “mappable”, because functors actually go further than the concept of mapping functions over containers.
However, the analogy of mapping functions over containers is useful, because it allows the student to actually get to work with this algebra rather than navel-gaze on the meanings and origins of names.
Mappable is good, but I think Functor is better still because we can recall the “functor laws” from category theory (functors preserve identity and composition). These laws aren’t just abstract curiosities—they are actually useful for reasoning about programs. Mappable doesn’t really convey the fact that these laws should hold.
I’m not sure most programmers can recall the functor laws from category theory. I certainly never heard of it.
To me, the key detail is: when you hear the word “functor” for the first time, you aren’t led into a false sense of familiarity. If it’s a new word to you, you can Google it and learn about the functor laws. But if we just called it “mappable”, you might think “ok I know what this is doing” and never learn the proper definition. And if you already know what functors are, you can immediately start using them without having to learn a “friendlier” neologism when learning a new language.
Not most programmers, but most people who learn a language which explicitly uses those abstractions.
When I was younger and double the asshole I am now, I used to scorn Harry Potter for not being a “true fantasy” like Witcher and LoTR. I also used to scorn Python because of the whitespace and prefer PHP because curly braces and so on.
All these conversations seem to me like a 100% in-group/out-group signalling and 0% technical discussion. Is Fruux a good name for frobnicating bars? Is casting spells without mana or fatigue true fantasy?
Is it useful and/or fun? Yes? Good!
Firstly, I agree with the fundamental point here that using a familiar word for a new concept may be misleading. It privileges one analogy over others. It may even force you to unlearn an immediate misconception before you can truly learn the concept, and even then you may continue to mentally trip over it afterwards. This phenomenon is frequently used on purpose in advertising or propaganda.
However, with respect to
Functorvs.Mappable:I mean, enough said, right?
For people coming from more mainstream languages, “map” has been learned as an iteration over a collection. That is not the correct base intuition for Functor, though incidentally map does iterate over instances that are collections. Many common instances are not collections, and the name Mappable may lead to confusion with iteration.
My point is you can’t logically make that argument and then call the function
fmap. I mean, pick a lane!I eventually understood what a monoid is and none of haskeller helped. I just discovered that it was a mathematical term, looked on wikipedia page, and that was cristal clear.
I wonder how haskell can hide that :
A monoid is just (a.b).c=a.(b.c) and e.a=a.e=a
And that the typical example is string concatenation and empty strings
I just read the haskell wiki on the subject and appart the term Sum nothing still males sense, despite the fact that I far as know monoids in haskell are exactly same things than in math.
Sorry, haskell you are doing a lot of things very wrong. (As far as I know, it is not the only occurence, rust use quite a lot of functional programming/haskell things, and rust is perfectly clear).
I would say that a lot of confusion has root on overgeneralisations of concept: in a typical program, one need an object which has two or three properties, some expert discover that if it has this three properties it has hundreds of useless others, so haskell teach you the hundreds of properties and good luck to recognize the familiar and obvious object.