4 ms·

> But when your property changes from nullsafe to nullable, you need to rewrtiging eeevverything. Isn't the fact that you have to be explicit about null the ma

> But when your property changes from nullsafe to nullable, you need to rewrtiging eeevverything. Isn't the fact that you have to be explicit about null the main feature of explicit null safety?

tommyage 7y ago
Yes, it is, but the domain req. can change, requiring to handling an nullable result
- thu2111 7y ago
  Isn't that the one big situation where null safety really shines? Something that used to be required is now optional, so, you need to visit all the use sites to figure out what a sensible behaviour is when the data isn't there. Without null safety that could be quite tricky, especially when combined with type inference. The value could be stored and used only later, for instance. The compiler flagging where those fields are used without a null check is convenient, it tells you exactly where to insert new code to handle the missing data.
  - tommyage 7y ago
    Thank you, I shall be more precise when giving any comment. Honestly, I have not considered the advantages from null-safetyness (rated anything..) properly before posting. I just wanted to rant about kotlin, since i hear too many prayers about it and my gud (stomach) tells me different. I am not able to put it into words, yet. I really appreciate your hint. Anyway, you are absolutely right and I am glad @jach posted an link (above) regarding my intuition (@shoutout). When I learned programming (with Java, 3 yrs. ago) my mentor pointed out that i included too null-checks, even though i was familiar with the entire code base. Just after reading a post on this platform I realized his real intention: Sometimes (most often!) we needlessy check for null. Since then, forcing me to check anytime for null feels wrong and kotlin is forcing me to do so. Eventually I just wanted to mention downsizes which comes into my way when using kotlin daily.. Thankfully..!
    - thu2111 7y ago
      You're welcome!
- alexbanks 7y ago
  Exactly. The whole point of null safety is so that null becomes an explicit decision, rather than an implicit/accidental decision. If the requirements change, so should the code (aka you have to refactor the previously nullsafe code to now become nullable).
Jach 7y ago
You didn't quote the bit above that, "Null Safety is just overhead imho." Having to change all your types for that data is one reason he gives for that assertion. I don't have a hard stance on that, but I can see where he's coming from. My day job is all Java, and while we do occasionally have to deal with NPEs, they're just NPEs, not segfaults or things that can take down the whole program. They get caught and logged in a thread while the rest of the (server) app marches on. Programmatically, using Optional to signal intention of null as meaningful (and it is sometimes useful to have null as a meaningful "don't know" value, see http://john.freml.in/billion-dollar-mistake http://john.freml.in/billion-dollar-mistake) works well and isn't syntactically laborious. (Additionally Optional chaining with maps is much nicer than the old way of nested if-not-null checks, but sure a "?." operator or similar would be slightly nicer.) Common Lisp complects nil and false and the empty list '(), which originally annoyed me quite a bit, but after working with it more I see it as deeply pragmatic and it simplifies a lot of code while also making many types of annoying errors in other null-supporting languages either not relevant or much more trivial to fix. Additionally its OOP system has a function-call syntax of (method obj arg) instead of something like obj.method(arg) so in error logs you'll see "no applicable method for the generic function #method when called with arguments (nil arg)" (and in development you have the excellent condition system to resolve this without unwinding the stack and losing state, including the choice to define a method that explicitly handles a null object). But I don't see the programming language fashions moving any closer in that direction...

> But when your property changes from nullsafe to nullable, you need to rewrtiging eeevverything. Isn't the fact that you have to be explicit about null the main feature of explicit null safety?

tommyage 7y ago

Yes, it is, but the domain req. can change, requiring to handling an nullable result

thu2111 7y ago
Isn't that the one big situation where null safety really shines? Something that used to be required is now optional, so, you need to visit all the use sites to figure out what a sensible behaviour is when the data isn't there. Without null safety that could be quite tricky, especially when combined with type inference. The value could be stored and used only later, for instance. The compiler flagging where those fields are used without a null check is convenient, it tells you exactly where to insert new code to handle the missing data.
- tommyage 7y ago
  Thank you, I shall be more precise when giving any comment. Honestly, I have not considered the advantages from null-safetyness (rated anything..) properly before posting. I just wanted to rant about kotlin, since i hear too many prayers about it and my gud (stomach) tells me different. I am not able to put it into words, yet. I really appreciate your hint. Anyway, you are absolutely right and I am glad @jach posted an link (above) regarding my intuition (@shoutout). When I learned programming (with Java, 3 yrs. ago) my mentor pointed out that i included too null-checks, even though i was familiar with the entire code base. Just after reading a post on this platform I realized his real intention: Sometimes (most often!) we needlessy check for null. Since then, forcing me to check anytime for null feels wrong and kotlin is forcing me to do so. Eventually I just wanted to mention downsizes which comes into my way when using kotlin daily.. Thankfully..!
  - thu2111 7y ago
    You're welcome!
alexbanks 7y ago
Exactly. The whole point of null safety is so that null becomes an explicit decision, rather than an implicit/accidental decision. If the requirements change, so should the code (aka you have to refactor the previously nullsafe code to now become nullable).

Jach 7y ago

You didn't quote the bit above that, "Null Safety is just overhead imho." Having to change all your types for that data is one reason he gives for that assertion. I don't have a hard stance on that, but I can see where he's coming from. My day job is all Java, and while we do occasionally have to deal with NPEs, they're just NPEs, not segfaults or things that can take down the whole program. They get caught and logged in a thread while the rest of the (server) app marches on. Programmatically, using Optional to signal intention of null as meaningful (and it is sometimes useful to have null as a meaningful "don't know" value, see http://john.freml.in/billion-dollar-mistake http://john.freml.in/billion-dollar-mistake) works well and isn't syntactically laborious. (Additionally Optional chaining with maps is much nicer than the old way of nested if-not-null checks, but sure a "?." operator or similar would be slightly nicer.) Common Lisp complects nil and false and the empty list '(), which originally annoyed me quite a bit, but after working with it more I see it as deeply pragmatic and it simplifies a lot of code while also making many types of annoying errors in other null-supporting languages either not relevant or much more trivial to fix. Additionally its OOP system has a function-call syntax of (method obj arg) instead of something like obj.method(arg) so in error logs you'll see "no applicable method for the generic function #method when called with arguments (nil arg)" (and in development you have the excellent condition system to resolve this without unwinding the stack and losing state, including the choice to define a method that explicitly handles a null object). But I don't see the programming language fashions moving any closer in that direction...