Re: Some errors in MIT's intro C++ course
On Sep 18, 4:49 am, Daniel <danielapar...@gmail.com> wrote:
On Sep 16, 4:51 am, James Kanze <james.ka...@gmail.com>
wrote:> On Sep 12, 3:48 pm, Daniel <danielapar...@gmail.com>
wrote:
On Sep 11, 3:54 pm, James Kanze <james.ka...@gmail.com> wrote:
Most of the larger Java projects
I've seen have been, in fact, GUI front ends to other tools
(e.g. Eclipse). Java is very good for GUI's, not because of the
language, but because of its libraries.
On the contrary, Java has had very little success on the GUI
side. Eclipse may be an exception, but it deliberately
eschewed the standard Java Swing components, and went its own
way. Personally, I don't particularly care for it as a
development tool, it's very heavy,
It's an IDE, which attempts to encompass everything. Visual
Studios is written in C++, and it's also very heavy:-).
but its success is largely attributable to its ability to
front a huge and diverse collection of enterprise tooling,
much of it written in Java.
Which brings us to the area where Java has thrived over the last
decade, on the server side: enterprise middleware, high end workflow
products, business orchestration tooling, fault tolerant middleware,
messaging infrastructure, etc.
Java is very successful in contexts where plugins are wanted.
The kernel code will be written in C or C++, but will provide a
JVM, so user defined classes can be loaded. In this context,
the Java distribution model does have significant advantages: a
plugin written for one system will (presumably) work on another,
and the JVM provides a sandbox so that the plugin cannot
(presumably) corrupt the main application.
The vast majority of the new tooling
in this space, from TIBCO, IBM, BEA and SUN (since absorbed by
Oracle), as well as new entrants, has been written in Java, and the
new products have been displacing the previous generation of tooling
that was written in C/C++.
I'm not sure how much of the actual root products is written in
Java. But they do provide a Java interface for plugins. And
they tend to use Java a lot for auxiliary functionality, since
these are generally implemented as plugins as well.
Depending on what you're targetting, Java's distribution model
(with one jar file for all platforms) may be an advantage or
a disadvantage (the "write once, debug everywhere" syndrome).
Whether you choose Java, C# or C++
for such projects depends on a lot of issues: Java is clearly
the least powerful langauge of the three, but distribution
issues may make it preferrable.
I think the vendors of enterprise middleware would not agree with your
assessment.
Not if they're trying to sell their customers Java
interfaces:-).
The movement from C/C++ to Java was motivated largely by
convenience, the convenience of using a language that offered
reasonable support for character encoding standards, that offered
support for calendars and dates, that supported threading and garbage
collection, that offered reflection and with it made configuration
easy, that didn't suffer from the security holes opened up by off-by-
one errors, that offered a simpler programming model, that was well
supported on UNIX.
That was Sun's original argument. Experience has shown that it
isn't totally valid. Or rather, that while Java did bring in a
number of new advantages, it threw out much of the essential.
Of course, ease of deployment and distribution were part of
it.
That, and the libraries, are the big reasons Java is used
today. With regards to the other points:
-- Threading may have been missing in the C++ standard, but
there are a lot of multi-threaded applications written in
C++ anyway. In practice, it's just as present in C++ as in
Java.
-- Garbage collection is an issue. Theoretically, it's
available as a third party plugin in C++, but it's not that
much used. Of course, if you're using value semantics (as
C++ does), it's less of an issue than for Java, but it would
still be nice (and it's absense does create serious security
issues).
-- Reflection is nice for debuggers and such (and some types of
plugins), but is not generally very useful. I've rarely
seen it used in actual Java applications, or if so, only in
very trivial ways that can easily be emulated (more safely,
in fact) in C++.
-- Off by one errors are a serious problem where C interfaces
are involved, but in pure C++, you just use one of the
mainstream standard libraries (Dinkumware or g++), and you
have bounds checking.
A lot of the open source projects seem to be open source just to
show off how poorly they are engineered:-).
You mean the boost libraries :-)
Some of them, maybe, but on the whole, they are well engineered
with regards to the goals they set. (Whether those goals are
appropriate for your project is another issue.)
But I was thinking more of the tons of projects you see by one
or two people.
Seriously, I've only looked at a
small subset of these libraries, but my experience is bad.
Constructing an inverse t distribution doesn't work, the results of
const boost::math::students_t dist(dof);
const double t = boost::math::quantile(dist, y);
are pathological. banded_matrix doesn't work, multiplications go away
forever as the dimensions go up. This wouldn't be quite so irritating
if there weren't all those comments on the web about how boost was
developed by the best programmers in the world, people who are really
good don't need that.
It depends on the library. Some are better than others, and
some are not particularly good. (I'm not familiar with the math
library, so I can't comment here.)
In numerics, you have to test everything, you can't release
code that doesn't work.
In numerics, testing isn't sufficient. You have to analyse the
program logic manually to ensure numeric stability. (That
doesn't mean you shouldn't test, but that you need more than
just testing.)
--
James Kanze