Oh yeah I forgot, first you have to make a blog post, then a devlog, then review the top 10 best features of JS es6 (9 years after it was released…). Then shitpost on social media network for the other half of the week, and boom! You’re officially a Master Programmer!
Because languages need to be able to handle the very common edge cases where data sources don’t return complete data.
Adding null coalescing to a null-safe language (like dart) is so much easier to read and infer the risk of handling null than older languages that just panic the moment null is introduced unexpectedly.
For old languages, null coalescing is a great thing for readability. But in general null is a bad concept, and I don’t see a reason why new languages should use it. That, of course, doesn’t change the fact that we need to deal with the nulls we already have.
How are we supposed to deal with null values though? It’s an important concept that we can’t eliminate without losing information and context about our data.
0 and “” (empty string/char) are very often not equivalent to null in my use cases and mean different things than it when I encounter them.
You could use special arbitrary values to indicate invalid data, but at that point you’re just doing null with extra steps right?
I’m really lost as to how the concept isn’t neccessary.
I’ll point to how many functional languages handle it. You create a type Maybe a, where a can be whatever type you wish. The maybe type can either be Just x or Nothing, where x is a value of type a (usually the result). You can’t access the x value through Maybe: if you want to get the value inside the Maybe, you’ll have to handle both a case where we have a value(Just x) and don’t(Nothing). Alternatively, you could just pass this value through, “assuming” you have a value throughout, and return the result in another Maybe, where you’ll either return the result through a Just or a Nothing. These are just some ways we can use Maybe types to completely replace nulls. The biggest benefit is that it forces you to handle the case where Maybe is Nothing: with null, it’s easy to forget. Even in languages like Zig, the Maybe type is present, just hiding under a different guise.
If this explanation didn’t really make sense, that’s fine, perhaps the Rust Book can explain it better. If you’re willing to get your hands dirty with a little bit of Rust, I find this guide to also be quite nice.
TLDR: The Maybe monad is a much better alternative to nulls.
Not quite, because the Maybe enum is neither int nor null, but it’s own, third thing. So before you can do any operations with the return value, you need to handle both cases that could occur
Isn’t that also true with compile-time type checking though? Eg. 0 + x where x is int|null would be detected? I don’t have much experience here so I could be wrong but I can’t think of a case where they’re not equivalent
Most languages that let you do ambiguous return types don’t do compile-time type checking, and vice versa. But if it’s actually implemented that way, then it’s logically equivalent, you’re right. Still, I prefer having things explicit
you could take a look at what Rust is doing with the Option enum. Superficially it looks similar to using null, but it actually accomplishes something very different.
A function that classically would return a value, say an int, but sometimes returns null instead, becomes a function that returns an Option. This forces explicit handling of the two cases, namely Some(value) or None. This way, it is next to impossible to try to do an operation on a value that does not exist.
When you’re interpreting a JSON request payload, how do you tell the difference between a property that’s not set and a property that is set to nothing? I.e. {"key":null} vs. {}. The former would be an instruction to clear the value and the latter is not set.
json is one of the old things we now just have to deal with, since JS and by extension json implement a null value. And for parsing arbitrary json data, I currently don’t have a good answer.
But when parsing a request payload, you usually know what properties to expect, and what types their values should be. Some keys are always present, for example UUIDs or other resource identifiers, and can therefore be directly parsed. But optional keys should be parsed differently, using Option Types. That way, you directly know what data type the field would have as well, if it were present. null in weakly-typed languages is especially bad in that regard, for example if you have something like this:
{"name":"Bob","year":1989}
and both fields are nullable, you would expect them to be different types, but if they are both null, suddenly they’re the same. The absence of a null type forces you to deal with optional values when parsing them, not when trying to do operations with them, which is the problem that null coalescing seeks to simplify.
I really like what Rust is doing in that regard, with the Option enum, and I know that functional programming languages like haskell have been doing it for a long time with their Maybe monad. I don’t think functional programming is accessible enough to challenge most of the current paradigms, but this is definitely a thing we can learn from them.
Who said anything about panicking the minute we encounter incomplete data? Just do what Rust does and, instead of having all types be able to be null, statically enforce that all variables have an initialized value and have a value have a separate type Option<T> which can either be Some(T) or None, and have the compiler not let you access the value inside unless you write code to handle the None case. There are standard library helper functions for common operations like null coalescing and, as you say, panicking when you encounter a null, but you have to explicitly tell the compiler you want to do that by calling myOption.unwrap()
What makes this really cool is that you can have an Option<Option<T>> where Some(None) is not the same as None, so an iterator that signals end of list by returning None can have None elements in it.
Say what you will about the functional programming people but they were spot on with this one. Having an Option monad in place of the ability for null is absolutely the way to go. I’d say it’s the future but Lisp and APL had this figured out in the 60s
Languages with null in them at all anymore just irk me. It’s 2023. Why are we still giving ourselves footguns.
Because I use a language that was invented more than 1 year ago
and it feeds me.
You use the language? Weren’t they just for bragging rights and blog posts?
Oh yeah I forgot, first you have to make a blog post, then a devlog, then review the top 10 best features of JS es6 (9 years after it was released…). Then
shitpost on social medianetwork for the other half of the week, and boom! You’re officially a Master Programmer!Because languages need to be able to handle the very common edge cases where data sources don’t return complete data.
Adding null coalescing to a null-safe language (like dart) is so much easier to read and infer the risk of handling null than older languages that just panic the moment null is introduced unexpectedly.
For old languages, null coalescing is a great thing for readability. But in general null is a bad concept, and I don’t see a reason why new languages should use it. That, of course, doesn’t change the fact that we need to deal with the nulls we already have.
How are we supposed to deal with null values though? It’s an important concept that we can’t eliminate without losing information and context about our data.
0 and “” (empty string/char) are very often not equivalent to null in my use cases and mean different things than it when I encounter them.
You could use special arbitrary values to indicate invalid data, but at that point you’re just doing null with extra steps right?
I’m really lost as to how the concept isn’t neccessary.
I’ll point to how many functional languages handle it. You create a type
Maybe a, whereacan be whatever type you wish. The maybe type can either beJust xorNothing, wherexis a value of typea(usually the result). You can’t access thexvalue throughMaybe: if you want to get the value inside theMaybe, you’ll have to handle both a case where we have a value(Just x) and don’t(Nothing). Alternatively, you could just pass this value through, “assuming” you have a value throughout, and return the result in anotherMaybe, where you’ll either return the result through aJustor aNothing. These are just some ways we can useMaybetypes to completely replace nulls. The biggest benefit is that it forces you to handle the case whereMaybeisNothing: with null, it’s easy to forget. Even in languages like Zig, theMaybetype is present, just hiding under a different guise.If this explanation didn’t really make sense, that’s fine, perhaps the Rust Book can explain it better. If you’re willing to get your hands dirty with a little bit of Rust, I find this guide to also be quite nice.
TLDR: The
Maybemonad is a much better alternative to nulls.Isn’t a Maybe enum equivalent to just using a return value of, for example,
int | nullwith type warnings?Not quite, because the Maybe enum is neither int nor null, but it’s own, third thing. So before you can do any operations with the return value, you need to handle both cases that could occur
Isn’t that also true with compile-time type checking though? Eg. 0 + x where x is int|null would be detected? I don’t have much experience here so I could be wrong but I can’t think of a case where they’re not equivalent
Most languages that let you do ambiguous return types don’t do compile-time type checking, and vice versa. But if it’s actually implemented that way, then it’s logically equivalent, you’re right. Still, I prefer having things explicit
Yes it is
One alternative are monadic types like result or maybe, that can contain either a value or an error/no value.
you could take a look at what Rust is doing with the Option enum. Superficially it looks similar to using null, but it actually accomplishes something very different.
A function that classically would return a value, say an int, but sometimes returns null instead, becomes a function that returns an Option. This forces explicit handling of the two cases, namely Some(value) or None. This way, it is next to impossible to try to do an operation on a value that does not exist.
When you’re interpreting a JSON request payload, how do you tell the difference between a property that’s not set and a property that is set to nothing? I.e.
{"key": null}vs.{}. The former would be an instruction to clear the value and the latter is not set.json is one of the old things we now just have to deal with, since JS and by extension json implement a null value. And for parsing arbitrary json data, I currently don’t have a good answer.
But when parsing a request payload, you usually know what properties to expect, and what types their values should be. Some keys are always present, for example UUIDs or other resource identifiers, and can therefore be directly parsed. But optional keys should be parsed differently, using Option Types. That way, you directly know what data type the field would have as well, if it were present. null in weakly-typed languages is especially bad in that regard, for example if you have something like this:
{ "name": "Bob", "year": 1989 }and both fields are nullable, you would expect them to be different types, but if they are both null, suddenly they’re the same. The absence of a null type forces you to deal with optional values when parsing them, not when trying to do operations with them, which is the problem that null coalescing seeks to simplify.
I really like what Rust is doing in that regard, with the Option enum, and I know that functional programming languages like haskell have been doing it for a long time with their Maybe monad. I don’t think functional programming is accessible enough to challenge most of the current paradigms, but this is definitely a thing we can learn from them.
Who said anything about panicking the minute we encounter incomplete data? Just do what Rust does and, instead of having all types be able to be null, statically enforce that all variables have an initialized value and have a value have a separate type
Option<T>which can either beSome(T)orNone, and have the compiler not let you access the value inside unless you write code to handle theNonecase. There are standard library helper functions for common operations like null coalescing and, as you say, panicking when you encounter a null, but you have to explicitly tell the compiler you want to do that by callingmyOption.unwrap()What makes this really cool is that you can have an Option<Option<T>> where
Some(None)is not the same asNone, so an iterator that signals end of list by returningNonecan haveNoneelements in it.Say what you will about the functional programming people but they were spot on with this one. Having an Option monad in place of the ability for null is absolutely the way to go. I’d say it’s the future but Lisp and APL had this figured out in the 60s
Because you can turn null into an Option monad with a small amount of syntax sugar and static analysis