21–30 of 377 posts
I wonder whether the author also hates the 0 and 1 elements of natural numbers. Since they have the same flaw of having weird, special semantics that all other other numbers don't share. In fact 0 is not even a number, but a placeholder for the concept of the absence of a number. Just like NULL.
But other than that, excellent point about the wonkiness of special values.
"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. – Rob Pike" When d…
> When did computer science become about hand holding? When people with pragmatic goals want to get large teams of new programmers productive fast, and can't expect everyone to be able to fend on their own or can afford the cost of accumulated mistakes. > Look at react. It was designed to force functional programming concepts in an OOP manner. Whatever that means, as React has little to do with "OOP manner".
I think it's a bit unlikely we'll fully get rid of null, but we can get rid of some of the pitfalls. TypeScript for example pretty much fixes the problem, by enforcing you check for null when needed, though TypeScript takes a handful of other soundness shortcuts. Go makes null less harmful by treating nil pointers like empty values by convention.
Why can't people just get over it and stop blaming the language for their own sloppy code?
Nulls in strongly typed languages can get rather weird but from a C/C++ perspective it is the same as 0. nullptr is just a correctly casted 0.
Actually nullptr is a struct.
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 the problem to solve it. I'm not trying to simulate every possible outcome in that domain.
Certain corners of your problem simply don't need to be modeled, and what's more the effort needed to model them can just be too much.
NULL is a great way to just throw up your hands and go "I don't know and I don't care". Much as when modelling a physical system singularities typically represent phenomena that the model doesn't take account of, so it goes with NULL. It simply says "Don't Go There".
Java's Optional seems fundamentally flawed in that Java allows any reference to hold a null value and Optional can still throw a NPE when calling isPresent on it so it still gives people a footgun.
> it means that C-strings cannot be used for ASCII or extended ASCII. Instead, they can only be used for the unusual ASCIIZ. This is a very pedantic quibble, and I'm not even sure it's correct. ASCII has NUL as well, and ASCIIZ isn't a character set AFAIK. > C++ NULL boost::optional, from Boost.Optional First of all, nullptr, second, std::optional. > Objective C nil, Nil, NULL, NSNull Maybe, from SVMaybe Nil is not a…
Also, Nil is absolutely a thing in Objective-C: it is a null pointer of type Class (whereas nil is a null pointer of type id; you should avoid mixing them up, though I will admit nothing much bad will happen as Class and id are generally co-polymorphic due to the type system being kind of lame. I am not sure they always have to be, though).
(And as someone who has been programming in C++ since before it was standardized at all, I frankly think listing NULL and boost::optional is totally acceptable and complaining about it as if C++11 is more canonical is just being annoying.)
Doing a quick search for how nil works in Swift, it apparently isn't a null pointer, so you are wrong there as well :(.
> nil means "no value" but is completely distinct in every other sense from Objective-C's nil.
> It is assignable only to optional variables. It works with both literals and structs (i.e. it works with stack-based items, not just heap-based items).
> Non-optional variables cannot be assigned nil even if they're classes (i.e. they live on the heap).
> So it's explicitly not a NULL pointer and not similar to one. It shares the name because it is intended to be used for the same semantic reason.
Given that I don't think any of the rest of your comment was legitimate criticism, I am frankly betting that your comment about UnsafePointer is also not useful, but I am kind of tired of having to analyze this comment at this point (I stepped in due to the note about character sets and the floor kept sinking).
I wonder whether the author also hates the 0 and 1 elements of natural numbers. Since they have the same flaw of having weird, special semantics that all other other numbers don't share. In fact 0 is not even a number, but a placeholder for the concept of the absence of a number. Just like NULL.
I can assure you that the number 0 in 0℃ is a number and not the absence of temperature. But other than that, excellent point about the wonkiness of special values.
If we're going to get pedantic ...
0 in this case is an offset. The number is what's behind it: The point at which water freezes (aka 273 °K).
In this case 0 indicates the absence of any offset.