| |||||||||||||
GCC 4.6.0 releasedGCC 4.6.0 releasedPosted Mar 28, 2011 20:43 UTC (Mon) by HelloWorld (guest, #56129)In reply to: GCC 4.6.0 released by cmccabe Parent article: GCC 4.6.0 released
Primitive types are only a "problem" if you're the kind of person who alphabetizes his sock drawer. Actually, Javas primitive types led to numerous problems. It made wrapper classes necessary, which in turn made autoboxing necessary as it's a PITA to use otherwise. And autoboxing leads to subtle bugs for example in conjunction with the :? operator. You also still can't say ArrayList<int>, making Java harder to teach and learn than necessary. And there's another more subtle problem. Primitive types were introduced because using a heap-allocated object for every int variable seemed too costly at the time. But if you think about it, allocating ints on the heap wouldn't have been necessary. The Integer class is immutable, and if something is immutable, it doesn't matter if you pass it by value or by reference, so they could have made it so that integers are passed around by value instead of references to heap-allocated integers. The only reason that doesn't fly is that Integer is nullable while int is not. So, if the Java designers had thought properly about whether primitive types were really needed, they may have figured out that nullable values are a dumb idea. Oh, and let's not mention the fact that Java still doesn't allow operator overloading (except for, somewhat bizarrely, the String class). Perhaps most important of all, primitive types show that the Java designers just had no taste. Dijkstra was right when he said that elegance is not a dispensable luxury, but the Java designers clearly didn't grok that. Non-nullable pointers may or may not be a good thing.Nullable pointers are obviously a bad thing, as their effect of making something optional can be trivially obtained without a special language feature and on the other hand, NullPointerExceptions are a frequent source of bugs. If you want to know what Java cleaned up, check out: http://yosefk.com/c++fqa/defective.htmlMost of that is utterly pointless ranting about C++ being a systems programming language. That said, there are a few problems in C++ that Java doesn't have (grammar, lack of a module system). But Java fixed too few of C++'s mistakes (and introduced too many stupid mistakes on its own) to call it a cleaned-up version of C++.
(Log in to post comments)
GCC 4.6.0 released Posted Mar 28, 2011 22:41 UTC (Mon) by cmccabe (guest, #60281) [Link]
> Actually, Javas primitive types led to numerous problems. It made wrapper
> classes necessary, which in turn made autoboxing necessary as it's a PITA > to use otherwise...
Google Go has primitive types. However, you can add methods to them exactly the same way that you can add methods to structures. So you can do:
type foo []int
func (f foo) DoSomething();
The fact that Java needs wrapper classes for this, and for other things, is a design limitation of Java, not of primitives themselves. It comes directly out of the inheritance-based design.
As far as "Java autoboxing" goes, I have always hated it. Hated it when they added it to the language, still hate it now. When the compiler starts implicitly generating functions for you like that, it's time to get out the barf bag.
> Nullable pointers are obviously a bad thing, as their effect of making
Having a bool type is "obviously a bad thing," as you can obtain the same effect with ints. Oh wait, that argument is bogus.
This is just more "argument by assertion" on your part. I find NULL, or nil, or None, or whatever you call it, to be useful more often than it is not. And when I don't have it, I usually have to create some kind of special class value to represent "zero" which is usually just an annoyance.
The real WTF in Java is the lack of unsigned types, based no doubt on an argument similar to yours: it's "obviously a bad thing" to have uint32_t, because you can just use int64_t if you need 32 bits. Except for a little thing called efficiency, and who needs that?
RE: nullable pointers Posted Mar 28, 2011 23:56 UTC (Mon) by nybble41 (subscriber, #55106) [Link]
Nullable pointers aren't bad because there are other ways of representing them, obviously. They aren't even bad because they're a special language feature. No, they're bad because they allow every pointer to potentially be null, even where an object should not be optional; ergo the problem with omnipresent null pointer dereference exceptions.
RE: nullable pointers Posted Mar 29, 2011 23:32 UTC (Tue) by neilbrown (subscriber, #359) [Link]
I'm having trouble understanding the argument against nullable pointers. Can anyone point me at a good treatise on the subject?
I can see some value in allowing a pointer to be declared non-nullable - a bit like 'const' in C, it might catch a few errors and it explicitly documents an intention so there could be is value (though I tend to find 'const' more annoying than helpful).
But when you really want a nullable pointer, as you do in a linked list or any tree data structure, arbitrarily not allowing one seems pointless.
Or am I misunderstanding something?
RE: nullable pointers Posted Mar 31, 2011 3:46 UTC (Thu) by deweerdt (subscriber, #18159) [Link]
I think that much of those seemingly unsubstantiated claims against nullable pointers come from this: http://www.infoq.com/presentations/Null-References-The-Bi...
RE: nullable pointers Posted Mar 31, 2011 10:48 UTC (Thu) by neilbrown (subscriber, #359) [Link]
Thanks for that link!!
If I understand the argument correctly, it goes like this:
1/ A null pointer is a known address that doesn't actually point to an object of the expected type. It points to something else, but should never be dereferenced.
If I am right, then:
So I see absolutely no problem in a modern language allowing a NULL pointer, though certainly supporting non-NULLable pointers is very appropriate. And every runtime should check for dereferences of NULL (preferrably in hardware) and raise and exception when it happens. But I'm sure they do.
RE: nullable pointers Posted Mar 31, 2011 11:16 UTC (Thu) by paulj (subscriber, #341) [Link]
Agree.
NULL pointers are a red-herring. If we're talking about C level languages, then a NULL pointer dereference is a *good* kind of mistake - it's a clear error and causes an immediate exception at runtime, as you say. Much, much more insidious in C-level-akin languages is stale pointers and code continuing to twiddle memory that no longer references the state it thinks it should. Give me an immediate segfault over bugs which only cause crashes later, in unrelated code, any day! Further, even in managed-runtimes and with non-nullable types, you *still* can have stale references that cause bugs (which can still be hard to debug, even if it manages to better protect state from being corrupted).
The problem is just so much more fundamental: The correct management of the lifetime of state, and the co-ordination of visibility of that state.
(Functional programmers would of course argue the problem is best solved by never sharing state, only ever copying and transforming it. Course, while that removes scope for many kinds of crash-causing bugs, it still can't remove higher-level, logical mistakes..).
RE: nullable pointers Posted Mar 31, 2011 14:55 UTC (Thu) by deweerdt (subscriber, #18159) [Link]
Yes, I think some people extrapolated the title and created this internet rumor that simply switching to non-nullable pointers would automagically resolve all sorts of problems.
RE: nullable pointers Posted Mar 31, 2011 19:56 UTC (Thu) by HelloWorld (guest, #56129) [Link]
I don't agree with your interpretation of Hoare's talk. In the beginning, he says that Algol, unlike other languages at the time, checked array subscripts at runtime, which he thought of as a good idea, even though it was slow. So clearly, efficiency wasn't his primary concern.
He explains later on why he added null, and what it boils down to is that he didn't know how to do better.
RE: nullable pointers Posted Apr 1, 2011 3:58 UTC (Fri) by neilbrown (subscriber, #359) [Link]
It is very possible that my interpretation of Hoare's talk is flawed. It was a very unsatisfying talk, and I got the impression that he wasn't really expecting to give it and so wasn't really prepared. He said something about expecting to be part of a panel of people all sharing their "greatest mistakes" and went to some effort to get people in the audience to contribute - to argue for or against - to make it a more substantial discussion. So it would almost certainly be unfair to assess Tony Hoare's really thoughts based on that talk.
For the moment however that is all we have, and to my mind it came across a lot like the proverbial dot-com-boom business plan which you might remember as:
In this case it is
1 - Invent the NULL pointer
In both cases there is no clear link from the first step and the third step.
I can happily agree that Tony Hoare invented NULL, and I can happy agree that programmer errors that manifested as dereferencing a NULL pointer have had a large cost, but I cannot see how the one leads to the other.
RE: nullable pointers Posted Mar 31, 2011 6:19 UTC (Thu) by wahern (subscriber, #37304) [Link]
In those circumstances you don't need a generic null reference, you just need a sentinel, which can be typed. A null reference is a conflation of several distinct notions. e.g., in poor layman's terms, uninitialized, missing, nothing-to-see-here, not-in-set, etc. A computational statistics professor once tried to explain to me the formal distinctions (including a new one he was proposing), but at the time I didn't grasp the importance and subtlety; all I remember now--a decade later--is that I wish I paid better attention.
I'm not exactly sure what is gained from removing generic null references entirely, though.
RE: nullable pointers Posted Mar 31, 2011 11:00 UTC (Thu) by neilbrown (subscriber, #359) [Link]
This reminds me of an observation I read many years ago that a two-valued type could mean any one of true/false, on/off, yes/no, success/fail and many other more domain-specific alternatives.
Grouping them all under "Boolean" is thus confusing.
However this is no worse than the fact that '2' could mean inches or centimetres ... or kilograms or people or almost anything.
It is for this reason that Ada (and possibly other languages) allows "new integer" which defines a new type that behaves like integer but is not type-compatible with any other integer type. It is a concept that does have its place, but the extra book-keeping would probably drive most programmers crazy - even static typing seems to be out of favour with a lot of people these days (python? Perl?) and this extra type differentiation is like static typing on steroids.
You are correct of course that a generic NULL reference is not needed, but I fail to see that a typed NULL actually buys you anything at all...
I certainly agree that it is not clear what could be gained by removing generic null references.
RE: nullable pointers Posted Mar 31, 2011 13:21 UTC (Thu) by HelloWorld (guest, #56129) [Link] But when you really want a nullable pointer, as you do in a linked list or any tree data structureYou don't need nullable pointers for linked lists
abstract class List<T> { }
final class ListNil<T> { }
final class ListCons<T> { T elem; List<T> tail; }
or for trees
abstract class BinaryTree<T> { }
final class TreeNil<T> { }
final class TreeCons<T> { T elem; BinaryTree<T> left; BinaryTree<T> right; }
arbitrarily not allowing one seems pointless.What is arbitrary is a null reference, not the lack of it. What could be more arbitrary than a magical value created out of thin air, which is a value of (almost) every type, yet supports none of the operations that all other values of these types support.
RE: nullable pointers Posted Mar 31, 2011 15:45 UTC (Thu) by mister_m (guest, #72633) [Link]
Wouldn't you have bigger problems if you tried to access an element that was filled with garbage values?
RE: nullable pointers Posted Mar 31, 2011 16:00 UTC (Thu) by HelloWorld (guest, #56129) [Link]
Of course, the compiler must ensure that a variable is never read before it is written. But this is fairly easy to do and does't require null.
RE: nullable pointers Posted Mar 31, 2011 19:04 UTC (Thu) by mister_m (guest, #72633) [Link]
I am a bit of a novice. Would you mind explaining how I would enable the compiler to do that? I am missing some programming knowlege in this area I think = perhaps a suer defined type? In school, we always set unused pointers to null, and then check for null to see if we can dereference whatever is at the other end.
RE: nullable pointers Posted Mar 31, 2011 20:36 UTC (Thu) by HelloWorld (guest, #56129) [Link]
> I am a bit of a novice. Would you mind explaining how I would enable the compiler to do that?
Unless you're the one writing the compiler, you can't. Of course, you could just use a language that does this by default, like Haskell or OCaml.
RE: nullable pointers Posted Apr 12, 2011 16:04 UTC (Tue) by oelewapperke (guest, #74309) [Link]
The essence of the trick is that you simply make a type difference between "filled in" pointers and "null" pointers.
A tree would be defined like so :
abstract class TreeNode {}
If you combine this with runtime polymorphism you can do something like this (won't work in Java, but I'm using java code anyway)
void processTreeNode(EmptyTreeNode et) {}
then simply call processTreeNode(tree), and the compiler would figure out whether to call the first or the second function.
I would love for java to support this though.
RE: nullable pointers Posted Apr 1, 2011 3:47 UTC (Fri) by neilbrown (subscriber, #359) [Link]
I'm not familiar with the language you are writing in (being primarily a C programmer), but I gather the a variable of type "List<T>" is allowed to refer to either an object of type "ListNil<T>" or an object of type "ListCons<T>". "ListNil<T>" fills exactly the same role a "NULL" so what you have created is exactly a NULLable pointer, only with a different name and more complex syntax.
A rose by any other name still has thorns, and a NULL de-reference by any other name still causes a run-time-exception or worse.
All values are "created out of thin air". They are abstractions which we create and use to try to model "real" things. Values that are useful we re-use. Values that are not, we forget. NULL turns out to be useful.
Your argument against NULL would seem to apply equally to the value '0'. It is an arbitrary magical value - that the Romans seemed to manage with out. It is a value of every (numerical) type, yet it doesn't support being the divisor in a division. We really should eradicate it - that would get rid of all divide-by-zero errors forever.
Of course, divide-by-zero errors are not caused by the availability of a 0 value, but by the misuse of that value. Similarly NULL pointer de-reference errors are not caused by the availability of a 'NULL' value, but by the misuse of that value.
RE: nullable pointers Posted Apr 1, 2011 4:39 UTC (Fri) by HelloWorld (guest, #56129) [Link]
> I'm not familiar with the language you are writing in
It's Java (though I don't usually use that language).
> "ListNil<T>" fills exactly the same role a "NULL" so what you have created is exactly a NULLable pointer, only with a different name and more complex syntax.
> Your argument against NULL would seem to apply equally to the value '0'.
RE: nullable pointers Posted Apr 1, 2011 6:06 UTC (Fri) by paulj (subscriber, #341) [Link]
Sure, but you still have a specialised nil type. Whether you use a null reference on a List type to denote the end of the list or a special EmptyList class, it still means your code has to take to check what exactly the reference is pointing to before going through it to avoid a runtime exception.
I don't see how getting a ClassCastException is any better than a NullPointerException. Even though you've created a new type, neither you nor the compiler is any better position...
RE: nullable pointers Posted Apr 1, 2011 8:22 UTC (Fri) by nybble41 (subscriber, #55106) [Link]
The example was simply to show that you don't need all pointers to be nullable to have linked lists. The advantages for this case are minimal, since linked lists specifically depend on the 'next' pointer being nullable. However, linked lists are a hardly representative of pointers in general, particularly in a language like Java where all objects are accessed via pointers. The benefit of making pointers non-nullable by default is in the majority of cases where nulls are nothing but a source of runtime exceptions.
The advantages tend to be more pronounced in languages like Haskell, however, which have more advanced type systems which handle this sort of subtyping without any need for runtime casts. As you point out, in Java you would need to explicitly cast from List<T> to ListNil<T> or ListCons<T>, an operation which can fail in much the same manner as dereferencing a null pointer.
RE: nullable pointers Posted Apr 1, 2011 13:33 UTC (Fri) by HelloWorld (guest, #56129) [Link]
> Sure, but you still have a specialised nil type. Whether you use a null reference on a List type to denote the end of the list or a special EmptyList class, it still means your code has to take to check what exactly the reference is pointing to before going through it to avoid a runtime exception.
How many times do you want me to repeat this? The fact that you need a way to represent the empty list does not mean that you need nullable pointers _everywhere_, even where they _don't_ have any purpose (unlike the list case).
RE: nullable pointers Posted Apr 1, 2011 14:25 UTC (Fri) by paulj (subscriber, #341) [Link]
That isn't what you were arguing earlier though. You have been arguing that nullable types are *always* a bad thing (in a grandparent to this post) and there is *never* a need for them (to paraphrase several other comments of yours).
To my mind, having to go from checking the value of a reference to checking other properties of a composite object (the type, or a length attribute), and still being left open to runtime-exceptions (with a different name) if you forget, means you still are facing fundamentally the same problem.
Can the compiler maybe catch a couple more problems it wouldn't otherwise. Sure. Is it a silver bullet? Sadly, still no.
RE: nullable pointers Posted Mar 31, 2011 13:29 UTC (Thu) by HelloWorld (guest, #56129) [Link]
> I'm having trouble understanding the argument against nullable pointers.
And I'm having trouble understanding why one would want a nullable pointer. I have yet to see a use case where they provide a substantial benefit. What I do see is that programs crash due to null pointer exceptions all the time.
RE: nullable pointers Posted Apr 1, 2011 4:04 UTC (Fri) by neilbrown (subscriber, #359) [Link]
> What I do see is that programs crash due to null pointer exceptions all the time.
What do you think those programs would do there were no null pointers?
One cannot know for sure, but I am certain that simply disallowing NULL pointers will not make incorrect programs correct except in a tiny minority of cases (if at all).
The thing that would have made the talk much more interested would be a description of what could have been done at the time which could have made a difference.... but I don't think there is anything.
RE: nullable pointers Posted Apr 1, 2011 4:19 UTC (Fri) by HelloWorld (guest, #56129) [Link]
> There are various possibilities: throw an 'invalid type' error instead, enter an infinite loop, produce an incorrect answer, kill your cat....
You forgot the one that matters: they may fail to compile. In languages like ML, a variable can't be "null". The closest thing to null that ML has is the Option datatype, and if you try to pass an expression of type t Option to a function expecting an argument of type t, your program won't compile.
RE: nullable pointers Posted Apr 1, 2011 8:12 UTC (Fri) by neilbrown (subscriber, #359) [Link]
ahh... I get it now.
What you are saying (I think) is that not only should the language provide a 'non-nullable' pointer type (which the compiler assures will never be NULL), but that where a nullable pointer is used, the language should require that there be an explicit test for NULL before dereferencing the pointer or assigning it to a non-nullable pointer.
That makes sense.
So you will never get a NULL dereference, and the compiler/runtime doesn't have to do implicit tests because tests are required to be explicit.
RE: nullable pointers Posted Apr 1, 2011 12:46 UTC (Fri) by HelloWorld (guest, #56129) [Link]
> What you are saying (I think) is that not only should the language provide a 'non-nullable' pointer type (which the compiler assures will never be NULL), but that where a nullable pointer is used, the language should require that there be an explicit test for NULL before dereferencing the pointer or assigning it to a non-nullable pointer.
Yes, this is exactly what I meant.
RE: nullable pointers Posted Apr 1, 2011 8:48 UTC (Fri) by jezuch (subscriber, #52988) [Link]
> You forgot the one that matters: they may fail to compile.
Yup. You learn Haskell and/or ML (and/or ...) and the case against null pointers becomes so obvious you don't even know how to explain it.
RE: nullable pointers Posted Apr 1, 2011 9:12 UTC (Fri) by paulj (subscriber, #341) [Link]
So in Haskell you never have to do things like have a separate case for an empty list?
If you specifically mean SEGVs, well that's very easy to explain: Haskell and functional languages generally do not have pointers.
RE: nullable pointers Posted Apr 1, 2011 21:01 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
You still have to case on the empty list (e.g., you can't get the first value from it, so if you need it, you need to do /something/ different for the empty list unless you want exceptions about incomplete pattern matchings). An example:
safeHead :: [a] -> Maybe a
When calling safeHead, the caller must* check to see if a value was actually returned before using it. This can be done with fromMaybe:
fromMaybe sensibleDefault $ safeHead someList
* The caller can just use fromJust which raises an exception on a Nothing value, but that's the caller's burden at that point.
RE: nullable pointers Posted Apr 5, 2011 6:27 UTC (Tue) by cmccabe (guest, #60281) [Link]
I think academics tend to dislike NULL is because it makes it harder to formally prove code correct. I'm kind of surprised nobody brought this up yet.
GCC 4.6.0 released Posted Mar 29, 2011 2:39 UTC (Tue) by HelloWorld (guest, #56129) [Link] The fact that Java needs wrapper classes for this, and for other things, is a design limitation of Java, not of primitives themselves.The term "Primitive type" refers to different things in different languages. I was talking about primitive types in Java, and they're a bad idea. I don't know about Go and its notion of primitive types. Having a bool type is "obviously a bad thing," as you can obtain the same effect with ints.Um no, you can't. The point of having a boolean type is to enable the compiler to check that there is actually a logical value in your if statement or while loop, and not a numeric value. Oh wait, that argument is bogus.I said something is obviously a bad thing if it's not needed and causes bugs. You deliberately didn't quote the second bit, because you knew that if you had, you wouldn't have had much of a point. Please stop doing that. And please tell me: what is in your opinion a more convincing way to show that a language feature is a bad idea than showing that it's dangerous and that you don't actually need it? This is just more "argument by assertion" on your part. I find NULL, or nil, or None, or whatever you call it, to be useful more often than it is not. And when I don't have it, I usually have to create some kind of special class value to represent "zero" which is usually just an annoyance.It is trivial to do this once generically. Heck, I'll just do it for you.
abstract class Option<T> {
public abstract T get();
public abstract bool isPresent();
}
final class None<T> extends Option<T> {
public T get() { throw new Ouch(); }
public bool isPresent() { return false; }
}
final class Some<T> extends Option<T> {
private final T t;
public Some(T t) { this.t = t; }
public T get() { return t; }
public bool isPresent() { return true; }
}
Put this in java.util and you have everything you need to represent optional values. If a method takes an optional value of type T you declare a formal parameter of type Option<T>. If you don't want to pass a value, pass new None<T>(), otherwise, pass new Some<T>(myT). What does null do better than this simple class hierarchy?
GCC 4.6.0 released Posted Mar 29, 2011 5:34 UTC (Tue) by cmccabe (guest, #60281) [Link]
> What does null do better than this simple class hierarchy?
I'm well aware that you can build a nullable pointer out of a non-nullable one. C++ has boost::optional which is kind of a nullable object, templated in a similar way. However, that technique is less efficient and more cumbersome than just using a regular pointer.
So far, you haven't presented any actual evidence that non-nullable pointers are helpful to programmers. Your whole argument depends on the idea that nullable pointers are somehow this huge source of bugs. But in my 10 years of C++ (and some Java) I haven't found this to be the case. I am much more worried about race conditions, implicit narrowing of numerics, and code that handles error conditions poorly than I ever will be about NULL pointers.
It's like trying to sell me insurance against stampeding elephants. I know that elephants can kill, but honestly, I'm not that worried about them. I have other things to worry about.
C++ has non-nullable pointers in the form of references. However, despite this fact, programmers continue to use pointers. Apparently either the advantages of a non-nullable pointer aren't that great, or the weight of legacy code is too heavy. I guess you're free to interpret it however you like.
When you look at static code analysis tools that people run in the real world, they tend to look for things like race conditions, uninitialized memory uses, double frees, and so on. You could imagine annotating your pointers with something like "attribute __nonnull", and using your tool to look for violations of that, but in practice, nobody bothers to do it.
Here's an example of such an implementation:
Now is any big Java project using this stuff? If not, why not? These are the kind of questions we should be asking.
Please don't misinterpret what I'm saying. I'm not necessarily against non-nullable pointers, I'm just saying that the evidence presented here has not been persuasive.
GCC 4.6.0 released Posted Mar 29, 2011 10:52 UTC (Tue) by nix (subscriber, #2304) [Link]
I've been religiously doing nonnull attribute decorations in the code I write for more than ten years. Violations are hardly ever detected.
However, I get null pointer errors on a fairly regular basis, because GCC's nonnull attribute can only warn you if it can be sure a pointer is NULL, and if it's received from somewhere else it can't tell that. Whole-program compilation will help, but a lot of code is in shared libraries, and there, you have no recourse.
But if the *actual type* of the pointer was different (so the compiler could distinguish 'non-null pointer to object' and 'nullable pointer to object' even for external symbols) this error would largely disappear (as it does in C++ with references). However, this would require changing the C linkage model, and probably mangling names. Ain't gonna happen.
GCC 4.6.0 released Posted Mar 30, 2011 7:13 UTC (Wed) by jrn (subscriber, #64214) [Link]
Sounds like a job for sparse.
GCC 4.6.0 released Posted Apr 1, 2011 17:51 UTC (Fri) by nix (subscriber, #2304) [Link]
Yeah, agreed, and if the system I'd been working on then hadn't been a horrible preprocessor-mangled nightmare (Pro*C, and if you have experience with it, my condolences) so sparse would have drowned the real warnings in all the screaming about the hideous wrecked code the preprocessor inserted.
GCC 4.6.0 released Posted Mar 29, 2011 13:16 UTC (Tue) by HelloWorld (guest, #56129) [Link]
> However, that technique is less efficient and more cumbersome than just using a regular pointer.
If these are an actual problem in your code, you're probably overusing "optional" elements anyway. I almost never need them.
> Your whole argument depends on the idea that nullable pointers are somehow this huge source of bugs. But in my 10 years of C++ (and some Java) I haven't found this to be the case.
> C++ has non-nullable pointers in the form of references. However, despite this fact, programmers continue to use pointers.
> Please don't misinterpret what I'm saying. I'm not necessarily against non-nullable pointers, I'm just saying that the evidence presented here has not been persuasive.
|
|||||||||||||