4 ms·

No. Null is great and has no good alternative. The attack on null stems from: * Bad implementations of null handling * Functional programming which doesn't h

No. Null is great and has no good alternative. The attack on null stems from: * Bad implementations of null handling * Functional programming which doesn't handle null well Null itself is efficient. It has hardware/OS support and is literally zero overhead. It fails fast so you don't see nonsense like "undefined" columns or bad data in your database. When null fails in a good language you usually get a stack directly to your problem. You have one concept to follow through the code instead of multiple concepts. I'm not here to convince you. I'm a fan of OOP and you obviously won't agree with me on either. But claiming "all" or even most without data to back it means you live in a bubble.

deltaonefour 5y ago
> No. Null is great and has no good alternative. First off you don't know what you're talking about. The inventor of the concept of Null has this to say about Null: "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. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years." The attack on null stems from Tony Hoare the inventor hating on null. It also stems from programmers who know what they're talking about. >Null itself is efficient. It has hardware/OS support and is literally zero overhead. On x86-64, the general registers are simply bits that are mostly interpreted as integer values. They do not have additional states such as “null” in the sense of “not currently holding a value”. (Some architectures do have such additional states, and the floating-point registers in IA-32 can have such a state.) Unless the OS exposes it's own custom ISA (which they don't) then this is NOT an OS concept either. >When null fails in a good language you usually get a stack directly to your problem. You have one concept to follow through the code instead of multiple concepts. The argument against null stems from the fact that the failure wouldn't even exist in the first place if null didn't exist period. The language itself should statically handle undefined concepts via types. By moving all runtime errors to compile time errors you eliminate the need of even looking at the stack. Possibly the most extreme example of this is elm. It is not possible for the elm language to have ANY runtime errors. All errors that are otherwise runtime errors in C or C++ are caught as compiler errors in elm. >I'm not here to convince you. I'm a fan of OOP and you obviously won't agree with me on either. I'm not a fan of OOP or FP. I'm an unbiased observer. The argument your making here is not either OOP or FP. It's part of mathematics. Type theory. I have a type called int. Why do I have this entity called Null within the type that fails even though everything type checks? It's a violation of the type contract. Your argument is saying the violation is ok for practical purposes. I'm saying it's not. > But claiming "all" or even most without data to back it means you live in a bubble. All programmers know how to sort a list. Do I need data to back up that statement? Perhaps I'm wrong. There are programmers out there who don't know how to do this. I thought null being bad was as obvious as sorting a list. Guess there's one person out there who doesn't know it's bad. It's unreasonable for me to get "data" on a If you want data, the quote from the inventor of null is the best possible one.

deltaonefour 5y ago

> No. Null is great and has no good alternative. First off you don't know what you're talking about. The inventor of the concept of Null has this to say about Null: "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. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years." The attack on null stems from Tony Hoare the inventor hating on null. It also stems from programmers who know what they're talking about. >Null itself is efficient. It has hardware/OS support and is literally zero overhead. On x86-64, the general registers are simply bits that are mostly interpreted as integer values. They do not have additional states such as “null” in the sense of “not currently holding a value”. (Some architectures do have such additional states, and the floating-point registers in IA-32 can have such a state.) Unless the OS exposes it's own custom ISA (which they don't) then this is NOT an OS concept either. >When null fails in a good language you usually get a stack directly to your problem. You have one concept to follow through the code instead of multiple concepts. The argument against null stems from the fact that the failure wouldn't even exist in the first place if null didn't exist period. The language itself should statically handle undefined concepts via types. By moving all runtime errors to compile time errors you eliminate the need of even looking at the stack. Possibly the most extreme example of this is elm. It is not possible for the elm language to have ANY runtime errors. All errors that are otherwise runtime errors in C or C++ are caught as compiler errors in elm. >I'm not here to convince you. I'm a fan of OOP and you obviously won't agree with me on either. I'm not a fan of OOP or FP. I'm an unbiased observer. The argument your making here is not either OOP or FP. It's part of mathematics. Type theory. I have a type called int. Why do I have this entity called Null within the type that fails even though everything type checks? It's a violation of the type contract. Your argument is saying the violation is ok for practical purposes. I'm saying it's not. > But claiming "all" or even most without data to back it means you live in a bubble. All programmers know how to sort a list. Do I need data to back up that statement? Perhaps I'm wrong. There are programmers out there who don't know how to do this. I thought null being bad was as obvious as sorting a list. Guess there's one person out there who doesn't know it's bad. It's unreasonable for me to get "data" on a If you want data, the quote from the inventor of null is the best possible one.