A shame [LWN.net]

A shame

Posted Apr 8, 2005 16:03 UTC (Fri) by ncm (subscriber, #165)
In reply to: A shame by Xman
Parent article: GCJ - past, present, and future

In detail and in order,

Evidently the consequences of declaring a virtual member are still not very widely understood. A class with virtual members presents two interfaces: one to the user (who calls the members) and another to the deriver (who overrides the virtual members). The first presents an abstraction, while the second manipulates implementation details beneath the abstraction. If your public interface consists of virtual functions, then you aren't really providing much abstraction at all, and your class isn't really earning its keep. Given this, for members to be virtual by default is profoundly silly.
Java's exception specifications are markedly worse than in earlier languages. It's true that specs have turned out to be a mistake wherever they appear. (Probably the only form of exception specs that would work is to list exceptions that cannot come from a function. It's not clear how useful that would be, though.) In C++, you can simply leave them off (as everyone does, nowadays) and everything will work. In Java you can't do that; they intrude everywhere, unavoidably. They have actually got worse in Java 1.5 with the addition of generics.
As I said, a 16-bit internal character representation is frankly silly. An 8-bit UTF-8 multibyte format is defensible, and a canonical UCS-32 works. Either bank is OK, but the middle of the river is all wet.
To take up C syntax and fix only a few of its flaws is worse than silly. It reeks of cargo-cultism. C++ has C syntax to ease upgrading; users can compile a C program with a C++ compiler, and then start cleaning up. Most of the language's other infelicities are traceable to that requirement. Java had no such justification; no C program is a valid Java program.
To have to suffer all that the Java type system imposes with no benefit of compile-time error checking is ludicrous. It was known perfectly well how to do (inadequate) generics in the late '80s, as in Eiffel, or Ada. To wait ten years and then paste them on, crippled (because the code generated is the same as if you had done the casts), can only be described as another mistake. C# did only a little better.
One of the deep problems with garbage-collected memory is that its costs don't show up in profiling. When a program is an order of magnitude slower than it should be, there's a reason. With GC, it's likely to be bad cache interactions. With GC, there's precious little you can do about it. (Non-portable tricks might help, but then your "run anywhere" leaks away; even the next release of your own JVM might break them.)
The faults I listed were incidental stupidities, to illustrate the lack of understanding by the language designers. I didn't list the deliberate design flaws. It's easy to see why it was taken up most enthusiastically by the worst-organized corporate IT departments. People find ways to use all kinds of languages -- even Forth! That doesn't excuse the design, or the designers, of fundamental misunderstandings of their craft, and it doesn't suggest any reason to take up the language for one's own use.

Free Software has largely avoided being saddled with Java overheads, and can only benefit from continuing to avoid them. Let corporate America mire itself helpless.

(Log in to post comments)

A shame

Posted Apr 8, 2005 23:05 UTC (Fri) by Xman (guest, #10620) [Link]

I think it's sufficient to say that you see design flaws where language designers see design decisions. You may not like the decisions a language designer makes, but that doesn't make them design flaws. Every design decision has tradeoffs, and you make a choice about which tradeoffs you want to work with. A design flaw is when you make a choice without recognizing its short comings. With the exception of exception specifications and ill defined bits in the Java memory model (both of which were the cases where they tried to do something new with unknown implications, rather than borrow concepts that worked well in other languages), I don't think you'll find James Gosling was surprised or disappointed by how things played out.

You've implied with your statements that you think C++ is a "public-standard language that is more powerful and more thoughtfully designed" than Java. Let's look at how it plays out on these issues. Yes, it defaults to non-virtual functions, but it also defaults to private non-virtual inheritence. While most Java code leaves member functions as virtual, most C++ code uses public inheritence and specifies virtual inheritence whenever it is an issue. I'd argue those are issues of style, but if they aren't then I'd have to say C++'s defaults are far more flawed than Java's. C++'s exceptions create so many problems that the people who *worked on the language* couldn't figure out how one would write an exception safe stack for the longest time. C++'s string class can be made to do UCS-32 (you didn't need that memory did you? ;-), but has no notion of using a variable width encoding of strings, and a lot of implementations still ship with 8 and 16-bit character types. Indeed, C++'s string class is so "broken" that there are any number of competing string implementations out there (include C strings) in wide use while Java's String class seems to work just fine for 99% of Java code. C++ claims to be fully compatible with C, but manages to have several subtle differences which turns out to be far more dangerous than being similar enough to help developers understand what they are looking at. C++ is the home of one of the worst macro systems known to mankind and has a powerful templating system who's syntax is so baroque that a number of semantic ambiguities were uncovered at the last minute, forcing some hacked and overloaded uses of the keywords "typename" and "template" to disambiguate the code. Nevermind that the system is so complex to this day few compilers can fully compile code using the likes of boost::lambda. C++ doesn't come with any support for GC, so you end up with people often jury rigging a solution using reference counting that is inherently flawed, increadibly slow and a potential source of deadlocks if you need thread safety, often slower even when single threaded, still leaves them with a fragmented heap and... (wait for it) bad cache interactions.

Despite pointing out all these issues, I like C++, and use it probably more than any other language. The reality is all languages suck, because most design decisions have unfortunate trade offs. It's unfortunate when this intrinsic property distracts from the advantages each language has to offer.

A shame

Posted Apr 11, 2005 4:02 UTC (Mon) by ncm (subscriber, #165) [Link]

A disappointing feature in a language is a tradeoff only when something was gained in exchange. If you got nothing in exchange, then it's a pure design flaw. Exception specifications are a classic example: C++ has them, but shouldn't. Java has them, too (but markedly worse, despite hindsight!). It's a pure flaw, with no benefit in sight.

One doesn't run across people complaining about how slow programs C++ are, but people frequently complain about Java programs. Java programs, as a rule, really are slow. Garbage collection carries much of the blame. For C++, GC would not be a feature. Rather, it would make encapsulating resource management impossible, as it is in every GC language. The presence of GC doesn't only hint that a language is too weak to encapsulate resource management. GC, by itself, makes that impossible. GC actually sabotages the design of languages, for industrial purposes. It is possible that academia's insistence on GC in new languages is the sole reason that (still!) no language has surfaced that might displace C++ in industrial use.

The whole purpose of exceptions is to make programs simpler and more robust at handling errors. C++ exceptions work superbly: error handling code is reduced to one or a few chokepoints where exceptions are handled, with typically very little code, easy to exercise with minimal testing. Java exceptions, by contrast, fail completely: a Java program that handles exceptions properly is much longer, with error handling scattered throughout. Hard to exercise, it rots. (More commonly, it is just omitted.)

Anybody who can't design an exception-safe stack for C++ has not identified a flaw in the language. Idiocy is a purely personal problem. See http://cantrip.org/stupidity.html.

As I noted before, the macro system in C++ comes unchanged from C, for the strictly practical reason of backward compatibility; most C++ programs use only #include and #if. The template system works fine on mature compilers, of which many are readily available today. (That MS's product remains dodgy tells us way more about MS than about language design.) The problems in template syntax are a product of language evolution: ISO C++ templates are far more powerful than as originally envisioned. Power is worth trading a lot for.

I don't know of any widely-used string type designed after the ISO standard was published. Of course the old ones, and those necessary to interact with C code, hang around. Library apparatus to operate on in-core multibyte strings is no credit to a language. External multibyte text representations (and conversions to and from) are appropriate for interoperability, but it would be foolish to operate directly on strings in that form.

All this is not to claim C++ is especially good; rather, Java is especially bad. If Gosling isn't disappointed with his design, it can only be because he hasn't paid attention. Java has managed to set back the practice of programming by a decade. A whole generation of programmers have had their careers blighted by exposure to it.

A shame

Posted Apr 15, 2005 20:31 UTC (Fri) by renox (subscriber, #23785) [Link]

Frankly I think that your reasons are a bit weak for such "definitive judgements".
While Java has many flaws (the number of bugs in it standard library being the number 1 mistake, Swing..), it is not a bad language just disapointingly average (getting out a language with no generics just to release it faster, no comment).
What I find amusing is that you seem to find C++ okay and Java ugly whereas in my book it is just the opposite: C++ *is* bad: a language which needs years for developpers to learn (and from which they use 30% of the features at most) and for which no compiler can be fully conforming years after the specification was made is bad.
Also in my opinion, the 'bolted on' nature of C++ feels is really ugly (reference and pointers, urgg), whereas Java's shallow use of C syntax to ease migration seems sensible.