81–90 of 377 posts
http://www.dbdebunk.com/2017/04/null-value-is-contradiction-...
Codd never proposed it in his original relational model. For good reason.
Isn't there an inherent need in programming to express an explicit "nothing" value? Coming from Python and JS, I never found None/null to be much of a problem. I in fact like the distinction of null and undefined in JS. Using null allows you to distinguish from the accidental undefined.
> Isn't there an inherent need in programming to express an explicit "nothing" value? In numerical calculus: yes, most certainly. What do you expect the result of log(-1) to be? The alternative is to use specially tagged particular numbers as "no-data", and pray so that they do not appear naturally as the result of computations.
Isn't there an inherent need in programming to express an explicit "nothing" value? Coming from Python and JS, I never found None/null to be much of a problem. I in fact like the distinction of null and undefined in JS. Using null allows you to distinguish from the accidental undefined.
previously: https://news.ycombinator.com/item?id=11798518
https://news.ycombinator.com/item?id=10148972 (150 points | Aug 31, 2015 | 143 comments)
Isn't there an inherent need in programming to express an explicit "nothing" value? Coming from Python and JS, I never found None/null to be much of a problem. I in fact like the distinction of null and undefined in JS. Using null allows you to distinguish from the accidental undefined.
In C++ I practically never feel like I need a null for anything but a pointer. A null string or integer makes no sense to me.
NULL in 'relational' databases in particular is a disaster. Or at least according to the notorious Fabian Pascal. http://www.dbdebunk.com/2017/04/null-value-is-contradiction-... Codd never proposed it in his original relational model. For good reason.
NULL is just another case of a state of a variable. Other states are 1, 15, 0xffffffff, etc.
That mainstream languages don't handle this is the worst mistake of the computer industry.
NULL is a convenient way to map singularities in your model of the problem. I have on a few occasions tried to write NULL-less code, and it adds a good bit of work. - model all possible states for a value - determine appropriate default actions for all types - meaningful place-holder values It's a good exercise, and I think more code should be written this way, but - as an Engineer I'm trying to model just enough of…
> I have on a few occasions tried to write NULL-less code, and it adds a good bit of work. Really depends on the language. On Java / C#, it's hard to avoid null-checking a lot of stuff. In C++ you will never encounter a null std::string outside of code written by indian students learning on Turbo C++ 3.5. So you don't need to check for anything: if it's a value, it exists.
NULL is a convenient way to map singularities in your model of the problem. I have on a few occasions tried to write NULL-less code, and it adds a good bit of work. - model all possible states for a value - determine appropriate default actions for all types - meaningful place-holder values It's a good exercise, and I think more code should be written this way, but - as an Engineer I'm trying to model just enough of…
Have you ever dealt with the Maybe(Haskell)/Option(F#) types? If not, then you don't understand what's wrong with NULL and how to easily avoid it without much work.
They are still NULLs however under the hood and I still need to do the work of defining what I want to happen when they occur. It's just neater.
NULL in 'relational' databases in particular is a disaster. Or at least according to the notorious Fabian Pascal. http://www.dbdebunk.com/2017/04/null-value-is-contradiction-... Codd never proposed it in his original relational model. For good reason.
Furthermore you need to represent missing values somehow if you perform a left join.