I think the nullable reference type system in c# is a perfectly workable compromise for languages that had nullability from the very beginning. Once a code base uses them fully, most null-related bugs are gone. And it’s far from an unwieldy bolt-on.
It's funny because I really dislike the C# approach. It's not truly enforced - any code with nullable disabled can call public functions with `null`, even if on your side they were marked as non-null.
Yes, that is possible but you still get warnings and you should compile with warnings as errors anyway.
Kotlin makes nullability part of the typesystem. It's a good reference for what would happen if Java did this better because if you are using Java you can just switch to Kotlin and experience this in your own code base (you can mix Java and Kotlin code easily). You can actually write extension functions for nullable types and calling them on a null value does not cause a Nullpointer exception. This also works with Ja…
CharSequence?.isNullOrBlank()
In java I can make my own static function
isNullOrBlank(String input)
Which works on nulls too, right?
It's annoying to have to reference another class - but otherwise it's not much less ergonomic.
Kotlin makes nullability part of the typesystem. It's a good reference for what would happen if Java did this better because if you are using Java you can just switch to Kotlin and experience this in your own code base (you can mix Java and Kotlin code easily). You can actually write extension functions for nullable types and calling them on a null value does not cause a Nullpointer exception. This also works with Ja…
But null is still null, a very special non-reference signifying absence. And not some pretend-object that walks like a valid reference, swims like a valid reference, but somehow doesn't quite quack like one. The problems surfacing as an NPE don't magically go away by null-less approaches, they just bite you at different times, in different form. Sometimes sooner, which is good, but sometimes also later. Java made null worse by not taking nullability into the type system (these days nullability annotations do a tolerable job at pretending it was) and lacking scope functions that make it easy to check without the eyesore of flooding local scope with names. Kotlin is really awesome for not falling into the trap of chasing the pipe dream of a world without absence.
Kotlin makes nullability part of the typesystem. It's a good reference for what would happen if Java did this better because if you are using Java you can just switch to Kotlin and experience this in your own code base (you can mix Java and Kotlin code easily). You can actually write extension functions for nullable types and calling them on a null value does not cause a Nullpointer exception. This also works with Ja…
CharSequence?.isNullOrBlank() In java I can make my own static function isNullOrBlank(String input) Which works on nulls too, right? It's annoying to have to reference another class - but otherwise it's not much less ergonomic.
You can, you can even call the kotlin version that way if it happens to be on the classpath, but it's truly horrible ergonomics if for every call you have to guess between class-ref-otherargs and ref-otherargs forms. It's one of those little cuts you grow numb to.
The problem isn't really that null isn't an object, it's that the type system allows any object reference of a particular class to also be null. After using Typescript for the past couple years, it's such a joy when you define a variable of type Foo and know it won't contain null. Granted, TS also has to deal with undefined vs null weirdness (and even more weirdness in that an object not containing a property is subt…
Seeing all this discussion reinforces the idea that no new programming language should have this "every type implicitly contains null" thing
Yes, sum types and generics solve this nicely.
It's a shame Java was designed before they had generics, so the core of the language can't take advantage of them.
Kotlin makes nullability part of the typesystem. It's a good reference for what would happen if Java did this better because if you are using Java you can just switch to Kotlin and experience this in your own code base (you can mix Java and Kotlin code easily). You can actually write extension functions for nullable types and calling them on a null value does not cause a Nullpointer exception. This also works with Ja…
CharSequence?.isNullOrBlank() In java I can make my own static function isNullOrBlank(String input) Which works on nulls too, right? It's annoying to have to reference another class - but otherwise it's not much less ergonomic.
CharSequence is the base class that things like java.lang.String inherit. So I understood that as an instance method you can call like "foo".isNullOrBlank() (in Kotlin syntax)
I think the nullable reference type system in c# is a perfectly workable compromise for languages that had nullability from the very beginning. Once a code base uses them fully, most null-related bugs are gone. And it’s far from an unwieldy bolt-on.
I think there is a way to migrate to an union type myType | null. Instead.
Union types are pretty ugly.
Eg they can't distinguish between one or two layers of nullable. Or between null and an optional null.
(In eg Rust syntax between `Option>` vs `Option`. Or `()` vs `Option`, where `()` would be how you spell `null` in Rust.)
Ruby has a `NilClass` and the best/worst part of it is the to_s is "", to_i is 0, to_f is 0.0, to_a is [], to_h is {} It's incredibly clean and convenient until you wake up one morning and have no idea what is happening in your code
I dont think there is something wrong with that once you think about what is a Null Element (or identity) in a group that is represented by a set of elements and a function: Integer, + => 0 Float, + => 0.0 Array, add => [] Hash, merge => {} and so on. I think maybe we can debate the operations/functions, but they make sense. For Integer in some ways you can define almost all other operations that you commonly use bas…
Integers support both addition and multiplication and taking maximum and minimums, and a few other semi-group operations. Do you want to define different Null elements for all of them?
We already have None in e.g. Python but that merely means that "x.mathod_name()" instead of throwing a NullPointerException raises an AttributeError, because None has no method "method_name". Okay? Not really any meaningfully different.
Just use Kotlin. I'm honestly not seeing any need nor benefit in writing Java anymore.
I‘d say its the other way around, Java is closing the gap, and I say that as a Kotlin fan. Nullability in the type system is the big remaining advantage.
Scope functions are still huge. Yes, deep let chains can certainly be considered an antipattern (sometimes I like the approach of writing them, then transforming to more imperative for readability, I think readability peaks at a mix of imperative with some shallow .let), but I miss them in any language that is not kotlin.
Variables should be the exception, not the norm. I have no patience for names that designate some fluid work in progress instead of a value.