View mode: basic / threaded / horizontal-split · Log in · Help
April 16, 2005
Re: Robust, fault-tolerant software is easier to write with D than C++. Or is it? [was: Re: recoverable and unrecoverable errors or exceptions]
"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message
news:d3pu39$1lvp$1@digitaldaemon.com...
>
> "Walter" <newshound@digitalmars.com> wrote in message
> news:d3pt4i$1lb6$1@digitaldaemon.com...
> >
> > "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message
> > news:d3po2o$1iek$2@digitaldaemon.com...
> >> Then if he did, he would need to supply a motivating example for
> >> "having a class of errors that is not catchable at all would be a
> >> mistake", because the word processor does not represent such. It
> >> can
> >> (do its best to) save the data without violating
> >> irrecoverability.
> >
> > Here's one. One garbage collection strategy is to set pages in the
> > gc heap
> > as 'read only'. Then set up an exception handler to catch the GP
> > faults from
> > writes to those pages. Internally mark those pages as 'modified'
> > and then
> > turn off the read only protection on the page. Restart the
> > instruction that
> > caused the GP fault.
>
> Sorry to be so brusque, but that's pure piffle. In such a case, the
> programmer who is designing their software is designating the
> (processing of the) hardware exception as a part of the normal
> processing of their application. It in no way represents a violation
> of the design, since it's part of the design.

I thought we were talking about the D programming language specifying a
class as being not catchable. The example I gave is about a program design
where the programmer needs to catch such exceptions. D, being a system
programming language, has to allow any exception to be caught at the
programmer's discretion.

I obviously have no idea what you're talking about when you asked for an
example.
April 16, 2005
Re: Robust, fault-tolerant software is easier to write with D than C++. Or is it? [was: Re: recoverable and unrecoverable errors or exceptions]
"Walter" <newshound@digitalmars.com> wrote in message
news:d3q0ll$1nlj$1@digitaldaemon.com...
>
> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message
> news:d3pu39$1lvp$1@digitaldaemon.com...
>>
>> "Walter" <newshound@digitalmars.com> wrote in message
>> news:d3pt4i$1lb6$1@digitaldaemon.com...
>> >
>> > "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message
>> > news:d3po2o$1iek$2@digitaldaemon.com...
>> >> Then if he did, he would need to supply a motivating example
>> >> for
>> >> "having a class of errors that is not catchable at all would
>> >> be a
>> >> mistake", because the word processor does not represent such.
>> >> It
>> >> can
>> >> (do its best to) save the data without violating
>> >> irrecoverability.
>> >
>> > Here's one. One garbage collection strategy is to set pages in
>> > the
>> > gc heap
>> > as 'read only'. Then set up an exception handler to catch the
>> > GP
>> > faults from
>> > writes to those pages. Internally mark those pages as
>> > 'modified'
>> > and then
>> > turn off the read only protection on the page. Restart the
>> > instruction that
>> > caused the GP fault.
>>
>> Sorry to be so brusque, but that's pure piffle. In such a case,
>> the
>> programmer who is designing their software is designating the
>> (processing of the) hardware exception as a part of the normal
>> processing of their application. It in no way represents a
>> violation
>> of the design, since it's part of the design.
>
> I thought we were talking about the D programming language
> specifying a
> class as being not catchable. The example I gave is about a
> program design
> where the programmer needs to catch such exceptions. D, being a
> system
> programming language, has to allow any exception to be caught at
> the
> programmer's discretion.
>
> I obviously have no idea what you're talking about when you asked
> for an
> example.

Well the heat of the recent debate has been that some people have
argued that there are exceptions to the Principle of
Irrecoverability. I've conceded - and, of course, use of every day -
that there are _practical_ exceptions to the rule, but they are
based on the knowledge that one operates a piece of software, in
such circumstances, _outside_ the parameters of its design. Some
have argued that the Principle of Irrecoverability does not hold in
all cases, which has been the primary source of the heat.

[FWIW, I've been busy in finalising the draft of "The Nuclear
Reactor and the Deep Space Probe", which I started in October, over
the last few days. It's had a number of improvements as a result of
the scorching analysis of my ideas, and has some new sections,
including "The Fallacy of the Recoverable Precondition", which I
believe proves that point completely. I shall have it to Bjorn in a
couple of days, and then hopefully it'll be out on TCS within about
a week.]

The practical side of the debate has been that some people have
argued that D does not need to support irrecoverability. Being
dogmatic about the _principle_ - in secret I'm eminently reasonable
about the practice - I've argued that D should make a strict
interpretation of the principle, such that a new 'exception' type,
ContractViolation (or whatever) would be indeed irrecoverable
(although it would be infinitely catchable (and rethrown, explicitly
or implicitly) all the way up to main()). One of the reasons for the
strictness of my position has been that there is no way to supply
irrecoverability on D - other than to just call some
exitWithReason() function at the point of violation.

Over the last few days, however, I've moved in behind Georg's idea
that D should support precisely two modes of compilation/execution:
with-CP and without-CP. This seems the only practicable measure that
will satisfy all parties.

The only area of doubt as to the viability of this solution is what
would happen with heterogeneous mixes of dynamically merged link
units. That is, what happens if a CP process loads a (violating)
non-CP plug-in? It just crashes without invoking the graceful
shutdown / logging stuff, I guess. Conversely, if a non-CP process
loads a (violating) CP plug-in? Same thing happens, I guess. I'm
interested in people's thoughts on this.


As for my asking for an example: you'd said "There isn't one size
that fits all applications, the engineer writing the program will
have to decide. Therefore, having a class of errors that is not
catchable at all would be a mistake.". Assuming by "not catchable"
you meant "not recoverable", I think you're wrong, and was asking
for a motivating example, since no-one, not in this debate nor the
one you and I had with the TCS people in October, nor in any others,
has ever been able to provide one that violates the principle.
That's all. :-)
April 16, 2005
Re: recoverable and unrecoverable errors or exceptions
"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message
news:d3ptmg$1llb$1@digitaldaemon.com...
> But, my friend, you've just done your usual and not answered the
> point I made. I disagree with none of the contents of this post,
> save for the implication that it addresses my point.

Your point, as I saw it, was that D doesn't address the
"larger/deeper/harder" problems. I addressed it by disagreeing with your
classification about what were the hard problems.

> The issue I have with many languages that appear, on the surface, to
> be 'better' than C++ is that the limits they place on the
> experienced programmer are usually very hard. An example we've seen
> with D in recent days is that we need compiler support for
> irrecoverability.

I'm at a loss understanding what you mean by irrecoverability. Perhaps a
pointer to the thread?

> Now whether as a result of the singular genius of Dr Stroustrup, or
> as an emergent property of its complexity, C++ has, for the
> ingenious/intrepid, almost infinite capacity for providing fixes to
> the language by dint of libraries.

I know of no C++ capacity to fix the:

   Foo *p;

uninitialized pointer problem. This is a large, hard, deep problem in my
opinion. Based on my experience helping others debug code over the years,
this is the #2 costliest problem. Memory allocation problems is #1 (and is
largely addressed by moving to automatic memory management).

> Look at my fast string
> concatenation, at Boost's Lambda, etc. etc. Other languages are left
> for dead in this regard.
>
> In this regard, D is a second class citizen to C++, probably by
> design, and probably for good reason. After all, most of the
> ingenious solutions in C++ are not accessible to most programmers,
> even very experienced ones, as it's just so complex and susceptible
> to dialecticism. But if D proscribes this (arguably semi-insane)
> level of ingenuity, then, IMO, it should address the fundamental
> "big" issues more seriously than it does. Otherwise, people who can
> reach answers for their biggest questions in other languages are
> going to, as I currently do, find it impossible to digest blanket
> statements about D's superiority.

There's no way to do CP in C++ in the general case. I know you're sold on
what CP can do for program robustness. Can't do foreach. No nested
functions. No function literals. No UTF. These things are simple and easy to
use in D, and accessible to ordinary programmers. The Boost stuff is
generally neither. A lot of Boost is devoted to solving problems with C++
that aren't problems in D.

That said, once D gets implicit template function instantiation, it'll leave
C++ metaprogramming behind.

P.S. As you know, I converted DMDScript from C++ to D. The source code
shrunk by about 1/3, line for line, even *excluding* the gc I wrote for C++
and all the other support code C++ needed. The code runs faster, took me a
whole week to get debugged and through the test suite, is easier to
understand, and is much less brittle.

As a challenge to you, take the D version of DMDScript and convert it back
to C++. Use Boost, whatever you want. I'd love to see the results. Heck,
it'd make a great case history for an article series you can do!
April 16, 2005
Re: Robust, fault-tolerant software is easier to write with D than C++. Or is it? [was: Re: recoverable and unrecoverable errors or exceptions]
"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message
news:d3pt4s$1lbb$1@digitaldaemon.com...
> My analogy with systems on an airplane is that the code that realized a
> subsystem failed and decided to shut that particular subsystem down
> effectively "caught" the problem in the subsystem. The same approach
applies
> to a piece of software that catches a problem in a subsystem and deals
with
> it. Just as an error in a subsystem on an airplane doesn't shut down the
> entire airplane so an error in a subsystem in a piece of software should
> shut down the entire software. I agree the level of safety and reduncancy
is
> much higher in an airplane but my argument was that *something* on that
> airplane realized the subsystem was in error and dealt with it.

Ok. We're on the same page, then.
April 16, 2005
Re: recoverable and unrecoverable errors or exceptions
"Walter" <newshound@digitalmars.com> wrote in message 
news:d3q3jv$1q48$1@digitaldaemon.com...
>
> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message
> news:d3ptmg$1llb$1@digitaldaemon.com...
>> But, my friend, you've just done your usual and not answered the
>> point I made. I disagree with none of the contents of this post,
>> save for the implication that it addresses my point.
>
> Your point, as I saw it, was that D doesn't address the
> "larger/deeper/harder" problems. I addressed it by disagreeing 
> with your
> classification about what were the hard problems.
>
>> The issue I have with many languages that appear, on the surface, 
>> to
>> be 'better' than C++ is that the limits they place on the
>> experienced programmer are usually very hard. An example we've 
>> seen
>> with D in recent days is that we need compiler support for
>> irrecoverability.
>
> I'm at a loss understanding what you mean by irrecoverability. 
> Perhaps a
> pointer to the thread?
>
>> Now whether as a result of the singular genius of Dr Stroustrup, 
>> or
>> as an emergent property of its complexity, C++ has, for the
>> ingenious/intrepid, almost infinite capacity for providing fixes 
>> to
>> the language by dint of libraries.
>
> I know of no C++ capacity to fix the:
>
>    Foo *p;
>
> uninitialized pointer problem. This is a large, hard, deep problem 
> in my
> opinion. Based on my experience helping others debug code over the 
> years,
> this is the #2 costliest problem. Memory allocation problems is #1 
> (and is
> largely addressed by moving to automatic memory management).
>
>> Look at my fast string
>> concatenation, at Boost's Lambda, etc. etc. Other languages are 
>> left
>> for dead in this regard.
>>
>> In this regard, D is a second class citizen to C++, probably by
>> design, and probably for good reason. After all, most of the
>> ingenious solutions in C++ are not accessible to most 
>> programmers,
>> even very experienced ones, as it's just so complex and 
>> susceptible
>> to dialecticism. But if D proscribes this (arguably semi-insane)
>> level of ingenuity, then, IMO, it should address the fundamental
>> "big" issues more seriously than it does. Otherwise, people who 
>> can
>> reach answers for their biggest questions in other languages are
>> going to, as I currently do, find it impossible to digest blanket
>> statements about D's superiority.
>
> There's no way to do CP in C++ in the general case. I know you're 
> sold on
> what CP can do for program robustness. Can't do foreach. No nested
> functions. No function literals. No UTF. These things are simple 
> and easy to
> use in D, and accessible to ordinary programmers. The Boost stuff 
> is
> generally neither. A lot of Boost is devoted to solving problems 
> with C++
> that aren't problems in D.
>
> That said, once D gets implicit template function instantiation, 
> it'll leave
> C++ metaprogramming behind.
>
> P.S. As you know, I converted DMDScript from C++ to D. The source 
> code
> shrunk by about 1/3, line for line, even *excluding* the gc I 
> wrote for C++
> and all the other support code C++ needed. The code runs faster, 
> took me a
> whole week to get debugged and through the test suite, is easier 
> to
> understand, and is much less brittle.
>
> As a challenge to you, take the D version of DMDScript and convert 
> it back
> to C++. Use Boost, whatever you want. I'd love to see the results. 
> Heck,
> it'd make a great case history for an article series you can do!

Sigh. This is just more "D has all these great features" propaganda 
again. You're not answering my points, just telling me that D is 
really good at chewing much of the existing low-hanging fruit, and 
_some_ of the high.

My thesis is that there is precious little (if any) evidence for 
reasons not to chew most/all of the high, and also that it's 
introduced some of its own new low.

But I know you just don't see this, so I yield.
April 16, 2005
Re: recoverable and unrecoverable errors or exceptions
> An example we've seen 
> with D in recent days is that we need compiler support for 
> irrecoverability.


> Now whether as a result of the singular genius of Dr Stroustrup, or 
> as an emergent property of its complexity, C++ has, for the 
> ingenious/intrepid, almost infinite capacity for providing fixes to 
> the language by dint of libraries. Look at my fast string 
> concatenation, at Boost's Lambda, etc. etc. Other languages are left 
> for dead in this regard.


What kind of argument is that? C++'s flaws can be fixed by writing some 
code, but you don't allow the same to D. If you don't want to recover 
from CP violations, then don't, and there you have irrecoverability. 
Isn't that a far cleaner solution to not recovering, compared to the 
language-assisted purist library writer shooting your app in the head 
(and I don't mean you personally here)?

Furthermore, considering that D has support for inline assembler, you 
can code absolutely anything you want. So, make us all happy, like you 
did for C++, and write a function that does whatever an irrecoverable 
exception proceeding down the call stack would do, and we'll all be able 
to use it when we want.


xs0
April 16, 2005
Re: recoverable and unrecoverable errors or exceptions
In article <d3q625$1ss3$1@digitaldaemon.com>, Matthew says...
>
>
>"Walter" <newshound@digitalmars.com> wrote in message 
>news:d3q3jv$1q48$1@digitaldaemon.com...
>>
>> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message
>> news:d3ptmg$1llb$1@digitaldaemon.com...
>>> But, my friend, you've just done your usual and not answered the
>>> point I made. I disagree with none of the contents of this post,
>>> save for the implication that it addresses my point.
>>
>> Your point, as I saw it, was that D doesn't address the
>> "larger/deeper/harder" problems. I addressed it by disagreeing 
>> with your
>> classification about what were the hard problems.
>>
>>> The issue I have with many languages that appear, on the surface, 
>>> to
>>> be 'better' than C++ is that the limits they place on the
>>> experienced programmer are usually very hard. An example we've 
>>> seen
>>> with D in recent days is that we need compiler support for
>>> irrecoverability.
>>
>> I'm at a loss understanding what you mean by irrecoverability. 
>> Perhaps a
>> pointer to the thread?
>>
>>> Now whether as a result of the singular genius of Dr Stroustrup, 
>>> or
>>> as an emergent property of its complexity, C++ has, for the
>>> ingenious/intrepid, almost infinite capacity for providing fixes 
>>> to
>>> the language by dint of libraries.
>>
>> I know of no C++ capacity to fix the:
>>
>>    Foo *p;
>>
>> uninitialized pointer problem. This is a large, hard, deep problem 
>> in my
>> opinion. Based on my experience helping others debug code over the 
>> years,
>> this is the #2 costliest problem. Memory allocation problems is #1 
>> (and is
>> largely addressed by moving to automatic memory management).
>>
>>> Look at my fast string
>>> concatenation, at Boost's Lambda, etc. etc. Other languages are 
>>> left
>>> for dead in this regard.
>>>
>>> In this regard, D is a second class citizen to C++, probably by
>>> design, and probably for good reason. After all, most of the
>>> ingenious solutions in C++ are not accessible to most 
>>> programmers,
>>> even very experienced ones, as it's just so complex and 
>>> susceptible
>>> to dialecticism. But if D proscribes this (arguably semi-insane)
>>> level of ingenuity, then, IMO, it should address the fundamental
>>> "big" issues more seriously than it does. Otherwise, people who 
>>> can
>>> reach answers for their biggest questions in other languages are
>>> going to, as I currently do, find it impossible to digest blanket
>>> statements about D's superiority.
>>
>> There's no way to do CP in C++ in the general case. I know you're 
>> sold on
>> what CP can do for program robustness. Can't do foreach. No nested
>> functions. No function literals. No UTF. These things are simple 
>> and easy to
>> use in D, and accessible to ordinary programmers. The Boost stuff 
>> is
>> generally neither. A lot of Boost is devoted to solving problems 
>> with C++
>> that aren't problems in D.
>>
>> That said, once D gets implicit template function instantiation, 
>> it'll leave
>> C++ metaprogramming behind.
>>
>> P.S. As you know, I converted DMDScript from C++ to D. The source 
>> code
>> shrunk by about 1/3, line for line, even *excluding* the gc I 
>> wrote for C++
>> and all the other support code C++ needed. The code runs faster, 
>> took me a
>> whole week to get debugged and through the test suite, is easier 
>> to
>> understand, and is much less brittle.
>>
>> As a challenge to you, take the D version of DMDScript and convert 
>> it back
>> to C++. Use Boost, whatever you want. I'd love to see the results. 
>> Heck,
>> it'd make a great case history for an article series you can do!
>
>Sigh. This is just more "D has all these great features" propaganda 
>again. You're not answering my points, just telling me that D is 
>really good at chewing much of the existing low-hanging fruit, and 
>_some_ of the high.
>
>My thesis is that there is precious little (if any) evidence for 
>reasons not to chew most/all of the high, and also that it's 
>introduced some of its own new low.
>
>But I know you just don't see this, so I yield.

GC, auto-init of data, checking of switch defaults, array bounds checking, and
especially null checking have been quite valuable to me for reliability.

GC and auto-init in particular are useful, no just because they provide
reliability, but because they unclutter the code.  For me a top contender for
bug incidence in C++ is simply that so much has to be specified, that the extra
syntax provides cover for broken code.

On another note, recently I converted an AI toy program from Java to D, then
tightened up the performance (by many orders of magnitude).  I simply renamed
the files to ".d", and was amazed to discover that after fixing the syntax
errors and implementing a few missing parts, there was only one code error:
argc was off by one (language difference).  After that, it -just ran-.

In other words, the syntax is very good at guiding you hand.  In C++ many many
things are legal code but don't do what is expected.  The D version caught
virtually everything at compile time.

Thanks, Walter.

Kevin

(P.S. If anyone wants a program to solve Sokoban puzzles in D...)
April 16, 2005
Re: recoverable and unrecoverable errors or exceptions
"Kevin Bealer" <Kevin_member@pathlink.com> wrote in message
news:d3qdtc$23js$1@digitaldaemon.com...
> GC, auto-init of data, checking of switch defaults, array bounds checking,
and
> especially null checking have been quite valuable to me for reliability.
>
> GC and auto-init in particular are useful, no just because they provide
> reliability, but because they unclutter the code.  For me a top contender
for
> bug incidence in C++ is simply that so much has to be specified, that the
extra
> syntax provides cover for broken code.

Yes. For example, most declarations in C++ have to be done twice.
Differences can inadvertently creep in. This is not what one would expect to
see in a modern language. Just being able to express directly what you want
to be done improves the reliability of the code, as you wrote.

> On another note, recently I converted an AI toy program from Java to D,
then
> tightened up the performance (by many orders of magnitude).  I simply
renamed
> the files to ".d", and was amazed to discover that after fixing the syntax
> errors and implementing a few missing parts, there was only one code
error:
> argc was off by one (language difference).  After that, it -just ran-.

Cool. I hadn't tried converting any Java programs. Converting C++ code
involves hitting the delete key a lot <g>. The real algorithm emerges from
the baggage. That's one of the reasons why the D version of DMDScript is
faster than the C++. I could see the algorithm better, and so it was easier
to tweak.

> In other words, the syntax is very good at guiding you hand.  In C++ many
many
> things are legal code but don't do what is expected.  The D version caught
> virtually everything at compile time.
>
> Thanks, Walter.

You're welcome.
April 16, 2005
Re: recoverable and unrecoverable errors or exceptions
Kevin Bealer wrote:
> GC, auto-init of data, checking of switch defaults, array bounds checking, and
> especially null checking have been quite valuable to me for reliability.
> 
> GC and auto-init in particular are useful, no just because they provide
> reliability, but because they unclutter the code.  For me a top contender for
> bug incidence in C++ is simply that so much has to be specified, that the extra
> syntax provides cover for broken code.
> 
> On another note, recently I converted an AI toy program from Java to D, then
> tightened up the performance (by many orders of magnitude).  I simply renamed
> the files to ".d", and was amazed to discover that after fixing the syntax
> errors and implementing a few missing parts, there was only one code error:
> argc was off by one (language difference).  After that, it -just ran-.
> 
> In other words, the syntax is very good at guiding you hand.  In C++ many many
> things are legal code but don't do what is expected.  The D version caught
> virtually everything at compile time.
> 
> Thanks, Walter.
> 
> Kevin
> 
> (P.S. If anyone wants a program to solve Sokoban puzzles in D...)

Hi Kevin, I'm interested in the pruning algorithm of your Sokoban solver.
April 16, 2005
Re: recoverable and unrecoverable errors or exceptions
In article <d3prc1$1k77$1@digitaldaemon.com>, Walter says...
>
>
>I'm going to posit that your 10+ years of professional experience in C++
>might be skewing your perceptions here. I have nearly 20 years experience
>writing C++, and I rarely make mistakes any more that are not algorithmic
>(rather than dumb things like forgetting to initialize). I am so *used* to
>C++ that I've learned to compensate for its faults, potholes, and goofball
>error prone issues, such that they aren't a personal issue with me anymore.
>I suspect the same goes for you.

Same here.  But I assume Matthew is suggesting fixes for problems he's had in
the passt.

>P.S. I said these C++ problems rarely cause me trouble anymore in my own
>code. So why fix them? Because I remember the trouble that they used to
>cause me, and see the trouble they cause other people. Being in the compiler
>business, I wind up helping a lot of people with a very wide variety of
>code, so I tend to see what kinds of things bring on the grief.

As I assume Matthew is doing with his suggestions.

>P.P.S. I believe the C++ uninitialized variable problem is a far deeper and
>costlier one than you seem willing to credit it for. It just stands head,
>shoulders, and trunk above most of the other problems with the exception of
>goofing up managing memory allocations. It's one of those things that I have
>lost enormous time to, and as a consequence have learned a lot of
>compensations for. I suspect you have, too.

Personally, this has never been much of an issue for me, as I've always been
diligent about initializing variables.  At the same time, I do support your
efforts here as when these bugs do occur they're a nightmare to track down.

>P.P.P.S. I know for a fact that I spend significantly less time writing an
>app in D than I would the same thing in C++, and that's including debugging
>time. There's no question about it. When I've translated working & debugged
>apps from C++ to D, D's extra error checking exposed several bugs that had
>gone undetected by C++ (array overflows was a big one), even one with the
>dreaded C++ implicit default break; in the switch statement <g>.

Agreed :)  This is one reason I have so much faith in D--I have far less
experience with it than with C++ and yet I still find myself more productive
with D.


Sean
6 7 8 9 10 11 12 13 14
Top | Discussion index | About this forum | D home