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