|Just another Perl shrine|
I agree with this.
I also enjoyed Bjarne Stroustrup's comments on the evolution of C++ vs Java (in : Evolving a language...), technically and - not the least - in the marketplace (the “genes” of C++ and Java) ...
I prefer not to compare C++ to other programming languages. For example, in the “Notes to the Reader” section of D&E 121, I write:
Several reviewers asked me to compare C++ to other languages. This I have decided against doing. ... Language comparisons are rarely meaningful and even less often fair. A good comparison of major programming languages requires more effort than most people are willing to spend, experience in a wide range of application areas, a rigid maintenance of a detached and impartial point of view, and a sense of fairness. I do not have the time, and as the designer of C++, my impartiality would never be fully credible. ... Worse, when one language is significantly better known than others, a subtle shift in perspective occurs: Flaws in the well-known language are deemed minor and simple workarounds are presented, whereas similar flaws in other languages are deemed fundamental. Often, the workarounds commonly used in the less-wellknown languages are simply unknown to the people doing the comparison or deemed unsatisfactory because they would be unworkable in the more familiar language. ... Thus, I restrict my comments about languages other than C++ to generalities and to very specific comments.
However, many claims about the C++/Java relationship have been made and the presence of Java in the marketplace has affected the C++ community.Consequently, a few comments are unavoidable even though a proper language comparison is far beyond the scope of this paper and even though Java has left no traces in the C++ definition.
Why not? From the earliest days of Java, the C++ committee has always included people with significant Java experience: users, implementers, tool builders, and JVM implementers. I think at a fundamental level Java and C++ are too different for easy transfer of ideas. In particular,
The “genes” of C++ and Java are quite dissimilar. The syntactic similarities between Java and C++ have often been deceptive. As an analogy, I note that it is far easier for English to adopt “structural elements” from closely related languages, such as French or German, than from more different languages, such as Japanese or Thai.
Java burst onto the programming scene with an unprecedented amount of corporate backing and marketing (much aimed at non-programmers). According to key Sun people (such as Bill Joy), Java was an improved and simplified C++. “What Bjarne would have designed if he hadn’t had to be compatible with C” was — and amazingly still is — a frequently heard statement. Java is not that; for example, in D&E §9.2.2, I outlined fundamental design criteria for C++: What would be a better language than C++ for the things C++ is meant for? Consider the first-order decisions:
I still consider static type checking essential for good design and run-time efficiency.Were I to design a new language for the kind of work done in C++ today, I would again follow the Simula model of type checking and inheritance, not the Smalltalk or Lisp models. As I have said many times, ‘Had I wanted an imitation Smalltalk, I would have built a much better imitation. Smalltalk is the best Smalltalk around. If you want Smalltalk, use it’.
I think I could express that more clearly today, but the essence would be the same; these criteria are what define C++ as a systems programming language and what I would be unwilling to give up. In the light of Java, that section seems more relevant today than when I wrote it in 1993 (pre-Java). Having the built-in data types and operators mapped directly to hardware facilities and being able to exploit essentially every machine resource is implicit in “C compatibility”. C++ does not meet Java’s design criteria; it wasn’t meant to. Similarly, Java doesn’t meet C++’s design criteria. For example, consider a couple of language-technical criteria:
Many of the differences can be ascribed to the aim of keeping C++ a systems programming language with the ability to deal with hardware and systems at the lowest level and with the least overhead. Java’s stated aims seem more directed towards becoming an applications language (for some definition of “application”).
Unfortunately, the Java proponents and their marketing machines did not limit themselves to praising the virtues of Java, but stooped to bogus comparisons (e.g., 51) and to name calling of languages seen as competitors (most notably C and C++). As late as 2001, I heard Bill Joy claim (orally with a slide to back it up in a supposedly technical presentation) that “reliable code cannot be written in C/C++ because they don’t have exceptions” (see §5, §5.3). I see Java as a Sun commercial weapon aimed at Microsoft that missed and hit an innocent bystander: the C++ community. It hurt many smaller language communities even more; consider Smalltalk, Lisp, Eiffel, etc.
Despite many promises, Java didn’t replace C++ (“Java will completely kill C++ within two years” was a graphic expression I repeatedly heard in 1996). In fact, the C++ community has trebled in size since the first appearance of Java. The Java hype did, however, harm the C++ community by diverting energy and funding away from much-needed tools, library and techniques work. Another problem was that Java encouraged a limited “pure object-oriented” view of programming with a heavy emphasis on run-time resolution and a de-emphasis of the static type system (only in 2005 did Java introduce “generics”). This led many C++ programmers to write unnecessarily inelegant, unsafe, and poorly performing code in imitation. This problem gets especially serious when the limited view infects education and creates a fear of the unfamiliar in students.
As I predicted 136 when I first heard the boasts about Java’s simplicity and performance, Java rapidly accreted new features — in some cases paralleling C++’s earlier growth. New languages are always claimed to be “simple” and to become useful in a wider range of real-world applications they increase in size and complexity. Neither Java nor C++ was (or is) immune to that effect. Obviously, Java has made great strides in performance — given its initial slowness it couldn’t fail to — but the Java object model inhibits performance where abstraction is seriously used (§4.1.1, §4.1.4). Basically, C++ and Java are far more different in aims, language structure, and implementation model than most people seem to think. One way of viewing Java is as a somewhat restricted version of Smalltalk’s run-time model hidden behind a C++-like syntax and statically type-checked interfaces.
My guess is that Java’s real strength compared to C++ is the binary compatibility gained from Sun having de facto control of the linker as expressed through the definition of the Java virtual machine. This gives Java the link compatibility that has eluded the C++ community because of the decision to use the basic system linkers and the lack of agreement among C++ vendors on key platforms (§7.4). In the early 1990s, Sun developed a nice C++ compiler based on Mike Ball and Steve Clamage’s Taumetric compiler. With the release of Java and Sun’s loudly proclaimed pro-Java policy where C++ code was referred to (in advertising “literature” and elsewhere) as “legacy code” that needed rewriting and as “contamination”, the C++ group suffered some lean years. However, Sun never wavered in its support of the C++ standards efforts and Mike, Steve and others made significant contributions. Technical people have to live with technical realities—such as the fact that many Sun customers and many Sun projects rely on C++ (in total or in part). In particular, Sun’s Java implementation, HotSpot, is a C++ program.
Bjarne Stroustrup goes on to describe the early .NET platform with C++/CLI extensions (the precursor to C#) and also mentions some major MS applications based on C++ :