5 ms·

I've come to the conclusion that in the generic business software world, removing null would be a trillion dollar mistake. Instead of applications simply crash

I've come to the conclusion that in the generic business software world, removing null would be a trillion dollar mistake. Instead of applications simply crashing, millions of hours would be wasted trying to clean up bogus values (e.g. "changeme", empty string, etc) from databases and calculate what should have been there instead.

eat_veggies 4y ago
do you see this a lot in industry codebases written in languages that have null safety?
jgilias 4y ago
I think you misunderstand what null safety really means. It’s not that values can’t be null/None/Empty. It’s just that it’s made explicit where this is the case and where it’s not the case. Without null safety everything is implicitly maybe null.
- KMag 4y ago
  In other words, the problem is that null is treated as if its class is a subclass of all classes. All of a sudden, you've introduced a superset of all of the problems with multiple inheritance. (Nulltype inherits from everything!) You've also made it nearly impossible to adhere to the Liskov substitution principle (unless none of your classes can do anything, making all object instances equivalent at runtime). In type theory, a type that is a supertype of all types is called a "top type" and a type that is a subtype of all types is a "bottom type". It's okay to have one or more bottom types in a type system, as long as it's not possible to create instances of them. Unfortunately, in most of the popular statically typed languages, null is an instance of a bottom type. One reasonable use of a bottom type would be to allow a variable to assume one of many types, and require a dynamically-checked upcast when actually passing that variable to a function that cared about its types.
anonyme-honteux 4y ago
Nobody is removing null because null itself is not the mistake. The mistake was to say like in Java that null is a valid value for every possible class under the sun. What Kotlin & cie are saying is that if your parameter is a RandomGenerator, null should not be allowed there because null is not a RandomGenerator. Null is null and that's it. If you search something in a map, your value will be of type "String?", that is "String | null" and that's completely fine, the compiler will assist you with that too.
- wizofaus 4y ago
  I'd even question whether a function whose job it is to "find" something should be able to return a Nullable value - or at least, it shouldn't be possible to just force such a value to be treated as an actual value (as is allowed by Swift/Kotlin/C# etc with "force unwrap" type operators). I'd rather see a language with built in support for functions that can either return one type or another, whereby the caller must provide two code paths to deal with each. And yes this would imply you could never simply call such a function and store its return value in a variable.
  - tadfisher 4y ago
    That was the initial intent behind Kotlin's Result<T> type; it was only allowed to be a return value from compiler-blessed functions (runCatching and friends) and was not allowed to be stored in a property. The problem became this additional function color; also, no language construct can prevent users from implementing "fun Result<T>.unwrap(): T" and crashing the program in the failure case. OK, you could also restrict functions that accept Result<T> (as a receiver or parameter), but now you force resolution of that type by the direct caller of the function returning Result<T>. So really this becomes a worse version of checked exceptions, which (thankfully) don't exist in Kotlin.

eat_veggies 4y ago

do you see this a lot in industry codebases written in languages that have null safety?

jgilias 4y ago

I think you misunderstand what null safety really means. It’s not that values can’t be null/None/Empty. It’s just that it’s made explicit where this is the case and where it’s not the case. Without null safety everything is implicitly maybe null.

KMag 4y ago
In other words, the problem is that null is treated as if its class is a subclass of all classes. All of a sudden, you've introduced a superset of all of the problems with multiple inheritance. (Nulltype inherits from everything!) You've also made it nearly impossible to adhere to the Liskov substitution principle (unless none of your classes can do anything, making all object instances equivalent at runtime). In type theory, a type that is a supertype of all types is called a "top type" and a type that is a subtype of all types is a "bottom type". It's okay to have one or more bottom types in a type system, as long as it's not possible to create instances of them. Unfortunately, in most of the popular statically typed languages, null is an instance of a bottom type. One reasonable use of a bottom type would be to allow a variable to assume one of many types, and require a dynamically-checked upcast when actually passing that variable to a function that cared about its types.

anonyme-honteux 4y ago

Nobody is removing null because null itself is not the mistake. The mistake was to say like in Java that null is a valid value for every possible class under the sun. What Kotlin & cie are saying is that if your parameter is a RandomGenerator, null should not be allowed there because null is not a RandomGenerator. Null is null and that's it. If you search something in a map, your value will be of type "String?", that is "String | null" and that's completely fine, the compiler will assist you with that too.

wizofaus 4y ago
I'd even question whether a function whose job it is to "find" something should be able to return a Nullable value - or at least, it shouldn't be possible to just force such a value to be treated as an actual value (as is allowed by Swift/Kotlin/C# etc with "force unwrap" type operators). I'd rather see a language with built in support for functions that can either return one type or another, whereby the caller must provide two code paths to deal with each. And yes this would imply you could never simply call such a function and store its return value in a variable.
- tadfisher 4y ago
  That was the initial intent behind Kotlin's Result<T> type; it was only allowed to be a return value from compiler-blessed functions (runCatching and friends) and was not allowed to be stored in a property. The problem became this additional function color; also, no language construct can prevent users from implementing "fun Result<T>.unwrap(): T" and crashing the program in the failure case. OK, you could also restrict functions that accept Result<T> (as a receiver or parameter), but now you force resolution of that type by the direct caller of the function returning Result<T>. So really this becomes a worse version of checked exceptions, which (thankfully) don't exist in Kotlin.