I think the lesson for C++ was that well though out decisions in the small can lead to an overly complex and difficult to use language, an all to common result of design by committee. Probably the single worst decision for Java was that the programmer needed to be protected from his own stupidity. What we ended up with is a language that's overly verbose and encourages baroque design patterns.
Bruce discusses some of the well known bad design decisions in Java, such as no operator overloading (.equals(), bah), bolt on generics, primitives instead of being purely object based. And there are a ton of other design decisions that made for a bad language: explicit typing of functions instead of duck typing and specialization, introspection for methods but not variables, no first class methods, everything has to be in a class instead of everything is an object, etc.
In the end Java will fade away and the JVM will endure with newer and better languages. The one thing that no one envisions is a better Java unconstrained by past errors. I suppose that's because of the rigid control by Sun.
So essentially, the positive legacy of Java is that the JVM has provided a platform for other languages to compile to (and has funded the continued study of dynamic language optimization that began with Smalltalk and Self), and that techniques such as garbage collection are finally mainstream.
The article doesn't seem to explicitly mention the legacy of C++, but the implication seems to be, "We now know ... not to make that same mistake again." (Maybe I'm being overly cynical.) Passing on some aspects to Java is part of it, of course.
" All future languages should learn from this: either create a culture where you can be refactored (as Python and Ruby have done) or allow competitive species to thrive. "
If that is the case, then .net is a great platform and I think he hasn't done justice by not mentioning it. More and more languages are being made compatible with .Net giving the programmer the choice to use libraries written in other languages in the language of their choice.
But I don't agree with him at the first place. Unlike C++, Java was proprietary and it went in the same direction most of the proprietary stuff leads to. As he himself points out, many C programmers moved to C++ and we saw an era when much of the code was written in C++. But now, how many programmers are fondly moving towards Java's newer versions or towards Groovy, JRuby, Jython etc?
The line "Java itself will diminish..." did feel a little Middle-Earth to me.
This is not so much a criticism, but I'm not entirely sure what this article is trying to say. He seems to be saying that Java and C/++ were really a springboard into a new way of looking at problems in computing.
I think the problem I have with this is (1) I don't think we really know what that "new" thing is yet, so it's hard to really judge the legacy of Java/C++ --
and (2) a lot of these emergent languages have been around a long time... So perhaps it misses the factors that have somehow turned the tables. Perhaps the issue with Java isn't the way it handles primitives, but something else more fundamental altogether.
Both Java language and C++ suffer from backward compatibility. Of course it is a must from business point of view, but it is also a major obstacle. Once bad design decision is made, no one could fix it. The Python doesn't strictly follow that rule and perhaps it is the reason why it seems to have a bright future.
If forwards compatibility is not accounted for, you could almost consider C, C++, Java and C# as the same language. There was a natural progression of syntax and features with very little that happened disruptively in the syntaxes in moving from one to the next (biggest jump, amusingly, was the one that was forwards compatible -- from C to C++).
I'd argue the lack of backward compatibility is what is keeping hosting companies to stick to arcane versions of PHP despite numerous newer releases being around.
Without a backward compatible environment lots of people will refuse to move forward because of the costs associated with it. For instance Windows would hardly be as successful as it is if it weren't for backward compatibility.
Not that it is all golden though. Java suffers majorly from backward-compatibility which has caused the language to be almost stagnant. In this respect I think Microsoft made a much better decision for .NET by enabling the user to have multiple runtimes installed.
the way to get the masses of C programmers to move to objects was to make the move transparent: to allow them to compile their C code unchanged under C++
Except that that is not really true: it is very rare that you can take a non-trivial C program, replace 'cc' with 'c++, and have it "just work".
You don't have to; C++ can work just fine with object files using C name mangling, so it's no problem to mix C and C++ in the same project even if the source files are compiled with different compilers.
Sure, although that's not the C++ <=> C compatibility story that was originally intended, AFAIK. Calling back and forth between C++ and C isn't entirely trivial, either (exceptions, longjmp, etc.)
Bruce discusses some of the well known bad design decisions in Java, such as no operator overloading (.equals(), bah), bolt on generics, primitives instead of being purely object based. And there are a ton of other design decisions that made for a bad language: explicit typing of functions instead of duck typing and specialization, introspection for methods but not variables, no first class methods, everything has to be in a class instead of everything is an object, etc.
In the end Java will fade away and the JVM will endure with newer and better languages. The one thing that no one envisions is a better Java unconstrained by past errors. I suppose that's because of the rigid control by Sun.