3 ms·

> Close to none so zero dollars were spent adding null safety to languages? False. Zero dollars were spent converting code to those languages? False. Zero do

> Close to none so zero dollars were spent adding null safety to languages? False. Zero dollars were spent converting code to those languages? False. Zero dollars were spent solving problems uniquely created by not having the benefits of null? Also false. > I'd take his expert opinion and experience on the matter over anybody referring to him as "a dude with a fancy name". Sounds like a crappy way to reason about facts. Just because he did cool shit once upon a time doesn’t mean that we should believe him when he pulls numbers out of his ass.

IshKebab 4y ago
"close to none" is not the same as "zero". But yes, converting Dart code to null safety is not very difficult.
- pizlonator 4y ago
  “Not very difficult” is not the same thing as “close to no cost”
  - coldtea 4y ago
    Is this about being obtuse on purpose? I could also do an immitation of a dumb pedantic person and just answer your "First, zero dollars were spent adding null safety to languages? False", with: "I didn't say "zero" I said "Close to none". So PWNED! or something equally immature. But one can also chose to be charitable. E.g. to understand that: > Zero dollars were spent converting code to those languages? False. Having null safety doesn't necessarily mean "converting". Could also mean not having nulls in a language to begin with. So "how many dollars does it cost to have null safety" in that case is zero. It's fixing the addition of nulls after the fact that can have a cost. Even so, the conversion to null safety is not that costly (it's nothing like a rewrite, more like going around a program and fixing SQL Injection cases or XSS). It also makes evident many logical and safety errors in the initial program when done (many teams have written about such experience), and any cost has to be offset with the cost of those errors not happening anymore. In any case, those are not costs of not having null to begin with in the language. They are costs of retrofixing code in ones that did have it. > Zero dollars were spent solving problems uniquely created by not having the benefits of null? Also false. There are no "problems uniquely created by not having the benefits of null". In fact, there are no "benefits of null" to begin with. > Sounds like a crappy way to reason about facts. Then again sounds like you didn't provide any facts. Just shown ignorance of computer science theory AND history, along with certainty and immature tone.
jamil7 4y ago
> Zero dollars were spent solving problems uniquely created by not having the benefits of null? This one doesn't make any sense in the context of the languages being discussed. What unique problems does it create in Swift/Kotlin/Rust?
Lewton 4y ago
> Zero dollars were spent solving problems uniquely created by not having the benefits of null? Also false. Do tell what those problems are? Whenever I hear people complain about this, they suffer from some fundamental misunderstanding of how null-safe languages work in practice
- gfxgirl 4y ago
  Not to defend the OP because I agree that null is bad. But, in my limited experiecne with Swift I just add a few characters at the right place and the null's are now incorrectly ignored and the warnings go away. So, the language gave me warning, but it didn't really force me to deal with it correctly. Is Swift a bad example of a null-safe language?
  - masklinn 4y ago
    What characters exactly? "!"? You literally tell it to break, a null-safe language will not actually prevent you from shooting your foot, it'll just make sure you do so knowingly. "foo!" is essentially a shortcut for guard foo else { fatalError() }
  - coldtea 4y ago
    It's a language that didn't go all the way to null-safety. But at least it did explicit (you HAD to add those characters) to get the unsafety than in C is the default.
    - masklinn 4y ago
      > It's a language that didn't go all the way to null-safety. Is it? I can’t think of any langage but Elm which doesn’t have that assertion. Though I guess e.g. Idris or ATS could have left out as well.
  - Lewton 4y ago
    > I just add a few characters at the right place and the null's are now incorrectly ignored and the warnings go away. So, the language gave me warning, but it didn't really force me to deal with it correctly. Personally I don't really see that as an issue, we're talking about null safe by default vs not safe by default. It being simple to break the null-safety is a good thing, as long as it requires you to do it deliberately

IshKebab 4y ago

"close to none" is not the same as "zero". But yes, converting Dart code to null safety is not very difficult.

pizlonator 4y ago
“Not very difficult” is not the same thing as “close to no cost”
- coldtea 4y ago
  Is this about being obtuse on purpose? I could also do an immitation of a dumb pedantic person and just answer your "First, zero dollars were spent adding null safety to languages? False", with: "I didn't say "zero" I said "Close to none". So PWNED! or something equally immature. But one can also chose to be charitable. E.g. to understand that: > Zero dollars were spent converting code to those languages? False. Having null safety doesn't necessarily mean "converting". Could also mean not having nulls in a language to begin with. So "how many dollars does it cost to have null safety" in that case is zero. It's fixing the addition of nulls after the fact that can have a cost. Even so, the conversion to null safety is not that costly (it's nothing like a rewrite, more like going around a program and fixing SQL Injection cases or XSS). It also makes evident many logical and safety errors in the initial program when done (many teams have written about such experience), and any cost has to be offset with the cost of those errors not happening anymore. In any case, those are not costs of not having null to begin with in the language. They are costs of retrofixing code in ones that did have it. > Zero dollars were spent solving problems uniquely created by not having the benefits of null? Also false. There are no "problems uniquely created by not having the benefits of null". In fact, there are no "benefits of null" to begin with. > Sounds like a crappy way to reason about facts. Then again sounds like you didn't provide any facts. Just shown ignorance of computer science theory AND history, along with certainty and immature tone.

jamil7 4y ago

> Zero dollars were spent solving problems uniquely created by not having the benefits of null? This one doesn't make any sense in the context of the languages being discussed. What unique problems does it create in Swift/Kotlin/Rust?

Lewton 4y ago

> Zero dollars were spent solving problems uniquely created by not having the benefits of null? Also false. Do tell what those problems are? Whenever I hear people complain about this, they suffer from some fundamental misunderstanding of how null-safe languages work in practice

gfxgirl 4y ago
Not to defend the OP because I agree that null is bad. But, in my limited experiecne with Swift I just add a few characters at the right place and the null's are now incorrectly ignored and the warnings go away. So, the language gave me warning, but it didn't really force me to deal with it correctly. Is Swift a bad example of a null-safe language?
- masklinn 4y ago
  What characters exactly? "!"? You literally tell it to break, a null-safe language will not actually prevent you from shooting your foot, it'll just make sure you do so knowingly. "foo!" is essentially a shortcut for guard foo else { fatalError() }
- coldtea 4y ago
  It's a language that didn't go all the way to null-safety. But at least it did explicit (you HAD to add those characters) to get the unsafety than in C is the default.
  - masklinn 4y ago
    > It's a language that didn't go all the way to null-safety. Is it? I can’t think of any langage but Elm which doesn’t have that assertion. Though I guess e.g. Idris or ATS could have left out as well.
- Lewton 4y ago
  > I just add a few characters at the right place and the null's are now incorrectly ignored and the warnings go away. So, the language gave me warning, but it didn't really force me to deal with it correctly. Personally I don't really see that as an issue, we're talking about null safe by default vs not safe by default. It being simple to break the null-safety is a good thing, as long as it requires you to do it deliberately