31–40 of 147 posts
Though I'm not sure if that problem is really that huge. Bad code will break in many ways. And breaking on nulls usually isn't that dangerous, data isn't corrupted and stack is safe.
There's another mistake of computer science in my opinion is inefficient array bounds checking and implicit integer overflow behavior. And those mistakes are more dangerous, they lead to data corruption and exploits.
class Connection {
//Error instances
BAD_ADDR("The given address was not correct...")
...
}
Try/catch has its place, but the persistence of null-as-error-state behavior among programmers shows that signalling-via-return-value is a practical and intuitive way to handle error states. We should make that better, rather than simply tipping our nose at null.
For statically typed languages this is definitely an issue, but for dynamic languages less so. In Python, I wouldn't use an optional value, x is None seems to be just fine. I'm still waiting for std::optional for C++.
In fact, the example in the article of the Ruby K/V store illustrates this problem. If optional values were used instead of an ambiguous nil for both cases, there would be two distinct results:
* Some(nil) -- or something of similar shape -- where there is a value for the key, and it is nil,
* nil where there is no value.
Obviously, the typesafety issue doesn't exist for dynamic languages, but the composability/API quality issues do -- from the numbered issues in the article, I'd say at least #s 2, 3, 4, and 7 apply to dynamic languages in general.
Python's problem, meanwhile, is that any parameter could be any type. In C, you can pass NULL to a function expecting a non-null string. In Python, you can also pass 42, [], or the sqlalchemy module. None isn't special here. :)
Also, to quibble a bit: Rust's std::ptr::null() is just a raw pointer, and isn't actually usable in safe Rust. Actual safe pointer types are guaranteed non-null and you'd use Option to specify that they're nullable. Raw pointers cannot be dereferenced in safe Rust. It is true that std::ptr::null() is in Rust's standard library, but Foreign.Ptr.nullPtr is in Haskell's, and the purpose is the same (a special raw-pointer type only used for FFI purposes), so Rust isn't any worse than Haskell here.
Rust doesn't have null, but it has Option, which is often syntactic sugar for null.
It's not that null is bad in itself. It's that having variables which might be null need to be distinguished from ones which can't be null.
NULL is okay as long as you pretend it doesn't exist. I mean, in these languages, uninitialized variables exist at some point (fields start uninitialized in constructor bodies, etc), and that's why there's null, instead of defining them with some garbage value that has undefined behavior. But the right solution for users is to just pretend that it can't exist, and that uninitialized variables have a garbage value. Of…
Uglier than a Windows backslash, odder than ===, more common than PHP, more unfortunate than CORS, more disappointing than Java generics, more inconsistent than XMLHttpRequest, more confusing than a C preprocessor, flakier than MongoDB, and more regrettable than UTF-16, the worst mistake in computer science was introduced in 1965. That could be the greatest intro sentence ever seen on Hacker News.
Pretty good, but I've never had a problem with an XMLHttpRequest being inconsistent. Everything else seems spot-on though.
I agree with the article, yet, despite what the table at the end suggest I got significantly less problems with NullPointerExceptions since I switched from Java to C++ for my work. C++ has an inbuilt alternative: references. References in conjunction with the Null Object Pattern have solved my problems until now. References simply cannot be null -- and I generally do not use raw pointers in my code unless some librar…
We don't need to get rid of null, we need more, type-specific and context-carrying nulls: types need a way to signal various error states via an enumeration of instance constants that carry the error state in a type-compatible manner without some syntactically crappy mechanism like Maybe. class Connection { //Error instances BAD_ADDR("The given address was not correct...") ... } These constants should throw, just lik…
Sounds like you want to go a step beyond Maybe to Either.
Earlier quoted context omitted.
nil really isn't any better than null-pointers/references. In the end, you need to check for nil-ness anyway, and there's no mechanism that will help you ensure the check is made. Algebraic data types with pattern matching, that is, Maybe/option is really the proper solution.
NIL is objectively, unquestionably safer than a raw machine pointer that is null. It's a first class object with a type; a symbol with a name, and instance of the NULL class and so on. Of course, if you want to use NIL as a character string or floating-point value, there is an exception. That's your fault: you needed a way to indicate "I don't have a string here" or "I don't have a number", and you bungled the logic.
And there's the rub: Just like NULL. And, in fact, that's the major problem with NULL. NIL is better than NULL, but not by much.