 Welkom everyone to this session at Functional Conf for 2022. We are really excited to have Jed Wesley-Smith with us. He is going to be talking about names are overrated. So we're looking forward to hearing about that and having some fun with names. Thanks very much for the lovely introduction. G'day everyone, my name is Jed Wesley-Smith. I'm very pleased and honoured to be presenting at Functional Conf this year. It's unfortunate it couldn't be there. It's about 15 years since I was last in India and would have loved to have been back. But this is a pleasure anyway. Our talk today is about names, about why we name things, how we name things and what are some of the things that we should really think about when naming things. So called names are overrated, previously called names don't matter. But that's possibly a fairly controversial thing for most people to say. So we'll call it names are overrated. And of course as programmers we all know how important naming things well is. Naming things poorly can have some really difficult consequences. And I think we've all had projects where we've had sort of bad names. I certainly had a project where the names were all things after native Australian birds and no one ever really knew if they needed a cookaburra, a pardalote or a magpie goose. It was a complete disaster. And we know that we should call our variables verbose and descriptive names. And so for instance A and B are really poor names for concrete things like taxable amount and tax rate. This let's say equals A times B is ambiguous in meaning compared to let the tax amount be the sale amount times the tax rate. This is fairly unambiguous and it's obviously better. So as programmers we tend to think and spend an enormous amount of time arguing and talking about names more possibly than anything else. And we're constantly searching for that perfect name. The idea that we programmers are uniquely gifted with the ability to decide and prescribe the one true name that something should be called. And that we really are the best at doing it. And of course there's actually a name for this. It's hubris. There isn't really such a thing as an objectively correct name. It's all subjective. So we should probably define some terms. What is a name? Well basically a name is a word or a set of words by which a person or a thing is known or how we address or refer to it. And a word is basically just a unit of language which consists of one or more sounds or their written representation. And this functions as a principal carrier of meaning. So Juliet Capulet is in love with a young Romeo Montague while her family the Capulets and the Montagues are in a deadly feud asks what is Montague? It isn't hand nor foot nor arm nor face nor any other part belonging to a man. Oh be some other man. No other name. What is in a name? That which we call a rose by any other name would smell as sweet. So Romeo would, were he not Romeo called, retain that dear perfection which he owns without that title. So what's the purpose of a name? Well really a name is just a compression scheme for communication. So complex objects, thoughts and ideas are assigned identifiers so that we can easily and succinctly refer to them. And names or identifying sounds aren't even unique to humans. They probably predate us by well over 100 million years. Many animals use specific threat identification sounds. So for instance they'll have different ones for a snake or a cat or a predatory bird. And there's no reason to presume that this identification doesn't go at least back to the time of the dinosaurs. So what is a principal carrier of meaning? So words carry meaning based on the shared understanding between two communicating parties. And without that shared understanding the name is meaningless. If I use a name that you're not aware of then it's essentially, it is completely useless. And yet the actual grouping of sounds is totally arbitrary. The meaning is built by usage. The essence of the object isn't affected by any specific representation. And for any name we must learn what it means. And indeed we introduce ourselves by telling each other our names. When I've met you I don't know your name and then I learn that name. But our usage of words is nevertheless very imprecise. We use synonyms. So we have multiple words that essentially referring to the same thing. And we overload words. So the same word can mean different things maybe in different contexts or we just have some kind of understanding of it. We also speak multiple languages. And each language has its entire own dictionary. Usually with a complete set of different words to mean the same things and entirely often different grammatical and morphological themes. And ultimately all these words are just an association of the sounds to the actual meaning. And if a word is merely an association can the actual meaning be referenced in a more stable or canonical form? And this is a really interesting idea. Is there a way that as programmers in particular we could actually have something that's better than words? Now every community has jargon. So we have special words that are only meaningful within that community. And that's a little localised compression scheme. And if you're going to join a community then you need to learn that community's jargon. Whether it's acronyms or specific words that are unique to that particular industry or that particular company. And most technical communities have extensive jargon dictionaries. And a lot of the time different jargons have different names for the same thing. So you're going to work in finance and they have a whole bunch of names for things which when you look at it really are the same as the kinds of things that are a different kind of company. But they're just called different things. So names really have what's known as the network effect. The network effect is essentially that a telephone that is unconnected to any other is really just a decorative sculpture. It's indistinguishable in its actual form from a brick. The telephone gains its initial value when it's connected to another one. And every other phone that's connected to the network increases the value of your phone. Similarly, names gain value by being shared. And a good name is a name that's widely known. They're familiar both to the speaker and the intended audience. And the process of becoming known is called making a name for oneself. So if I tell you a story about Fred, your interest is going to depend on a lot on whether you know Fred or not unless it's a great story and Fred's just a good character. Similarly, if I name something using some metaphor or analogy its value is entirely dependent on whether you happen to know the concept that you're referring to. So unfamiliarity is an interesting psychological thing for people to deal with. When we encounter the unfamiliar we are challenged and made to feel quite distinctly uncomfortable. The challenge comes at quite a deep psychological level. It triggers a fight or flight mechanism which has its origins deep in the heart of the brain in a place called the hippocampus. So when people are confronted with the unfamiliar they tend to react quite negatively. And programmers, particularly senior ones are used to being in a familiar world and so they're often suspicious of and reject the unfamiliar. The concepts we know and use are good and we've done pretty well without all the other stuff. Thanks very much. And this is also known as the blob paradox. The blob paradox refers to the mythical middle of the road language called blob. And blob programmers, especially senior ones are extremely comfortable in blob land. They know that blob is superior to lesser tools. They're happy to use all of the features. They know they don't need superior tools because, hey, they can do everything in blob. They tend to think in blob and blob is all they need. So let's talk about names. What do names matter to programmers? Well, it's really about not necessarily about what we tell the computer to do but can we tell other people about what we want the computer to do. And, of course, we've got to get things right. So we're constantly searching for better names to describe a particular unit. Names that really give the reader some innate sense of what something does and will often lean heavily on metaphor. And the problem is that many of the abstractions that we've traditionally built are fairly informally or poorly specified. Just ad hoc collections of data and functionality. And partly that's because a lot of the tools that we've been using lack the abstraction power to make them sufficiently general and reusable and usable. And so consequently, we've generally only had the ability to name things and documentation. And in many programming contexts, names are all you've got. So, when we're searching for something, we often reach for paroxynonyms. With the idea being that well, programmers already basically know everything. And if we can only find the right metaphor to tease out that existing knowledge, then they'll understand this particular bit of code. And what happens then is every language in every library provides different names based on what they think will be something that someone will understand. This brings us to this, which is known as BIND in Haskell. This is the standard monadic combinator. And Haskell brought it to programming via... Now, Martin Oderski didn't like BIND, so he created a name which was based on the composition of MAP and Flatten, which to the great annoyance of Haskell programmers, which might have been partly the point. Java's completion stage introduced then-compose, then-compose async. I don't know if Doug Lee really knew about or cared about the generic composition patterns. He just added useful combinators and they happened to be the same as BIND. It's called Select Many in C-sharp's link. Eric Mayer definitely knew all about monads and he explicitly wanted to hide those scary words from C-sharp programmers and use the existing jargon of SQL. JavaScript promises have then and the ECMAScript proposal proposed smush map because someone had already taken Flatten map. But these are almost all the same thing. Well, how do we know? We look at the type and it simply says that, given this definition, where for all types A and B for some monad of the higher kind of type M, we're given an M of A and a function from A to M of B, we can produce an M of B and all of the preceding things essentially all accord to that. And really it's the same concept, sequential composition of two effects. And the type and the laws are really the important identifying feature. Here's a function. It's called FRED. It says for all A, given an A, return an A. If we believe this hypothesis that fast and loose reasoning is morally correct and we already know this function must be the same as definitely not FRED, even though the name might lead you astray here. This is also known as, of course, the identity function. Similarly, given a function, oh my god, which says for all A, given a list of As, return a list of As, well, the function's signature's not enough to tell us about its implementation, but we can still tell a lot about it. For instance, we know that all elements in the result were definitely present in the argument because you can't just make up As. If we had a law that says for all A and a list of As, or two lists of As, if we, oh my god, the Bs appended to Cs, that's exactly the same as omagodding Cs and then appending that to omagodding Bs. And now we know precisely what this function does. It's reverse. Similarly, we can replace letters with symbols and we say that, given some spanner function that says for all bathtubs, given two bathtubs, return me another bathtub, we can say that for all crocodile, horse, and cow, we can spanner a crocodile and a horse and then spanner that with a cow and that is the same as spannering a crocodile with spannering a horse and cow. And we can fairly easily see that this is really a semi-group. We don't need any literal names for this. And we can take this a bit further and have a burrito class, which, if you squint, not very hard, you'll see is basically obviously monad. So, we'll talk quickly about hard names nearly out of time. Program is often balk at difficult names, particularly the mathematics ones, because really we all decided, well, maths people are just not very good at naming things. But really the problem is that these are unfamiliar names. And we're, as we said, hardwired to be fearful of unfamiliar things, especially if they're not easy. And many attempts to rename them try to tie them to something familiar. And that often only partially captures what they do. So, for instance, many people coming across monoids for the first time propose alternate names such as appendable or addable. And, you know, that superficially seems like it's a good idea. Monoid exposes the operation called plus, which addition is a standard example. But this operation is also shared with semi-group. So, which one is really addable? And if we're looking at addition, that also gives rise to negation or inversion, which isn't shared amongst all monoid instances. So perhaps we should really rename group to addable, except addition also admits multiplication. So maybe ring is the thing that should be renamed. Right? Addition is only a very specialised instance. So, and semi-group, monoid, group and ring are all far more specific and accurate names. I'm going to get through quickly. And of course, if we use the original names, then there's a whole set of existing literature that we can use, which is much harder to access if we rename everything. Ed Camett talks about how using the proper names or the pre-existing names has allowed others to show him how he's using them wrong or potentially additional features that he could add. And the Twitter bijection library inspired much comment because they didn't have the correct definition of bijection. And that actually led to material improvements in the library which helped everybody. Of course Java loves a good name and Spring has some of the best. Things like abstract annotation, config dispatcher, handler initialiser, which of course clearly tells you everything about what it does. It's actually been renamed to abstract reactive web initialiser. And really it's just a Java-binified tuple of application context in a class array. Some more fun with Spring. Some of these. And these are all real Spring names that you clearly know everything about just from its name. OK. So the question is, do names matter? Well, what matters is if you change it, is there a material difference? We can add multiple names to things without changing their meaning and we can refactor the name of thing without actually making any material change to the program. So I don't believe that is an actual material difference. So under that definition, names don't matter. But if we change types and laws, then we definitely change the meaning and behaviour of the program. If they don't matter, does this mean we're free to rename anything to any silly name? No, of course not. It really means that the specific word chosen isn't the important factor. It means changing well existing understood names doesn't necessarily help. So basically we should choose the ergonomic factors we care about in the names we use. Names that already have a precise meaning should be preferred to new made up names. And names that already have precise meaning should be avoided for only tangentially related concepts. Isomorphic JavaScript has got nothing to do with isomorphism. And stability of identifiers is important. It can tie multiple communities with the same concept. So naming new concepts is hard. So let's go to the pub and argue about them. I think I'll leave it there. Thank you very much everybody. I think I've run out of time for questions but we can... We've overrun a little bit but we can quickly look. There's one question there. So the question says from Kim Eo. The speaker assumes a platonic where all nouns are embedded immutably in the firmament. What can he say about names used provisionally as a tool to discover and incrementally emerge hidden half-seen and completely understood complex concepts. Did you get all of that? I don't entirely get it. A platonic universe. So this isn't to say that everything has an existing name or that we have the ability to say well everything already has a name. There are certainly things that we are discovering or inventing and we are of course in the privileged position of naming those things if they are genuinely new. My argument is simply that if there is an existing name giving it some name like burrito-like as opposed to the name monad is not necessarily doing anyone a favour. It might make more sense to you as the person who is naming it but you've now got a brand new name which has no shared understanding. You now have to teach that from scratch. You are the Unconnected Telephone. So, yeah, that's kind of the guts of what I'm trying to say. Well, one more question and then we'll take everything to the hangouts. Aaron says if ergonomics matter we might find that programmers are very bad at ergonomics. Yes or no? This is definitely true. These are usability things but we do at the same time spend a lot of time arguing and thinking about names and yes, I certainly agree that programmers are actually not very good at naming things. However, it's like planning. No plan survives contact with the enemy but planning is an extremely important thing to do regardless because it gives you some idea of where you're going. So, if you have at least some more tools in the kit bag to think about what you want for a name and if one of those things is is there an existing name, can we use that? I would hope that if all this talk does is give you that thought and say well, use the existing name because it's very good because people already know it and there's already a whole heap of stuff out there about what it does and what it is. All right, I'm going to sneak in one more question from Elliot Cable but doesn't advertising Trump correctness a correctly or precisely named thing that nobody uses is objectively less useful than a slightly wrongly named thing that lots of people benefit from? Isomorphic JavaScript, anyone? Yes, so I think the isomorphic JavaScript example is an interesting one because they have used a word which has a very precise meaning and then used it very poorly. They're really just saying, oh, you can run JavaScript on the server or the browser. It has no real relation to isomorphism. Certainly because it's the JavaScript world they've publicised that out and everyone knows what they mean. So in that sense it is a good enough name but it's certainly not something that I would sort of recommend people use for that. The point here is there is no such thing as an objectively good name. It's all subjective. I'm not going to say that these names I have the answer because I'm talking about names. I'm simply saying that there is no correct way to do it. It's just whatever we choose to use. However, again, council, people to use the existing names if they can. Jed, thank you so much for your talk on names and their importance and how we might go about naming things for the maximum benefit and not having too many fights over it.