| |||||||||||||
GCC 4.6.0 releasedGCC 4.6.0 releasedPosted Mar 27, 2011 18:57 UTC (Sun) by elanthis (guest, #6227)In reply to: GCC 4.6.0 released by jd Parent article: GCC 4.6.0 released
Moving D into GCC proper is problematic for no other reason than that D is a moving target. The authors are not formally standardizing the language, they abandon versions of it, and there's no guarantee that tomorrow's D will be anything like today's.
Plus, the D standard library is total crap. It's so much crap that they wrote a completely new one. Which is also total crap. So they're contemplating a third.
There's a ton of great ideas in D but nobody involved in that project is really fit to be in charge of a language standard. Either D needs to be taken off Digital Mars' hands or a new very D-like language needs to be spec'd out by somebody else.
(On a personal taste note, the fact that D is not backwards compatible with C is very annoying. There is a ridiculously large body of C code and C libraries out there for which the D facility for generating "bindings" does not work well, such as libraries that make heavy use of macro tricks which are common given C's weaknesses. In all honesty, these days, we're almost in the same boat with C++ given its ubiquity in so many areas of the industry. Whatever minor improvements a language gets by dropping C compatibility are simply not worth the loss. Removing the C preprocessor isn't necessary because its existence does not mandate its use in new code, and changing where the * in pointer type declarations binds is nice but such an incredibly minor thing... the break in compatibility is measurably harmful but not notably helpful.)
(Log in to post comments)
GCC 4.6.0 released Posted Mar 27, 2011 21:47 UTC (Sun) by cmccabe (guest, #60281) [Link]
> (On a personal taste note, the fact that D is not backwards compatible
> with C is very annoying. There is a ridiculously large body of C code and > C libraries out there for which the D facility for generating "bindings" > does not work well...
The whole point of D is to be a "cleaned up" version of C++. A lot of the problems C++ has result from the fact that it kept source-level compatibility with C.
The problem with D is that someone already wrote a cleaned up C++. He called it Java, and it happened in the 1990s. There are still some things about Java that are annoying, but not to the point that it justifies a whole new language.
Personally, I think golang is a lot more interesting than D, fortran 2008, or pascal. But that's just me :)
GCC 4.6.0 released Posted Mar 28, 2011 0:22 UTC (Mon) by HelloWorld (guest, #56129) [Link]
> The problem with D is that someone already wrote a cleaned up C++. He called it Java, and it happened in the 1990s.
The Java designers removed the stuff that is useful in C++, while failing completely to clean up the actual problems like primitive types or Tony Hoare's billion dollar mistake and introducing boneheaded mistakes like the conversion from Derived[] to Base[]. Calling Java a cleaned-up version of C++ is simply ridiculous.
> Personally, I think golang is a lot more interesting than D, fortran 2008, or pascal.
Java Fail Posted Mar 28, 2011 15:40 UTC (Mon) by ncm (subscriber, #165) [Link]
Correct as far as it goes... Java's designers demonstrated again and again that they didn't even understand the C++ of 1992 that they copied Java from. The litany of "boneheaded mistakes" just goes on and on: 16-bit characters. Default virtual. No destructors. Garbage collection. Ugly NamingConVention. Threading model unimplementable on modern multi-CPU designs. Enforcedly slow execution model. I could go on.
C# is even worse, because it shares almost all the mistakes of Java, and adds new ones despite full benefit of hindsight.
Go's designers had even more hindsight to work from, so each such mistake counts more. They got some doozies. However, it is marginally more interesting than D.
Java Fail Posted Mar 28, 2011 17:16 UTC (Mon) by nteon (subscriber, #53899) [Link]
is there a 'modern' language you _would_ recommend?
Java Fail Posted Mar 31, 2011 18:08 UTC (Thu) by ncm (subscriber, #165) [Link]
There is still no plausible successor to C++, as much as we might like one.
Any such successor can only be produced by someone who understands it, and why it has been successful despite all the historical baggage it must drag along. It would be at least as expressive, but 90% smaller. Unfortunately most efforts sabotage themselves at the outset by including garbage collection and CONS or its equivalent. A powerful-enough language should be able to express those in the library, and not need them built into the core. Likewise, control structures, inheritance, and maybe even function argument lists.
GCC 4.6.0 released Posted Mar 28, 2011 16:24 UTC (Mon) by cmccabe (guest, #60281) [Link]
Primitive types are only a "problem" if you're the kind of person who alphabetizes his sock drawer.
Non-nullable pointers may or may not be a good thing. Either way, argument by assertion doesn't add anything to the debate.
If you want to know what Java cleaned up, check out: http://yosefk.com/c++fqa/defective.html
The big mistakes Java's designers made were copying the C++ inheritance model (http://asserttrue.blogspot.com/2009/02/inheritance-as-ant...), relying too much on threads as a concurrency mechanism, and reinventing a lot of wheels in a misguided effort to be platform-independent.
GCC 4.6.0 released Posted Mar 28, 2011 18:33 UTC (Mon) by daglwn (subscriber, #65432) [Link]
You're demonstrating exactly what mcm talked about in the comment above. The C++FQA is a load of garbage, written by someone who doesn't actually understand C++.
C++ has plenty of warts. No C++ user or designer will tell you otherwise. But the C++ inheritance model is not broken. Java did take out all the good parts of C++. That's why it feels like an incomplete language.
GCC 4.6.0 released Posted Mar 28, 2011 19:52 UTC (Mon) by cmccabe (guest, #60281) [Link]
If you think Yossi Kreinin "doesn't understand C++," then can you point out an actual factual error he makes?
What "good parts" of C++ did Java take out?
I seem to be no more knowledgeable after reading your post than before.
GCC 4.6.0 released Posted Mar 28, 2011 21:10 UTC (Mon) by mpr22 (subscriber, #60784) [Link] C++'s operator overloading lets me write arithmetic on ordered pairs of numbers in a civilized fashion. The fact that other idiots do strange, idiotic, crack-addled things with it is not, and will never be, sufficient to persuade me that it is not a good and valuable feature which improves the language of which it is a part. Also, what is this C++ FAQ that Yossi keeps ranting about? I've never read it, it has never occurred to me to look for a C++ FAQ, and I can't imagine why one would look for a C++ FAQ.
GCC 4.6.0 released Posted Mar 31, 2011 15:37 UTC (Thu) by mister_m (guest, #72633) [Link]
I'd like to say that the C++ FAQ here is an absolutely fantastic resource. Especially for students coming from Java like myself.
GCC 4.6.0 released Posted Mar 28, 2011 21:15 UTC (Mon) by daglwn (subscriber, #65432) [Link]
> What "good parts" of C++ did Java take out?
Multiple inheritance
Just to name a few.
> If you think Yossi Kreinin "doesn't understand C++," then can you point
Ok, here's one chosen at random:
> Templates are mostly applicable to containers or smart pointers, which
This is completely wrong. In fact one often wants to favor static polymorphism over dynamic polymorphism. Of course, one has to
GCC 4.6.0 released Posted Mar 28, 2011 21:55 UTC (Mon) by cmccabe (guest, #60281) [Link]
> > What "good parts" of C++ did Java take out?
> Multiple inheritance
Java classes can implement multiple Interfaces. This effectively accomplishes the same thing as multiple inheritance without the big problems of MI in C++.
By the way, most experts recommend that you never use C++'s multiple inheritance support (unless you are inheriting from abstract base classes).
> Fully generic templates
Java has generics. They're not implemented quite the same as C++ templates, but they accomplish the same thing.
> Operator overloading
Frankly, I think operator overloading is confusing and ugly. It's a Perl-style "let's save 5 seconds of typing now, but spend 50 minutes scratching our heads a few months later over what this code REALLY does."
> > Templates are mostly applicable to containers or smart pointers, which
I am looking at some C++ code right now. I can tell you that 90% of the uses of templates are STL containers and smart pointers! I don't know what your definition of "mostly" is, but 90% meets my definition.
Let's take the next sentence. "Most of the time you are better off with dynamic polymorphism." I think if you look at most C++ programs, you would see more use of classes and virtual functions (dynamic polymorphism) than templates (static polymorphism). So this sentence seems to be true as well.
I think your brain translated what Yossi said into "templates suck, don't use them." But that's really not what he said at all. He just said other methods are, and should be, used more often than templates. Templates have their place. I've said this before and I'll say it again-- templates are really the only improvement C++ made over C.
GCC 4.6.0 released Posted Mar 29, 2011 1:05 UTC (Tue) by mtall12 (guest, #73924) [Link]
Sorry, that's a non-argument. Using the same logic I could say that using the "traditional" function call of foo(a,b) is confusing and ugly, because I'll need to spend 50 minutes deciphering what foo() does. Operator overloading is a very useful shorthand for function calls that can make the code far more readable and hence easier to maintain (translation: less bugs). This is especially true when writing scientific applications (though certainly not limited to them). With a decent matrix library (eg. Armadillo or ITPP), C++ allows things like:
A = (0.1*B + C) * D;
A.scalar_multiply(0.1); A.add(C); A.matrix_multiply(D);
Let's also not forget that through C++ templates one can implement expression optimization, where operations like (0.1*B + C) can be turned into one loop, thereby providing execution speeds generally not doable in Java (ie. without specialized functions).
GCC 4.6.0 released Posted Mar 29, 2011 1:11 UTC (Tue) by HelloWorld (guest, #56129) [Link]
> Java classes can implement multiple Interfaces. This effectively accomplishes the same thing as multiple inheritance without the big problems of MI in C++.
What "big problems" are you talking about? I suspect these "problems" are merely something that is being made up by Java fanboys in order to defend their emasculated language, because I've never seen an actual problem that is fixed with Java's interface approach.
> By the way, most experts recommend that you never use C++'s multiple inheritance support
> Java has generics. They're not implemented quite the same as C++ templates, but they accomplish the same thing.
> Frankly, I think operator overloading is confusing and ugly. It's a Perl-style "let's save 5 seconds of typing now, but spend 50 minutes scratching our heads a few months later over what this code REALLY does."
GCC 4.6.0 released Posted Apr 3, 2011 22:34 UTC (Sun) by cmccabe (guest, #60281) [Link]
> Except that they don't, as the introduction of generics broke the casting
> operator. You can cast something to ArrayList<Foo>, and even if that > succeeds, what is returned from its get method may not be a Foo. This kind > of fuckup is typical for Java.
Java's generics do have a lot of weird corner cases. Things that, as a C++ coder, I would expect to succeed, do not. One example is trying to make a copy of an arbitrary type T using a copy constructor.
http://www.ibm.com/developerworks/java/library/j-jtp01255...
Java's generics are flawed. Java itself is flawed. But then, so are many other languages.
> What "big problems" are you talking about? I suspect these "problems" are
http://en.wikipedia.org/wiki/Diamond_problem
Honestly, I am just going to stop commenting or offering advice on programming languages at all. Even the most simple and basic advice always seems to touch off a flamewar.
Recently I advised someone to stop throwing raw "int"s as exceptions. Result: 15 minute discussion about maintainability, code clarity, stuff experts said, the difficulty of adding all the catch blocks you need to client code, etc. At the end of it: "well, I'm going to keep doing it anyway." Luckily I will never have to maintain, or even see, that code because it's closed source and I don't work at that organization.
GCC 4.6.0 released Posted Apr 4, 2011 19:10 UTC (Mon) by daglwn (subscriber, #65432) [Link]
> http://en.wikipedia.org/wiki/Diamond_problem
That's a problem for a very specific case and even then it's not always a problem. It's more something to be aware of. It does not invalidate the utility of multiple inheritance. The mixin pattern is a primary example of how useful MI can be. It use it all the time.
> Honestly, I am just going to stop commenting or offering advice on
Advice is fine as long as it is relevant to the task at hand. General
GCC 4.6.0 released Posted Apr 5, 2011 10:47 UTC (Tue) by HelloWorld (guest, #56129) [Link]
> http://en.wikipedia.org/wiki/Diamond_problem
C++ solved this problem a long time ago. You can either use virtual inheritance or say explicitly if you want to use B's or C's method (using the class identifiers from the wikipedia article). And your assertion that interfaces effectively accomplish the same thing as multiple inheritance is just wrong, you can't do mixins with Java interfaces. So, the way I see it, Java didn't actually solve any problem (like C++ did with virtual inheritance), but it just disallowed multiple inheritance even in cases where the diamond "problem" doesn't even arise.
GCC 4.6.0 released Posted Apr 5, 2011 20:38 UTC (Tue) by cmccabe (guest, #60281) [Link]
As the Gang of Four book says, you should "favor 'object composition' over 'class inheritance'." So rather than creating mixins, you should usually create objects that are comprised of several smaller objects which operate independently.
There are a lot of reasons for this. The first and most obvious reason is that it makes unit testing a lot easier. If I have a class which inherits from 3 other classes, I can't test that class without also testing the three base classes. I may not even be able to construct an instance of that class without providing a lot of irrelevant inputs-- file descriptors to open, memory to allocate, and so forth. On the other hand, it's easy to create an instance of a component and test just that component.
You can get around some of these problems by constructing "mock ups" of some of your class components. You see this a lot in Java code. But it's difficult, and even when executed successfully, it bloats the code.
Creating elaborate and deep inheritance hierarchies increases compile time and the coupling between components. The former chews up machine cycles when compiling (at least if you're using C++). The latter chews up human time when trying to maintain the code, no matter what language you're using.
This is related to the "midlayer mistake" that Neil Brown talked about earlier: http://lwn.net/Articles/336262/
GCC 4.6.0 released Posted Apr 5, 2011 22:43 UTC (Tue) by HelloWorld (guest, #56129) [Link]
Firstly, this is a general statement about inheritance and has little to do specifically with multiple inheritance. Secondly, if we assume the GoF to be right, then Java did it just as wrongly as C++, as it still allows inheritance.
GCC 4.6.0 released Posted Apr 5, 2011 23:24 UTC (Tue) by cmccabe (guest, #60281) [Link]
My main point is that using inheritance for code reuse is bad.
Using inheritance to implement runtime polymorphism is still ok.
So Java interface classes and C++ abstract base classes are ok in my book. Mixins are bad, in my opinion.
I do like the way Golang handles runtime polymorphism more than the way C++ or Java do it, but you can only do it that way if you're using Go. :)
GCC 4.6.0 released Posted Apr 7, 2011 16:42 UTC (Thu) by daglwn (subscriber, #65432) [Link]
Mixins do not have to implement anything. Again, you're artificially restricting what's possible. It's sometimes convenient to use mixins to convey relationships among types. I have a mother and a father. My mother has a mother and a father. So does my father. That means my maternal-side cousin and I have grandparents in common and my paternal-side cousin and I also have grandparents in common, but a different set.
In more concrete terms, an add expression is a binary operator. So is a subtract expression. Both are also associative, but only one is commutative. That's a useful thing to express in class hierarchies and using mixins is a great way to do it.
GCC 4.6.0 released Posted Apr 8, 2011 17:57 UTC (Fri) by cmccabe (guest, #60281) [Link]
from Wikipedia:
> In object-oriented programming languages, a mixin is a class that provides
So it's not about relationships between types. It is about code reuse.
Bruce Eckel suggests a way of implementing mixins in C++ using templates:
http://www.artima.com/weblogs/viewpost.jsp?thread=132988
I would suggest yet another: private inheritance.
GCC 4.6.0 released Posted Apr 8, 2011 18:35 UTC (Fri) by daglwn (subscriber, #65432) [Link]
I've used CRTP as well and find it useful. I also find mixins as relationship useful. I my mind, inheritance is about relationships. For functionality, I would agree with GoF and you that composition is generally a better path. I very rarely use private inheritance. I honestly can't think of a situation where I've found it absolutely necessary.
But in any case, I think the discussion leads us to a place where general MI is useful, even with the pitfalls. Pointers in C have a similar usefulness/pitfall tradeoff. I like the fact the C++ is flexible like this. I wish it were more flexible than it is! :)
GCC 4.6.0 released Posted Apr 11, 2011 0:30 UTC (Mon) by cmccabe (guest, #60281) [Link]
Well, as I said before, I think being able to inherit from multiple (fully) abstract base classes is useful. I have never found a good use for inheriting from multiple non-abstract base classes. I guess we'll have to agree to disagree.
Anyway, language design is an endless process. It really comes down to who what languages are most successful in the marketplace, and in the open source world. My philosophy is to use the right tool for the job.
GCC 4.6.0 released Posted Mar 29, 2011 10:54 UTC (Tue) by jwakely (subscriber, #60262) [Link]
> By the way, most experts recommend that you never use C++'s multiple inheritance support (unless you are inheriting from abstract base classes).
What about non-abstract empty bases? Should they never be used with MI?
What about std::ctype, std::codecvt, std::time_get and other facets?
What about std::iostream?
I guess I'll "never" be an "expert"
GCC 4.6.0 released Posted Apr 2, 2011 0:10 UTC (Sat) by cmccabe (guest, #60281) [Link]
> What about non-abstract empty bases? Should they never be used with MI?
That's what I just said.
> What about std::iostream?
from a footnote in "Thinking in C++" by Eckel:
> Jerry Schwarz, the author of iostreams, has remarked to both of us on
> I guess I'll "never" be an "expert"
Try reading Effective C++, More Effective C++, and anything by Alexandrescu. Or you can go renegade and read the C++ FQA. No matter whether you agree with Yossi, you will learn a lot.
GCC 4.6.0 released Posted Mar 29, 2011 15:47 UTC (Tue) by k8to (subscriber, #15413) [Link]
If you say Yosef doesn't understand C++, then you've demonstrated that you're willing to claims someone is wrong just because you don't like their position, and without actually understanding what they have to say.
There is a very *deep* grasp of the language there, by someone who has had to implement aspects of it in production systems for many many years. You may not agree with the assessment, but to claim a lack of understanding only makes you look a fool.
GCC 4.6.0 released Posted Mar 29, 2011 16:20 UTC (Tue) by mpr22 (subscriber, #60784) [Link] My experience of C++ directly contradicts the position that the FQA is written to advance (which can be fairly summarized as "C++ delenda est" - and if you disagree, please explain why).
GCC 4.6.0 released Posted Mar 28, 2011 20:43 UTC (Mon) by HelloWorld (guest, #56129) [Link] 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++.
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.
GCC 4.6.0 released Posted Mar 29, 2011 6:08 UTC (Tue) by jensend (guest, #1385) [Link] I fail to see how golang is interesting. I imagine you've seen the Go vs Brand X comparison?The thing that hath been, it is that which shall be; and that which is done is that which shall be done: and there is no new thing under the sun. - Kohelet.
GCC 4.6.0 released Posted Mar 29, 2011 13:41 UTC (Tue) by HelloWorld (guest, #56129) [Link]
I hadn't. Thank you for the link, it's rather enlightening.
GCC 4.6.0 released Posted Mar 29, 2011 21:26 UTC (Tue) by cmccabe (guest, #60281) [Link]
I take issue with that article. Despite spending so much time on things like syntax, he doesn't write code in the Golang style, which is 4-character indentation and cuddled braces. This is more than a minor issue, because whitespace is significant in Go. For example, this won't compile:
if (foo)
It has to be written this way:
Yet his examples are all written out with the former style of braces, and Ruby-style 2-space tabs. So it's clear that he's hardly used Go at all.
After spending all this time obsessing over syntax, he glosses over the major new things in Go with this breezy paragraph:
> Go has more in the way of actual features --- interfaces, channels, maps,
Yeah. Who needs good support for concurrency, proper error handling, closures, and a radical new type system. Algol-68 has "while" loops, and that's *important*. It also has the "pleasing symmetry" of having an explicit keyword to put things on the stack, much like C's useless auto keyword. Oh yeah, and there's "nothing new" in Go, except for that stuff that I just ignored.
Meanwhile, Algol-68 "also has threading, but the mechanism is unspecified."
Accusing Golang of not being "consistent in its features" is a bizarre conclusion. If you've used any langauge from the past 20 years-- C++, Java, Perl, PHP, or Javascript-- you will find Golang much more consistent than any of those. (I don't know Algol-68 well enough to make this kind of esthetic judgement, though.)
In summary, he obsesses over Go's syntax, gets even that wrong, and completely ignores the major challenges facing modern programmers: i.e. effectively dealing with parallelism and building large-scale object oriented systems.
GCC 4.6.0 released Posted Mar 28, 2011 0:32 UTC (Mon) by HelloWorld (guest, #56129) [Link]
> Removing the C preprocessor isn't necessary because its existence does not mandate its use in new code
But it makes it much harder to write proper tools, such as IDEs. There is a reason why C and C++ IDEs still suck compared to what is available for, say, Java. > There is a ridiculously large body of C code and C libraries out there for which the D facility for generating "bindings" does not work well, such as libraries that make heavy use of macro tricks which are common given C's weaknesses. Oh, so first you say that the preprocessor is not a problem because you don't have to use it and then you say that it is in fact, because it breaks the tools that generate C bindings for D. Make up your mind!
GCC 4.6.0 released Posted Mar 28, 2011 2:18 UTC (Mon) by tetromino (subscriber, #33846) [Link]
> proper tools, such as IDEs
<rant>
Back in the day, real programmers used to write software in MS Notepad! With 8-letter filenames and Hungarian variables! And no version control system! They walked to work three hours in meter-deep snow, all year long, uphill both ways! And they *liked* it!
GCC 4.6.0 released Posted Apr 1, 2011 3:29 UTC (Fri) by elanthis (guest, #6227) [Link]
You aren't making any sense.
(1) I said that removing the C preprocessor is a stupid idea.
These statements support each other quite well.
My point about "not having to use it" simply means that if you want to write code that doesn't use the preprocessor, you can already do that in C/C++ today. The fact that it exists is not forcing you to use it in new code. However, removing it forces you to not be able to use old code.
Hence, removing it has a measurable cost and no measurable gain.
GCC 4.6.0 released Posted Apr 1, 2011 3:49 UTC (Fri) by HelloWorld (guest, #56129) [Link]
> You aren't making any sense.
Look who's talking.
> My point about "not having to use it" simply means that if you want to write code that doesn't use the preprocessor, you can already do that in C/C++ today.
But anyway, if you want to stick with cpp, go for it. I don't particularly care.
GCC 4.6.0 released Posted Apr 8, 2011 15:55 UTC (Fri) by etienne (subscriber, #25256) [Link]
> if you want to write code that doesn't use the preprocessor, you can already do that in C/C++ today.
I would really like to have *real* constant in C/C++, something like:
inline const struct {
and write functions like:
So that the debug code is completely removed when debug is null,
GCC 4.6.0 released Posted Apr 8, 2011 17:51 UTC (Fri) by dtlin (✭ supporter ✭, #36537) [Link]
Doesn't GCC already do that (at least under some optimization levels)?
GCC 4.6.0 released Posted Apr 11, 2011 12:27 UTC (Mon) by etienne (subscriber, #25256) [Link]
GCC treat const variable as thing which cannot be modified by the code, i.e. more like read-only.
You can modify the const variable in assembler, or in another piece of code where that variable is not declared "const". Long time ago I read that you could use "static const" in C++ to get the same behaviour but I then tried and the variable was still defined as a piece of memory - and that was not available to C. What I would like is that no memory is ever reserved for "inline const struct {}" - so the tests are always either true or false at compilation time, address of that variable cannot be taken, etc...
GCC 4.6.0 released Posted Apr 11, 2011 20:05 UTC (Mon) by jrn (subscriber, #64214) [Link]
const register? constexpr?
GCC 4.6.0 released Posted Jul 18, 2011 10:03 UTC (Mon) by runciter (guest, #75370) [Link] How about: enum DebugFlags {
DEBUG_INPUT = 0,
DEBUG_SOMETHING_ELSE = 1,
};
It's constant, doesn't use any memory and doesn't use the preprocessor.
GCC 4.6.0 released Posted Jul 18, 2011 13:12 UTC (Mon) by etienne (subscriber, #25256) [Link]
But it is not as "structured" as a C structure named "debug" which would contain not only boolean but where to send the ouput (stdout, stderr, serial, filename...) and sub-structures like what to debug in "INPUT".
Anyway GCC-4.6 does introduce the inlining of constants, if you want a read only variable modified in the ELF file or at assembly time before main() is called, you now need to use "volatile const" - I was too quick to do that initial comment...
GCC 4.6.0 released Posted Mar 28, 2011 8:06 UTC (Mon) by renox (subscriber, #23785) [Link]
> Moving D into GCC proper is problematic for no other reason than that D is a moving target.
Ridiculous comment: C++ and Fortran are also a moving targets: does this mean that we shall remove them from GCC?
> The authors are not formally standardizing the language
> they abandon versions of it,
> and there's no guarantee that tomorrow's D will be anything like today's.
> Plus, the D standard library is total crap. It's so much crap that they wrote a completely new one. Which is also total crap. So they're contemplating a third.
GCC 4.6.0 released Posted Mar 28, 2011 12:07 UTC (Mon) by stevenb (guest, #11536) [Link]
C++ is ISO/IEC 14882:2003.
Fortran 2008 is ISO/IEC 1539-1:2010
D is... well, you know...
So the comment is IMVHO not so ridiculous.
GCC 4.6.0 released Posted Mar 28, 2011 13:35 UTC (Mon) by HelloWorld (guest, #56129) [Link]
So what? Java, Objective-C and Go aren't standardized either, yet they're implemented by GCC.
|
|||||||||||||