111–120 of 147 posts
The entry for C++ in the final tables is:
C++ | NULL | boost::optional, from Boost.Optional
Here is what is wrong with Option. option.ifPresent(x -> System.out.println(x)); So instead of just checking to see if it is NULL you want me to create an instance of a specialized class that holds my variable that has a method that acts like an "if" statement that I need to pass an anonymous function to that receives the value I already have? Why not just do: x && System.out.println(x) or: System.out.println(x) if x…
> The one benefit I see is type safety but it is certainly not easier Type safety is one benefit, but composability is an important benefit (as, you know, is extensively discussed in the source article.)
"In fact, composibility is really the fundamental issue behind many of these problems. For example, the Store API returning nil for non-existant values was not composable with storing nil for non-existant phone numbers."
That's only because you invented some abstraction that got in your way in the first place. NULL is a perfectly acceptable value in dynamic languages and even in most document store databases.
Here is what is wrong with Option. option.ifPresent(x -> System.out.println(x)); So instead of just checking to see if it is NULL you want me to create an instance of a specialized class that holds my variable that has a method that acts like an "if" statement that I need to pass an anonymous function to that receives the value I already have? Why not just do: x && System.out.println(x) or: System.out.println(x) if x…
I think your failure to use Option correctly cannot be blamed on Option alone, given that many people use it successfully.
Earlier quoted context omitted.
> The right language design decision for these languages (managed languages like Java) might have been to make uninitialized references have a garbage value that reliably throws an exception when used (i.e. null) -- you can copy the reference and pass it around, but you can't compare it for equality and any attempt to inspect its value results in an exception. That's just a different kind of null. You still have the…
That is not an option. Things like arrays need to be allocated with a default initialization and then filled.
- Require an explicit initial value to be provided.
- Or require that a collection/iterator/generator of values be provided (and fail if it's not large enough).
- Or have a built-in ArrayBuilder type that accumulates all the needed values before allowing you to retrieve the array.
- Or make your language dependently typed, and change the signature of Array.get to take both an index and a proof that said index has been initialized.
Also, NULL pointers are the least problematic type of pointer if you ask me. If a pointer is NULL it is not likely a security problem, and certainly not on its own. Accidentally using a NULL pointer will cause a crash, but accidentally using any other pointer could cause unlimited damage.
I was with the article until the part about null terminators on strings. Null terminators are nothing like a NULL reference. We could just as easily have dollar-sign-terminated strings and no one would be conflating that idea with the concept of NULL. Also, NULL pointers are the least problematic type of pointer if you ask me. If a pointer is NULL it is not likely a security problem, and certainly not on its own. Acc…
> This is a bit different than the other examples, as there are no pointers or references. But the idea of a value that is not a value is still present, in the form of a char that is not a char.
It has nothing to do with the similarity in name (NULL / NUL). As you said, it could be terminated with $. The similarity is that they are both sentinel values. NULL is a sentinel for types; NUL is a sentinel for char arrays.
In both cases, they create exceptional and non-composable situations.
Good explanation here: https://www.reddit.com/r/programming/comments/3j4pyd/the_wor...
One of the problem's Maybe still has is in the deeper question of "why are you expecting None to be here?". Don't get me wrong, there are valid cases for this, and Maybe is certainly preferable to null across the board, but I think the movement to Maybe in the greater programming space will in many cases practically result in trading one set of explicit errors (crashes) for (a more subtle?) set of errors (behavioral)…
I don’t agree that lazy programmers will add optionality to please compilers rather than fix their program logic. In languages where optional types are ubiquitous, you usually see people avoiding needless optionality, because it’s simply easier.
Earlier quoted context omitted.
That is not an option. Things like arrays need to be allocated with a default initialization and then filled.
You can absolutely work around that: - Require an explicit initial value to be provided. - Or require that a collection/iterator/generator of values be provided (and fail if it's not large enough). - Or have a built-in ArrayBuilder type that accumulates all the needed values before allowing you to retrieve the array. - Or make your language dependently typed, and change the signature of Array.get to take both an inde…
Let's say you want an array of FileHandles. Under this proposal, you'd need to create an "empty" FileHandle value that you can use to fill arrays with and such. You'd have to create some "empty" state for every type. This is worse software engineering than having the possibility of a null pointer exception. (Also, you couldn't write generic code to implement an ArrayList efficiently without some way to generically default-construct the T to fill most of the array entries, or the constructor would have to take a filler value.)
- Or require that a collection/iterator/generator of values be provided (and fail if it's not large enough).
This is a needlessly complicated way to use an array, and it still has the same downsides.
- Or have a built-in ArrayBuilder type that accumulates all the needed values before allowing you to retrieve the array.
And how do you implement your own ArrayBuilder? What if you need something with a slower growth rate, or some other data structure that you could build out of an array with uninitialized elements, such as a deque?
- Or make your language dependently typed, and change the signature of Array.get to take both an index and a proof that said index has been initialized.
A far worse alternative.
Late edit: Generally speaking I think you're completely missing the problem of null pointers. The problem is not that a class of error exists. It's that people try to use null values in surprising ways in their APIs. If you make the null value impractical as a sentinel, you remove the mismatch between what programmers expect about whether a value can be null.
Earlier quoted context omitted.
> The one benefit I see is type safety but it is certainly not easier Type safety is one benefit, but composability is an important benefit (as, you know, is extensively discussed in the source article.)
Composability comes from functions, macros, and inheritance. What does that have to do with types? "In fact, composibility is really the fundamental issue behind many of these problems. For example, the Store API returning nil for non-existant values was not composable with storing nil for non-existant phone numbers." That's only because you invented some abstraction that got in your way in the first place. NULL is a…
(1) A cache returns something or NULL. It's generic; i.e. implementation doesn't care what it is storing: integers, strings, etc.
(2) A particular value of interest may be NULL or non-NULL.
But now I can no longer use my generic cache and my values of interest together.
A very real example of this is Java's Map interface. It's completely up to implementation on how they handle null, making interpreting null results difficult.
While often you use NULL and everything works, you're still limited to a certain set of circumstances. You can't pick up thing A and thing B and just use them together. Hence non-composable.