Naming and pointer thickness
Occam’s Razor is often phrased as “The simplest explanation that fits the facts.” Robert Heinlein replied that the simplest explanation is “The lady down the street is a witch; she did it.”
− Occam’s Razor, Eliezer Yudkowsky
The point here is that people have confused ideas about what “simple” means. The sentence “The lady down the street is a witch; she did it.” seems simple, but in actuality, it is very complex. It seems simple because it’s kinda short, but the shortness is deceiving.
Don’t see what I mean? Let me ask you a question. What if we took the first letter of each word and abbreviated the sentence as “tldtsiawsdi”? Is it simpler? No, of course not. But why?
Well, it’s still pointing to the same underlying thing. We just used different symbols to do the pointing. When we talk about simplicity and complexity in Occam’s Razor, we’re talking about the substance, not the symbols.
In this particular example, there’s a big issue with the word “witch”.
“Witch,” itself, is a label for some extraordinary assertions—just because we all know what it means doesn’t mean the concept is simple.
There’s a lot of fun places to take this conversation. If you’re interested in things like rationality and philosophy, I’d really recommend checking out A Humans Guide to Words. Here, I want to talk about how this relates to programmig.
In programming, we also have symbols and substances.
var adam = {
firstName: 'adam',
lastName: 'zerner',
email: 'adamzerner@protonmail.com’,
birthday: ’11/03/1992’
};
adam
is the symbol, and { firstName: 'adam'... }
is the substance. The way I like to think of it, the substance gets compressed, or squished into the symbol. You have this big complicated thing, and you pack it up nicely into a symbol that represents it. Then, elsewhere in the codebase, you can refer to adam
instead of { firstName: 'adam'... }
. I think that conceptually, this is the same thing that is happening with “witch” and 🧙♀️, as well as “apple” and 🍎, “bear” and 🐻, and “carrot” and 🥕. (If 🧙♀️→ “witch” doesn’t look like compression to you, read about thingspace and you’ll see how much is packed into 🧙♀️.)
In writing as well as speaking, it is important to communicate clearly. One way to do that is to choose simple words. To speak in plain english. Eg. saying “start” instead of “commence”.
Why? Think about it in terms of the symbol and the substance. Both “start” and “commence” are symbols, and they roughly point to the same underlying substance. With “start”, the pointer is more… accessible. It’s “oh yeah, I know what you mean” versus “huh… what are you trying to point to?”
In programming it’s the same thing. You want to communicate clearly. You want to name things well, so that when people read your code, the pointer is thick and obvious, not thin and obscure. You want it to be clear what the underlying substance is. It’s as if you’re a tour guide who is trying to direct the reader towards the substance.
I’m not saying anything new here. Everyone knows this. But there’s a big difference between “knows” and knows, and my hope in this post is that this way of visualizing it will help you move away from the former and towards the latter. That it will prompt you to think about how thick and direct your pointers are.
I think it would be helpful to point out some examples of where naming things goes poorly in practice. Let’s do that.
“B.1.351” instead of “the South African strain”.
“DEV-7754” instead of “the denylist ticket”.
“PoC” instead of “proof of concept”
“Bayes’ theorem” instead of… I’m not sure, but something more descriptive than a guy’s name.
See how those symbols don’t do a good job of pointing to the substance? Let’s also take a look at some examples in programming.
user.arg1
instead ofuser.firstName
.yyyymmdstr
instead ofcurrentDate
.l
instead oflocation
.
There’s a lot that can be said about how to name things well. I don’t want to get into all of that in this post though. I think that would detract from the core point. The core point is that, IMHO, visualizing things this way − a symbol pointing to a substance with some thickness − will help you think more clearly about naming things. Hopefully you’ll find that core point useful.
Humanity has perennial issues with anything where the explanation of the solution is much longer than the explanation of the problem.
The best phrasing I’ve heard is “never assume plurality without necessity.” But most English-speaking people never use the word ‘plurality’ that way, so perhaps it’s off-putting.
I’m actually having trouble understanding what that phrase means and how it relates to my post. Would you mind elaborating?
As in the phrasing of Occam’s Razor or the principle of maximum parsimony.
I’m not sure if you were around during the 2000s (if that’s your DOB then probably not) atheism/evolution vs theism/creation era but a common “debate” would go like
Atheist: finding a correct scientific answer can be accelerated by simplifying the assumptions.
Theist: well, the simplest answer is the “God created it!” It’s definitely simpler than the theory of evolution and a 5 billion year old earth. lol pwnz0red !!!!
Atheist: … uhh that’s not what I mean… stimmer stammer.
I think we agree on the problem, in terms of “simple” is the incorrect framing.
But I also don’t think we get around that by saying “not the simplest symbols but the simplest substance.”
If you think about it more like “does this need to be in an explanation and/or does it implicitly contain more dependencies or assumptions?”
As is the case with witches and God in our two examples, there’s an implicit assumption that witches have power and disposition to to kill, and God has power to create a universe.
You really don’t have to care if those conditions about witches and God are true, all you have to care about is “is there a reason to include witches or God in this explanation?” If there’s no evidence, then there’s no reason to include them.
Hm, I think I see what you mean. I agree that “not the simplest symbols but the simplest substance” has the issue of “simple” being a term that can be argued and that what you’re saying about dependencies/assumptions gets closer to the heart of the issue. I guess it depends on who your audience is.