"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.

"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. :-)

"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!

"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.

"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.

> 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

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...)

"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.

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.

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