One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
Interestingly they didn't do this mistake for boolean which can only be true or false but never null. I prefer when booleans have only two values. Don't you?
Let say the type String does not accept null like in Kotlin
Let say you don't like the letters "n-u-l-l" so you define a singleton Absent instead when something is not in a map.
Let say you have union types, so you define type StringOrAbsent = String | Absent
At that point you realize being interoperable with Java would be very important, so you give up Absent and use type StringOrNull = String | null
At that point you realize that's a very common use case and you implicitely define String? as being String | null... and do the same for all types
At that point you build lots of clever syntax shorthands to work with null. Adding null safety to the language doesn't make it more cluncky like Option anymore and people love it.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
Boolean doesn't accept null because it's a primitive?
That's the technical reason yes.
My point is that it's the right thing to do. Only the worst psychopaths use nullable "booleans", an insult to mathematical sanity.
Again, you described an option type hidden behind smart syntax.
No I'm not. Option<String> is a monad (aka it has .map() and .flatmap()), it's stored as wrapper class in memory. String and String? on the other hand is more like a union type. The values are stored just as string, no memory allocation.
That's not null people talk about when saying that null is a billion dollar mistake.
I happen to have referenced Tony Hoard's exact quote in an article
I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement.
That goal is perfectly implemented in a type system that allows null but only explicitly, and then it has to be handled safely. Not implicitly, and everywhere, and good luck.
Null-Pointers (think C) are a necessary foot-gun because the language needs the low-level concept to be both performant and simple. Pointers, in this context, are just numbers that we interpret as memory addresses, and numbers can be 0.
Null-Objects, on the other hand, make no sense at all. If your variable if a User, and your User class has a name attribute, your variable should necessarily always have that name attribute.
Nullable Types, that is, union types with a special non-value type, make about as much sense as union types in general: it's debatable whether they are a good idea, but they work well for real-life programming. The point is that no sane type system will let you put something nullable where a non-nullable type is expected, which mostly fixes the footgun problem.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
The compiler of any statically typed language that doesn't replicate Java's error of allowing 'null' (not present) as a valid member of all types.
Typescript is a good example.
And for me Kotlin
Null safety | Kotlin
I don't know Kotlin a lot, bit from reading these docs it looks like a "nullable type" is in fact an option type, but hidden behind a smart syntax.
This is a core feature of a
null. Taking something different and calling itnulldoes not change the original sentiment towardsnullin my opinion.It's strange to say that a mistake is a feature.
Interestingly they didn't do this mistake for
booleanwhich can only betrueorfalsebut nevernull. I prefer when booleans have only two values. Don't you?Stringdoes not acceptnulllike in KotlinAbsentinstead when something is not in a map.type StringOrAbsent = String | AbsentAbsentand usetype StringOrNull = String | nullString?as beingString | null... and do the same for all typesNot at all. Lots of languages and frameworks have features that are mistakes.
Because it's a primitive? Primitives cannot be
null, IIRC from writing Java some 10 years ago. ButBooleancan benull.Again, you described an option type hidden behind smart syntax. That's not
nullpeople talk about when saying thatnullis a billion dollar mistake.That's the technical reason yes.
My point is that it's the right thing to do. Only the worst psychopaths use nullable "booleans", an insult to mathematical sanity.
No I'm not.
Option<String>is a monad (aka it has.map()and.flatmap()), it's stored as wrapper class in memory.StringandString?on the other hand is more like a union type. The values are stored just as string, no memory allocation.I happen to have referenced Tony Hoard's exact quote in an article
Android's billion-dollar mistake(s)
Jean-Michel Fayard 🇫🇷🇩🇪🇬🇧🇪🇸🇨🇴 ・ Sep 25 '19 ・ 10 min read
That goal is perfectly implemented in a type system that allows null but only explicitly, and then it has to be handled safely. Not implicitly, and everywhere, and good luck.
I think you're kind of talking past each other.
Null-Pointers (think C) are a necessary foot-gun because the language needs the low-level concept to be both performant and simple. Pointers, in this context, are just numbers that we interpret as memory addresses, and numbers can be 0.
Null-Objects, on the other hand, make no sense at all. If your variable if a
User, and yourUserclass has anameattribute, your variable should necessarily always have thatnameattribute.Nullable Types, that is, union types with a special non-value type, make about as much sense as union types in general: it's debatable whether they are a good idea, but they work well for real-life programming. The point is that no sane type system will let you put something nullable where a non-nullable type is expected, which mostly fixes the footgun problem.
Perfect summary,, completely agree 💪🏻