Re: The D Programming Language
James Kanze wrote:
Andrei Alexandrescu (See Website For Email) wrote:
I think it's one thing to have a wrong numeric value and one very
different thing to have a program in which all hell breaks looks due to
random overwriting of memory.
But nobody's really disagreeing. Being able to accidentally
randomly overwrite memory is hardly what I would call a feature.
(Being able to do it intentionally, e.g. with a
reinterpret_cast, is a necessary feature if you want to develope
kernel code, but that's a different issue.)
On the other hand, faced with a serious program error (e.g.
inconsistent values resulting from a race condition), having all
hell break loose is certainly preferrable to silently continuing
and pretending that all is well. And issuing a market order to
buy when our customer said sell.
The problem is that the hell could break loose by also issuing a market
order to buy when our customer said sell.
The problem with a program is not that it crashes - that would be great
- but that it can do anything, including not crashing.
I guess the set of "all hell breaks loose" is much larger, and includes,
the set "there is one incorrect value". I am sitting here in amazement I
have so much trouble getting this point across.
Well the only thing I can add is that in my limited experience,
debugging Java programs is much easier because there's never the case
that a dangling pointer misteriously overwrites some object it wasn't
supposed to.
That's not been my experience. I found debugging Java programs
exceedingly difficult---the event handler in AWT/Swing silently
ate all exceptions, so when you dereferenced a null pointer, you
simply silently didn't finish handling the event, rather than
crashing noisily.
So I guess you have libraries that suck. Nothing new :o).
More importantly, of course, I found writing correct programs in
Java considerably more difficult, because everything derived
from object, and your collections weren't typesafe. Which meant
I had a lot more debugging to do---in general, in C++, if my
code passes the compiler, it works. (Not always, of course, but
in general, after successful compilation and code review, I can
count on one error per 100000 lines of code in C++, but close to
10 times as many in Java.)
I'm not sure how such personal anecdotes relate to the undefined
behavior issue, however. I don't think that there's any doubt
that Java has a lot less undefined behavior than C++: you claim
zero, and I claim that there are a very few special cases, where
as C++ has it all over the place.
I am eager to hear about the few special cases, and I have tried to
substantiate my point with what I found on the net. Would somebody
please oblige.
I don't think that there's
any doubt either that undefined behavior is bad, in itself. And
I certainly hope we agree that it is only one factor, and that
there are a lot of other factors which affect the difficulty of
writing correct code, or debugging incorrect code. (The biggest
problems I had in debugging Java were due to the defined
behavior doing the wrong thing---throwing an exception rather
than crashing---and an incredibly stupid decision to ignore the
exception in the standard library. That and the lack of strong
typing on variable sized containers---I understand that has
since been fixed.)
So we have bad libraries and a problem that's been fixed... pretty nice.
To be honest, the first problem I've had in my Java apps was that it's
slow like molasses running uphill on a cold day in rough terrain for
what I'm doing in my research. Our lab actually has a ban against
running Java or much Perl on the computing cluster, because it just
wastes precious resources. Perhaps they could be talked into allowing D :o).
Andrei
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]