note
ady
I agree with this.<br> I also enjoyed Bjarne Stroustrup's comments on <b>the evolution of C++ vs Java</b> (in : <a href="http://research.att.com/~bs/hopl-almost-final.pdf">Evolving a language...</a>), technically and - not the least - in the marketplace (<i>the “genes” of C++ and Java</i>) ...<br>
<br>
<readmore>
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:<br>
<br>
<i>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.</i><br>
<br>
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.<br>
<br>
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,<br>
<ol>• C++ relies on direct access to hardware resources to
achieve many of its goals whereas Java relies on a virtual
machine to keep it away from the hardware.</ol>
<ol>• C++ is deliberately frugal with run-time support whereas Java relies on a significant amount of metadata</ol>
<ol>• C++ emphasizes interoperability with code written in
other languages and sharing of system tools (such as
linkers) whereas Java aims for simplicity by isolating
Java code from other code.</ol><br>
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.<br>
<br>
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++.
<i>“What Bjarne would have designed if he hadn’t had to be
compatible with C”</i> 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:<br>
<ol>• Use of static type checking and Simula-like
classes.</ol>
<ol>• Clean separation between language and environment.</ol>
<ol>• C source compatibility (“as close as possible”).</ol>
<ol>• C link and layout compatibility (“genuine local
variables”).</ol>
<ol>• No reliance on garbage collection.</ol>
<br>
<br>
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, <i>‘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><br>
<br>
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:<br>
<ol>• Provide as good support for user-defined types as for
built-in types</ol>
<ol>• Leave no room for a lower-level language below C++
(except assembler)</ol>
<br>
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”).<br>
<br>
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 <i>“reliable code cannot be written in C/C++
because they don’t have exceptions”</i> (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.<br>
<br>
Despite many promises, Java didn’t replace C++ (<i>“Java
will completely kill C++ within two years”</i> 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.<br>
<br>
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.<br>
<br>
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.<br>
</readmore>
<br>
Bjarne Stroustrup goes on to describe the early .NET
platform with <i>C++/CLI extensions</i> (the precursor to C#) and also mentions <b>some major MS applications based on C++</b> :<br>
<br>
<ol>• Windows XP</ol>
<ol>• Office</ol>
<ol>• Internet explorer</ol>
<ol>• Visual Studio</ol>
<ol>• .Net</ol>
<ol>• C# compiler</ol>
<br>
Best regards,<br>
<i> Allan Dystrup</i>
681389
681485