4 ms·

> 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

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

by ex3xu 7y ago

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.