Switch Statement

045: A Billion Dollar Mistake

October 13, 2023 Jon Bedard
Switch Statement
045: A Billion Dollar Mistake
Transcript
Matt:

Hello everyone And welcome to the switch statement podcast It's a podcast for investigations into miscellaneous tech topics

Today is show and tell, and we're talking about null.

jon:

Hi, Matt. I'm doing good. How about you? The vid? Yeah, no, all the cool kids are definitely calling it the vid. A pizza? Able? No way. Wow, man, Scrabble just doesn't care about the sanctity of its... Yeah. Man, can you imagine, like, The upheaval in the Scrabble universe when a new two letter word is in invented with a ten a Ten value in the tile. Oh Yeah, QI or whatever Insane we should talk about Scrabble rules one day All right, so today we're doing show and tell and I have brought a topic that is just ridiculously interesting Null Yeah, man. Null. yeah, that audio should just cut out Yeah. So this is an episode about null. Null is one of my favorite sort of love hate relationship things in programming. so what is null? Null pointer or a null reference. It's a value that indicates that a pointer or reference does not refer to a valid object. So, yeah, so in other words, if you say something is null, it's kind of non existent. And if you try to, you know, communicate with it in any way, if you try to dereference it, you will have errors. So and there's other similar concepts, there's undefined in JavaScript, which means that a variable has been declared, but it hasn't been set to anything yet. Um, and JavaScript is super interesting because null and undefined are two separate things. So if something is null, it's not undefined and vice versa. So you often see code that checks for both. There's also a concept called uninitialized, which is similar to undefined, but like in C for instance, if you just create a pointer, but don't set it to anything, it will be uninitialized, which. Which is undefined behavior, which is even more scary because it might actually point to something, it might point to something real. So, I don't know. It's a, it's an interesting concept. A lot of times null is used as a sentinel value, like common use cases. Like if you have a list or something, it'll represent the end of the list. iterating over each item, you go until you hit null. And that's, that's when you kind of know that you can stop, stop. Yeah, my understanding of null pointer, like in C for instance, is it's some constant that it's guaranteed that no other pointer will ever be that constant. Like zero, for example. You know. Yes. Yeah, which actually, uh, I'll skip ahead to... So Dykstra's quote about null. So we mentioned this last time, or maybe a couple of times ago, but I absolutely love Dykstra. Uh, he's quite possibly my favorite software engineer and his quote game is just like, it's ridiculous. He's like a comedian, but so he, so when, uh, this guy was originally inventing null, which I will talk about the guy who invented null in just a minute, but Dykstra compared a null pointer reference. To a promiscuous adulterer. And he noted that, uh, if every bachelor is pointing to the same object structure, it will seem like a polyamorous marriage. Which is just such a bizarre... I don't know. It's just, uh, Dykstra being amazing. But anyway, yeah, I just wanted to give a little bit of history of Null, because it's kind of interesting. It was invented by a guy named Charles Anthony Richard Hoare, where some people call him Tony or some people call him C A R Hoare. You'll see that a lot if you, uh, look at Wikipedia or something. It was invented around the sixties and years later, Charles Anthony Richard Hoare referred to Null as a billion dollar mistake. Yeah. Yeah, no, it is, it's interesting because you need that ability to kind of represent nothing. like that comes up in programming all the time how would you represent the end of a list if you didn't have null? You know, I guess you'd always have to just know exactly how many things are in the list and just stop once you reach that point or something. And maybe that's his point, is maybe there is always some solution, and it's better to use that solution. But yeah, I sort of agree with you. It seems like a very practical thing, ability to have, is to be able to represent nothing. Right. Yeah. Yeah. Yeah. I don't know, I've, I haven't extensively used languages that don't have null. Like I think. I think there are, I mean, there's, there's always some concept of like, like maybe Haskell doesn't have null. Let's check this. Does Haskell have null? I'm literally Googling this right now. Uh, Haskell does not have null. Uh, this is a design feature. It completely prevents any possibility of your code crashing due to null pointer exception. Uh, okay. So they're not saying how Haskell represents null. Um, but I think, ah, okay, they have a maybe, um, which I vaguely remember. I, way back in the day, I did a little Haskell because I was curious. Uh, and yeah, the way maybe works is if you have a reference to a maybe, you always have to pattern match on it, you know? So you, you always have to handle this case of like, there wasn't something. So it's, yeah, exactly. You have to catch on the maybe not. So anyway, it's, and actually this is something I was going to talk about a little bit later, but a lot of languages have sort of made up for the, the frailties of null by introducing more abstractions, like Java has something called an option or optional. Where it's basically saying, you know, instead of having a function return null, which is dangerous, you can have a function return an option, which is telling the client in the signature of the function that like, hey, you know, this function might not actually return anything. And it also sort of, it gives you this object that you sort of have to deal with. Um, which a lot of people find that to be a little nicer. I think I would agree with those people. Yeah, yeah, exactly. Which is, yeah. And this was my sort of first real introduction to null was the Java language. And I do think, I mean, going back to the billion dollar mistake thing, I would completely agree with, with that logic in Java, because in Java, you just never know if something is null or not. And there's so many cases where something can. Um, you know, be null and it just gets passed along this super long chain of logic. You don't know where it came from. Um, and yeah, it feels safe to dereference it, but you get an all pointer exception. Also another language, Objective C. So I did a bunch of Objective C for iOS mobile development and Objective C, at least to me, has a completely bizarre handling of null. Um, it's called nil in the Objective C language, but whenever you. It's called passing a message. Whenever you pass a message to nil, it just returns nil. So if anything in your code is nil, you wind up with these situations where your code doesn't error, but like nothing is actually working. Like you can have this really long block of code where the whole thing just runs and no, it doesn't throw any exceptions or anything. And it even like you know, like even to the user, it might just like render nothing. But the actual error is like the first line of this massive block of code. So it's, uh, I don't know, on the one hand, maybe it leads to a better user experience in cases where there's bugs in the code, but on the other hand, it makes it very hard to find issues. Yeah. Mm hmm. Yeah. Yeah. Right. Exactly. Yeah. TypeScript, uh, is an amazing language and has, uh, there's a feature that, uh, that many languages have called null safety. A lot of modern languages will have this where whether something can be null or not is actually part of the type. Right. And this is sort of what type TypeScript has, where you can specify a type as. Just like you're saying, you know, it's either an int or it's null. And, you know, you're literally doing that with a union type a lot of the times in TypeScript. Um, other languages like, you know, Kotlin, for instance, you could use the question mark, which you can do the question mark in TypeScript too, right? Where it's okay. Yeah, I wasn't sure about that, but in Kotlin you can say something, is nullable or not by having a type or a question mark at the end of the type. And other languages allow you to do this in various ways, like Dart also has null safety. other languages refer to this as void safety, by the way, which I thought was just a cooler name. Just sounds, sounds intense. Well, that's the thing is like a lot of, so there's different words for this null concept. Like Python, it's called none. I mentioned Objective C, it's called nil. Some languages actually call this void. Which to me is confusing, because I think of void as, you know, basically a function that doesn't return, But I guess in some languages, it's like a thing. Yeah. Yeah. Right, yeah, right. Well, I think different languages just handle this differently, you know, where like in C if you try to say like some variable equals the result of a void returning function, it just won't compile, you know? So, but I think in some languages you can say like some variable equals this void returning function. Like you can do that in Python and I think it just is equal to none. Um, Oh yeah, Oh God, yeah, no, the void pointer, the dreaded void pointer, which I don't, I mean, I don't know how the void pointer works. I know that it essentially allows you to pass anything. Like you can pass functions, you can pass, um, you know, pointers to things, references to whatever. So it's, I think it's kind of like this any style pointer. Um, that's just extremely permissive, but I don't know. I've always sort of thought of the void pointer as a smell. Like I'm sure there's some cases where it's, it's necessary, but I don't know. Yeah. Right. Which now they have, you know, C, C plus plus today has like function types where you can, you can basically have something that extends from function. There's also anonymous function. So there's like features in the language that I think. are probably more, uh, you know, viewed as you should use those instead of using the void pointer, but yeah, I think, I think what you're saying is true where like originally in C or something, this would allow you to implement a callback type system. Um, yeah, what else did I want to say? We talked about null safety. Oh yeah. And if you do have a language that has null safety, it will often provide additional operators that allow you to safely act on an object that could be null, like the question dot operator allows you to sort of safely traverse the fields of an object and it will all just resolve to null, like if the original object is null. You know, this big chain of like question dots will just all result to null. Yeah. Yeah. I think it's commonly referred to the Elvis operator because of the swishy hair that the question mark sort of looks like. But, uh, yeah, that's one of my favorite operators. Maybe the, uh, what is it? The UFO operator is only slightly above. I don't know if that's the exact name for it. Maybe spaceship operator, the, uh, I think it's like a less than a colon and a greater than, and I can't even remember what it does to be honest, but I just feel like I've seen that somewhere. Um, but yeah, and I guess, uh, that's, that was null. I don't really have anything else to chat about. I've just always found null to be this really interesting concept. So I wanted to look into the history of it a little bit. Yeah, yeah, it's fascinating. I think every programming language sort of use it as one of those things that the other languages get wrong. So they try to, you know, quote unquote fix it, but invariably the way they fix it also has a bunch of wrongness. Yeah, no. Yeah, no, let's just give up. This is why it's good that GPT is just going to start taking over in a couple of years, so we just won't have to worry about this problem anymore. See you next time.