3 ms·

> You have to be extremely dilligent about verifying input. That's true of all languages. Null references are a problem of low effort development. Calling it a

> You have to be extremely dilligent about verifying input. That's true of all languages. Null references are a problem of low effort development. Calling it a billion dollar mistake is sensationalist hand-wringing. It accidentally highlighted how carelessly most programs are written, implying that without it developers wouldn't be checking inputs as strictly, because they wouldn't need to. Yes it's another type, but lots of languages have a nil/null and there hasn't been a demonstrative reason to pull it.

smt88 7y ago
Well to be clear, most modern languages with reasonable type systems will force you to explicitly verify the type of your input. C#, for example, forces you to cast your JSON before using it. If the cast fails because you got the class definition wrong, you get an error (like a constructor error).
zeendo 7y ago
> there hasn't been a demonstrative reason to pull it" is not the reason it's not "been pulled Languages are hard to change and backwards compatibility is paramount. Hell, some languages support null just for interoperability (i.e. Scala) when they would have otherwise not allowed it when they were created. Null isn't expressive and is historical baggage. At this point "billion dollar" is probably an understatement. I wonder how many people that have spent significant time writing in languages that allow null and those that don't prefer having null? I, for one, wouldn't willingly go back to a language that allows null.
- perl4ever 7y ago
  Lots of languages have several ways to indicate an invalid value. With SQL, I generally prefer dialects where an empty string and null are considered the same, although that may be just due to what I learned first. Various Microsoft technologies seem to tend towards multiple ways of expressing null/missing/empty. An interesting thing about null in SQL is that the rule that any operation on a null returns null, only applies sometimes in some contexts. For instance in Oracle SQL: select max(case when x = 'ABC' then 'ABC' end) as y from ... ...is taking the maximum of an expression which is null whenever x <> 'ABC', yet it doesn't return null if there are rows where it does = 'ABC'. (sorry for any errors)
shitpostbot 7y ago
Almost all bugs could be called the result of "low effort development", but if there's a class of bugs that simply does not need to exist, why would you want to keep it around? The reason to pull Null is that it's easy to forget to check, and it causes bugs. Lots of bugs. Lots of wasted developer time. The real question is if there is any reason to keep it, and I'm pretty sure the answer is no. Expressing nullability in the type is an infinitely better solution.

smt88 7y ago

Well to be clear, most modern languages with reasonable type systems will force you to explicitly verify the type of your input. C#, for example, forces you to cast your JSON before using it. If the cast fails because you got the class definition wrong, you get an error (like a constructor error).

zeendo 7y ago

> there hasn't been a demonstrative reason to pull it" is not the reason it's not "been pulled Languages are hard to change and backwards compatibility is paramount. Hell, some languages support null just for interoperability (i.e. Scala) when they would have otherwise not allowed it when they were created. Null isn't expressive and is historical baggage. At this point "billion dollar" is probably an understatement. I wonder how many people that have spent significant time writing in languages that allow null and those that don't prefer having null? I, for one, wouldn't willingly go back to a language that allows null.

perl4ever 7y ago
Lots of languages have several ways to indicate an invalid value. With SQL, I generally prefer dialects where an empty string and null are considered the same, although that may be just due to what I learned first. Various Microsoft technologies seem to tend towards multiple ways of expressing null/missing/empty. An interesting thing about null in SQL is that the rule that any operation on a null returns null, only applies sometimes in some contexts. For instance in Oracle SQL: select max(case when x = 'ABC' then 'ABC' end) as y from ... ...is taking the maximum of an expression which is null whenever x <> 'ABC', yet it doesn't return null if there are rows where it does = 'ABC'. (sorry for any errors)

shitpostbot 7y ago

Almost all bugs could be called the result of "low effort development", but if there's a class of bugs that simply does not need to exist, why would you want to keep it around? The reason to pull Null is that it's easy to forget to check, and it causes bugs. Lots of bugs. Lots of wasted developer time. The real question is if there is any reason to keep it, and I'm pretty sure the answer is no. Expressing nullability in the type is an infinitely better solution.