"Scott Wood" <scott@buserror.net> wrote in message news:slrnd0cocc.5nk.nospam@odin.buserror.net...
> No, its root cause *is* bad programmers.  A good programmer would not interpret a missing-return error as an encouragement to mindlessly stick a "return 0;" in the code, but rather an indication that there's a code path that isn't properly terminated.

Back when I used to work for Boeing, a major focus of attention was making it impossible to cross the hydraulic lines to critical flight controls. There have been many crashes and near disasters from this happening. Measures taken include:

1) making sure the lines are not long enough to connect to the wrong port
2) using different diameter lines and fittings for each port
3) one one port use left hand threads, on the other use right hand threads
4) warnings and labels
5) test proceedures to verify correct hookup
6) preflight checks to verify correct hookup

Real life FAA certified mechanics sometimes went to astonishing lengths to idiotically cross the lines. You can't rely on better training, more certification, etc., eliminating the problem. You've got to design the machine to minimize the potential of mechanics getting it wrong. This kind of effort to eliminate tempting sources of error is pervasive in jetliner design.

We all have to work with "bad" programmers, we can't wish them away or assume that better training will transform them. Even great programmers make silly mistakes. I tried to design D in a way that doing the right thing is *less* work than doing the wrong thing. This is because the wrong things often happen because they are easier.

Sure, a determined mechanic could still cross the lines. But he's going to have to go through a great deal of effort to do it, and hopefully at some point the thought will cross his mind "this is too hard, I must be doing something wrong."

P.S. There was a crash a few years back of a fighter (not a Boeing design). The pitch controls were reversed. Reversing the controls on that bird was as easy as moving a control rod from one spot to the wrong one. Their ace mechanic did it by mistake, and the pilot didn't do his preflight checkout right. Both got blamed. Me, I blame the design of the flight controls.

http://www.aviationtoday.com/sia/20010801.htm http://www.ntsb.gov/ntsb/brief.asp?ev_id=20001212X24781&key=1

On Sat, 5 Feb 2005 13:34:54 -0600, Charles <no@email.com> wrote:
> I can see both your points.  And I do not want to gang up on Walter but
>
>> Q: Do you think driving on the left-hand side of the road is more or
>> less sensible than driving on the right?
>> A: When driving on the left-hand side of the road, be careful to monitor
>> junctions from the left.
>
> represents allot of responses from Walter when he's dead set on something.
>
> I agree that putting in "shut-up" code can indeed lead to more bugs like
> Walter was saying , but in this case , I don't think that a 'return'
> statement is one of them.  Using C/C++ its always been an error on my
> compilers to not have a return statement, and its _never_ been a problem (
> probably saved many bugs because of it ).  Have to agree 100% with Matthew
> on that one.

The problem is not whether compile time detecting missing returns is good or bad, most would agree that it's good.

IIRC the problem is that it's not possible to do it with 100% accuracy, and further doing it at to a degree that approaches 100% requires a lot of code which basically amounts to checking for each and every weird possible combination of factors.

> Now a switch with no default and no matching 'case' ? I can see the argument
> for that.  I think that is a good example of 'shut-up code' doing harm,
> where its better caught at runtime then at compile time.  But its almost
> GUARANTEED not to run right with a missing return statement , best to catch
> it at compile time.

We're not simply talking about a missing return. We're talking about a return which:

- The programmer believed was not required, as it would never be executed.
- The compiler complained about (correctly, but seemingly incorrectly).
- The programmer added a 'return 0;' "to shut it up"
- Which was then later executed.
- Causing un-expected behaviour, potentially un-noticed for ...

Regan

On Sun, 6 Feb 2005 13:35:14 -0800, Walter wrote:

> "Scott Wood" <scott@buserror.net> wrote in message news:slrnd0cocc.5nk.nospam@odin.buserror.net...
>> No, its root cause *is* bad programmers.  A good programmer would not interpret a missing-return error as an encouragement to mindlessly stick a "return 0;" in the code, but rather an indication that there's a code path that isn't properly terminated.
> 
> Back when I used to work for Boeing, a major focus of attention was making it impossible to cross the hydraulic lines to critical flight controls. There have been many crashes and near disasters from this happening. Measures taken include:
> 
> 1) making sure the lines are not long enough to connect to the wrong port
> 2) using different diameter lines and fittings for each port
> 3) one one port use left hand threads, on the other use right hand threads
> 4) warnings and labels
> 5) test proceedures to verify correct hookup
> 6) preflight checks to verify correct hookup
> 
> Real life FAA certified mechanics sometimes went to astonishing lengths to idiotically cross the lines. You can't rely on better training, more certification, etc., eliminating the problem. You've got to design the machine to minimize the potential of mechanics getting it wrong. This kind of effort to eliminate tempting sources of error is pervasive in jetliner design.
> 
> We all have to work with "bad" programmers, we can't wish them away or assume that better training will transform them. Even great programmers make silly mistakes. I tried to design D in a way that doing the right thing is *less* work than doing the wrong thing. This is because the wrong things often happen because they are easier.
> 
> Sure, a determined mechanic could still cross the lines. But he's going to have to go through a great deal of effort to do it, and hopefully at some point the thought will cross his mind "this is too hard, I must be doing something wrong."
> 
> P.S. There was a crash a few years back of a fighter (not a Boeing design). The pitch controls were reversed. Reversing the controls on that bird was as easy as moving a control rod from one spot to the wrong one. Their ace mechanic did it by mistake, and the pilot didn't do his preflight checkout right. Both got blamed. Me, I blame the design of the flight controls.
> 
> http://www.aviationtoday.com/sia/20010801.htm http://www.ntsb.gov/ntsb/brief.asp?ev_id=20001212X24781&key=1

It appears to me then that you now have DMD informing the pilot at 30,000 feet that the lines are crossed and the system is shutting down, rather than letting maintenance people on the ground know before the plane takes off.

-- 
Derek
Melbourne, Australia
7/02/2005 10:06:54 AM

Disclaimer: Please correct me if I have miss-represented anyone, I appologise in advance for doing so, it was not my intent.

The following is my impression of the points/positions in this argument:

1. Catching things at compile time is better than at runtime.
 - all parties agree

2. If it cannot be caught at compile time, then a hard failure at runtime is desired.
 - all parties agree

3. An error which causes the programmer to add code to 'shut the compiler up' causes hidden bugs
 - Walter

Matthew?

4. Programmers should take responsibilty for the code they add to 'shut the compiler up' by adding an assert/exception.
 - Matthew

Walter?

5. The language/compiler should where it can make it hard for the programmer to write bad code
 - Walter

Matthew?


IMO it seems to be a disagreement about what happens in the "real world", IMO Matthew has an optimistic view, Walter a pessimistic view, eg.

Matthew: If it were a warning, programmers would notice immediately, consider the error, fix it or add an assert for protection, thus the error would be caught immediately or at runtime.

It seems to me that Matthews position is that warning the programmer at compile time about the situation gives them the opportunity to fix it at compile time, and I agree.

Walter: If it were a warning, programmers might add 'return 0;' causing the error to remain un-detected for longer.

It seems to me that Walters position is that if it were a warning there is potential for the programmer to do something stupid, and I agree.

So why can't we have both?

To explore this, an imaginary situation:

- Compiler detects problem.
- Adds code to handle it (hard-fail at runtime).
- Gives notification of the potential problem.
- Programmer either:

 a. cannot see the problem, adds code to shut the compiler up. (causing removal of auto hard-fail code)

 b. cannot see the problem, adds an assert (hard-fail) and code to shut the compiler up.

 c. sees the problem, fixes it.

if a then the bug could remain undetected for longer.
if b then the bug is caught at runtime.
if c then the bug is avoided.

Without the notification (a) is impossible, so it seems Walters position removes the worst case scenario, BUT, without the notification (c) is impossible, so it seems Walters position removes the best case scenario also.

Of course for any programmer who would choose (b) over (a) 'all the time' Matthews position is clearly the superior one, however...

The real question is. In the real world are there more programmers who choose (a), as Walter imagines, or are there more choosing (b) as Matthew imagines?

Those that choose (a), do they do so out of ignorance, impatience, or stupidity? (or some other reason)

If stupidity, there is no cure for stupidity.

If impatience (as Walter has suggested) what do we do, can we do anything.

If ignorance, then how do we teach them? does auto-inserting the hard fail and giving no warning do so? would giving the warning do a better/worse job?

eg.

"There is the potential for undefined behaviour here, an exception has been added automatically please consider the situation and either: A. add your own exception or B. fix the bug."

Regan

On Sat, 5 Feb 2005 20:26:43 +1100, Matthew <admin@stlsoft.dot.dot.dot.dot.org> wrote:
>> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message
>> news:cu1pe6$15ks$1@digitaldaemon.com...
>>> > 1) make it impossible to ignore situations the programmer did not
>>> > think of
>>>
>>> So do I. So does any sane person.
>>>
>>> But it's a question of level, context, time. You're talking about two
>>> measures that are small-scale, whose effects may or may not ever be
>>> seen
>>> in a running system . If they do, they may or may not be in a
>>> context,
>>> and at a time, which renders them useless as an aid to improving the
>>> program.
>>
>> If the error is silently ignored, it will be orders of magnitude
>> harder to
>> find. Throwing in a return 0; to get the compiler to stop squawking is
>> not
>> helping.
>
> I'm not arguing for that!
>
> You have the bad habit of attributing positions to me that are either
> more extreme, or not representative whatsoever, in order to have
> something against which to argue more strongly. (You're not unique in
> that, of course. I'm sure I do it as well sometimes.)
>
>>> > 2) the bias is to force bugs to show themselves in an obvious
>>> > manner.
>>>
>>> So do I.
>>>
>>> But this statement is too bland to be worth anything. What's is
>>> "obvious"?
>>
>> Throwing an uncaught exception is designed to be obvious and is the
>> preferred method of being obvious about a runtime error.
>
> Man oh man! Have you taken up politics?
>
> My problem is that you're forcing issues that can be dealt with at
> compile time to be runtime. Your response: exceptions are the best way
> to indicate runtime error.
>
> Come on.
>
> Q: Do you think driving on the left-hand side of the road is more or
> less sensible than driving on the right?
> A: When driving on the left-hand side of the road, be careful to monitor
> junctions from the left.
>
>>> *Who decides* what is obvious? How does/should the bug show
>>> itself? When should the showing be done: early, or late?
>>
>> As early as possible. Putting in the return 0; means the showing will
>> be
>> late.
>
> Oh? And that'd be later than the compiler preventing it from even
> getting to object code in the first place?
>
>>> Frankly, one might argue that the notion that the language and its
>>> premier compiler actively work to _prevent_ the programmer from
>>> detecting bugs at compile-time, forcing a wait of an unknowable
>>> amount
>>> of testing (or, more horribly, deployment time) to find them, is
>>> simply
>>> crazy.
>>
>> I understand your point, but for this case, I do not agree for all the
>> reasons stated here. I.e. there are other factors at work, factors
>> that will
>> make the bugs harder to find, not easier, if your approach is used. It
>> is
>> recognition of how programmers really write code, rather than the way
>> they
>> are exhorted to write code.
>
> Disagree.
>
>>> But you're hamstringing 100% of all developers for the
>>> careless/unprofessional/inept of a few.
>>
>> I don't believe it is a few. It is enough that Java was forced to
>> change
>> things, to allow unchecked exceptions. People who look at a lot of
>> Java code
>> and work with a lot of Java programmers tell me it is a commonplace
>> practice, *even* among the experts. When even the experts tend to
>> write code
>> that is wrong even though they know it is wrong and tell others it is
>> wrong,
>> is a very strong signal that the language requirement they are dealing
>> with
>> is broken. I don't want to design a language that the experts will say
>> "do
>> as I say, not as I do."
>
> Yet again, you are broad-brushing your arbitrary (or at least partial)
> absolute decisions with a complete furphy. This is not an analogy, it's
> a mirror with some smoke machines behind it.
>
>>> Will those handful % of better-employed-working-in-the-spam-industry
>>> find no other way to screw up their systems? Is this really going to
>>> answer all the issues attendant with a lack of
>>> skill/learning/professionalism/adequate quality mechanisms (incl,
>>> design
>>> reviews, code reviews, documentation, refactoring, unit testing,
>>> system
>>> testing, etc. etc. )?
>>
>> D is based on my experience and that of many others on how programmers
>> actually write code, rather than how we might wish them to.
>> (Supporting a
>> compiler means I see an awful lot of real world code!) D shouldn't
>> force
>> people to insert dead code into their source. It's tedious, it looks
>> wrong,
>> it's misleading, and it entices bad habits even from expert
>> programmers.
>
> Sorry, but wrong again. As I mentioned in the last post, there's a
> mechanism for addressing both camps, yet you're still banging on with
> this all-or-nothing position.
>
>>> But I'm not going to argue point by point with your post, since you
>>> lost
>>> me at "Java's exceptions". The analogy is specious, and thus
>>> unconvincing. (Though I absolutely concur that they were a little
>>> tried
>>> 'good idea', like C++'s exception specifications or, in fear of
>>> drawing
>>> unwanted venom from my friends in the C++ firmament, export.)
>>
>> I believe it is an apt analogy as it shows how forcing programmers to
>> do
>> something unnatural leads to worse problems than it tries to solve.
>> The best
>> that can be said for it is "it seemed like a good idea at the time". I
>> was
>> at the last C++ standard committee meeting, and the topic came up on
>> booting
>> exception specifications out of C++ completely. The consensus was that
>> it
>> was now recognized as a worthless feature, but it did no harm (since
>> it was
>> optional), so leave it in for legacy compatibility.
>
> All of this is of virtually no relevance to the topic under discussion
>
>> There's some growing thought that even static type checking is an
>> emperor
>> without clothes, that dynamic type checking (like Python does) is more
>> robust and more productive. I'm not at all convinced of that yet <g>,
>> but
>> it's fun seeing the conventional wisdom being challenged. It's good
>> for all
>> of us.
>
> I'm with you there.
>
>>> My position is simply that compile-time error detection is better
>>> than
>>> runtime error detection.
>>
>> In general, I agree with that statement. I do not agree that it is
>> always
>> true, especially in this case, as it is not necessarilly an error. It
>> is
>> hypothetically an error.
>
> Nothing is *always* true. That's kind of one of the bases of my thesis.
>
>>> Now you're absolutely correct that an invalid state throwing an
>>> exception, leading to application/system reset is a good thing.
>>> Absolutely. But let's be honest. All that achieves is to prevent a
>>> bad
>>> program from continuing to function once it is established to be bad.
>>> It
>>> doesn't make that program less bad, or help it run well again.
>>
>> Oh, yes it does make it less bad! It enables the program to notify the
>> system that it has failed, and the backup needs to be engaged. That
>> can make
>> the difference between an annoyance and a catastrophe. It can help it
>> run
>> well again, as the error is found closer to the the source of it,
>> meaning it
>> will be easier to reproduce, find and correct.
>
> Sorry, but this is totally misleading nonsense. Again, you're arguing
> against me as if I think runtime checking is invalid or useless. Nothing
> could be further from the truth.
>
> So, again, my position is: Checking for an invalid state at runtime, and
> acting on it in a non-ignorable manner, is the absolute best thing one
> can do. Except when that error can be detected at runtime.
>
> Please stop arguing against your demons on this, and address my point.
> If an error can be detected at compile time, then it is a mistake to
> detect it at runtime. Please address this specific point, and stop
> general carping at the non-CP adherents. I'm not one of 'em.
>
>>> Depending
>>> on the vaguaries of its operating environment, it may well just keep
>>> going bad, in the same (hopefully very short) amount of time, again
>>> and
>>> again and again. The system's not being (further) corrupted, but it's
>>> not getting anything done either.
>>
>> One of the Mars landers went silent for a couple days. Turns out it
>> was a
>> self detected fault, which caused a reset, then the fault, then the
>> reset,
>> etc. This resetting did eventually allow JPL to wrest control of it
>> back. If
>> it had simply locked, oh well.
>
> Abso-bloody-lutely spot on behaviour. What: you think I'm arguing that
> the lander should have all its checking done at compile time (as if
> that's even possible) and eschew runtime checking.
>
> At no time have I ever said such a thing.
>
>> On airliners, the self detected faults trigger a dedicated circuit
>> that
>> disables the faulty computer and engages the backup. The last, last,
>> last
>> thing you want the autopilot on an airliner to do is execute a return
>> 0;
>> some programmer threw in to shut the compiler up. An exception thrown,
>> shutting down the autopilot, engaging the backup, and notifying the
>> pilot is
>> what you'd much rather happen.
>
> Same as above. Please address my thesis, not the more conveniently
> down-shootable one you seem to have addressing.
>
>>> It's clear, or seems to to me, that this issue, at least as far as
>>> the
>>> strictures of D is concerned, is a balance between the likelihoods
>>> of:
>>>     1.    producing a non-violating program, and
>>>     2.    preventing a violating program from continuing its
>>> execution
>>> and, therefore, potentially wreck a system.
>>
>> There's a very, very important additional point - that of not enticing
>> the
>> programmer into inserting "shut up" code to please the compiler that
>> winds
>> up masking a bug.
>
> Absolutely. But that is not, in and of itself, sufficient justification
> for ditching compile detection in favour of runtime detection. Yet
> again, we're having to swallow absolutism - dare I say dogma? - instead
> of coming up with a solution that handles all requirements to a healthy
> degree.
>
>>> You seem to be of the opinion that the current situation of missing
>>> return/case handling (MRCH) minimises the likelihood of 2. I agree
>>> that
>>> it does so.
>>>
>>> However, contrarily, I assert that D's MRCH minimises the likelihood
>>> of
>>> producing a non-violating program in the first place. The reasons are
>>> obvious, so I'll not go into them. (If anyone's cares to disagree, I
>>> ask
>>> you to write a non-trival C++ program in a hurry, disable *all*
>>> warnings, and go straight to production with it.)
>>>
>>> Walter, I think that you've hung D on the petard of 'absolutism in
>>> the
>>> name of simplicity', on this and other issues. For good reasons, you
>>> won't conscience warnings, or pragmas, or even switch/function
>>> decoarator keywords (e.g. "int allcases func(int i) { if i < 0
>>> return -1'; }"). Indeed, as I think most participants will
>>> acknowledge,
>>> there are good reasons for all the decisions made for D thus far. But
>>> there are also good reasons against most/all of those decisions.
>>> (Except
>>> for slices. Slices are *the best thing* ever, and coupled with
>>> auto+GC,
>>> will eventually stand D out from all other mainstream languages.<G>).
>>
>> Jan Knepper came up with the slicing idea. Sheer genius!
>
> Truly
>
>>> Software engineering hasn't yet found a perfect language. D is not
>>> perfect, and it'd be surprising to hear anyone here say that it is.
>>> That
>>> being the case, how can the policy of absolutism be deemed a sensible
>>> one?
>>
>> Now that you set yourself up, I can't resist knocking you down with
>> "My
>> position is simply that compile-time error detection is better than
>> runtime
>> error detection." :-)
>
> ?
>
> If you're trying to say that I've implied that compile-time detection
> can handle everything, leaving nothing to be done at runtime, you're
> either kidding, sly, or mental. I'm assuming kidding, from the smiley,
> but it's a bit disingenuous at this level of the debate, don't you
> think?
>
>>> It cannot be sanely argued that throwing on missing returns is a
>>> perfect
>>> solution, any more than it can be argued that compiler errors on
>>> missing
>>> returns is. That being the case, why has D made manifest in its
>>> definition the stance that one of these positions is indeed perfect?
>>
>> I don't believe it is perfect. I believe it is the best balance of
>> competing
>> factors.
>
> I know you do. We all know that you do. It's just that many disagree
> that it is. That's one of the problems.
>
>>> I know the many dark roads that await once the tight control on the
>>> language is loosened, but the real world's already here, batting on
>>> the
>>> door. I have an open mind, and willing fingers to all kinds of
>>> languages. I like D a lot, and I want it to succeed a *very great
>>> deal*.
>>> But I really cannot imagine recommending use of D to my clients with
>>> these flaws of absolutism. (My hopeful guess for the future is that
>>> other compiler variants will arise that will, at least, allow
>>> warnings
>>> to detect such things at compile time, which may alter the commercial
>>> landscape markedly; D is, after all, full of a great many wonderful
>>> things.)
>>
>> I have no problem at all with somebody making a "lint" for D that will
>> explore other ideas on checking for errors. One of the reasons the
>> front end
>> is open source is so that anyone can easily make such a tool.
>
> I'm not talking about lint. I confidently predict that the least badness
> that will happen will be the general use of non-standard compilers and
> the general un-use of DMD. But I realistically think that D'll splinter
> as a result of making the same kinds of mistakes, albeit for different
> reasons, as C++. :-(
>
>>> One last word: I recall a suggestion a year or so ago that would
>>> required the programmer to explicitly insert what is currently
>>> inserted
>>> implicitly. This would have the compiler report errors to me if I
>>> missed
>>> a return. It'd have the code throw errors to you if an unexpected
>>> code
>>> path occured. Other than screwing over people who prize typing one
>>> less
>>> line over robustness, what's the flaw? And yet it got no traction
>>> ....
>>
>> Essentially, that means requiring the programmer to insert:
>>    assert(0);
>>    return 0;
>
> That is not the suggested syntax, at least not to the best of my
> recollection.
>
>> It just seems that requiring some fixed boilerplate to be inserted
>> means
>> that the language should do that for you. After all, that's what
>> computers
>> are good at!
>
> LOL! Well, there's no arguing with you there, eh?
>
> You don't want the compiler to automate the bits I want. I don't want it
> to automate the bits you want. I suggest a way to resolve this, by
> requiring more of the programmer - fancy that! - and you discount that
> because it's something the compiler should do.
>
> Just in case anyone's missed the extreme illogic of that position, I'll
> reiterate.
>
>     Camp A want behaviour X to be done automatically by the compiler
>     Camp B want behaviour Y to be done automatically by the compiler. X
> and Y are incompatible, when done automatically.
>     By having Z done manually, X and Y are moot, and everything works
> well. (To the degree that D will, then, and only then, achieve resultant
> robustnesses undreamt of.)
>
>     Walter reckons that Z should be done automatically by the compiler.
> Matthew auto-defolicalises and goes to wibble his frimble in the back
> drim-drim with the other nimpins.
>
> Less insanely, I'm keen to hear if there's any on-point response to
> this?
>
>>> [My goodness! That was way longer than I wanted. I guess we'll still
>>> be
>>> arguing about this when the third edition of DPD's running hot
>>> through
>>> the presses ...]
>>
>> I don't expect we'll agree on this anytime soon.
>
> Agreed
>
>

On Fri, 4 Feb 2005 18:53:15 -0800, Walter wrote:

> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:cu15pb$jqf$1@digitaldaemon.com...
>> Guys, if we persist with the mechanism of no compile-time detection of return paths, and rely on the runtime exceptions, do we really think NASA would use D? Come on!
> 
> NASA uses C, C++, Ada and assembler for space hardware.
> 
> http://www.spacenewsfeed.co.uk/2004/11July2004_6.html http://vl.fmnet.info/safety/lang-survey.html
> 
> That said, you and I have different ideas on what constitutes support for writing reliable code. I think it's better to have mechanisms in the language that:
> 
> 1) make it impossible to ignore situations the programmer did not think of
> 
> 2) the bias is to force bugs to show themselves in an obvious manner
> 
> 3) not making it easy for the programmer to insert dead code to "shut up the compiler"
> 
> This is why the return and the switch defaults are the way they are.

Of course, this is all a moot point if you compile using the -release switch. In that case, one gets neither run time nor compile time messages, but the bugs still remain. So a really lazy/ignorant/impatient/stupid coder just always compiles using -release and never gets nagged by the compiler.

-- 
Derek
Melbourne, Australia
7/02/2005 10:36:21 AM

AOP is cool, I wish it was possible to use it in D.

On Sun, 6 Feb 2005 05:34:27 +0000 (UTC), Kris <Kris_member@pathlink.com> wrote:
> Here's a suggestion that /might/ help: are you, Walter, familiar with AOP at
> all? If so, you might consider treating such things as part of "cross-cutting
> concerns", where
>
> a) a "point-cut" is declared, by the programmer, to add code to those
> non-void-returning functions which don't actually end with a return statement.
>
> b) the code generated at the end of a function would thus be an "advice". One
> which has been explicitly provided by the programmer, rather than by the
> compiler.
>
> Here's a little blurb on AOP, via Google:
> http://www.onjava.com/pub/a/onjava/2004/01/14/aop.html
>
> - Kris
>
>
> In article <cu44i1$739$1@digitaldaemon.com>, Walter says...
>>
>>
>> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message
>> news:cu3v58$3c3$1@digitaldaemon.com...
>>> A maintenance engineer is stymied by *both*
>>> forms, and confused contrarily: the first looks like a bug but may not
>>> be, the second is a bug but doesn't look like it. The only form that
>>> stands up to maintenance is something along the lines of what Derek's
>>> talking about:
>>>
>>>     int foo(CollectionClass c, int y)
>>>     {
>>>         foreach (Value v; c)
>>>         {
>>>             if (v.x == y)
>>>                 return v.z;
>>>         }
>>>
>>>         throw logic_error("This function has encountered a situation
>>> which contradicts its design and/or the design of the software within
>>> which it resides");
>>>
>>>         return 0;
>>>     }
>>
>> From a C/C++ perspective, you're right, this is the only correct solution.
>> From a D perspective, however, I submit that the first example is not
>> confusing. There is no falling off the end in D functions, as an exception
>> would be thrown. The only returns that can happen are explicitly there with
>> return statements. The maintenance engineer will know this as surely as he
>> knows that after an assert(p) that p is not null. I agree this is a
>> different way of thinking about the code, that coming from a solid C/C++
>> background it might be a bit off-putting.
>>
>>> This is what I also do in such cases, and I believe (and have witnessed)
>>> it being a widely practiced technique.
>>
>> Yes, and I've written magazine articles and done lectures pushing exactly
>> that. It's what one has to do with C/C++.
>>
>>> You're
>>> keen to mould D with a view to catering for, or at least mitigating the
>>> actions of,  the lowest common denominators of the programming gene
>>> pool.
>>
>> I've seen this kind of error written by experts, not just the lowest common
>> denominator. If D cannot prevent an error, it should try to mitigate the
>> damage.
>>
>>> Yet you seem decidely uninterested in addressing the concerns of
>>> large scale and/or commercial and/or large-teams and/or long-lasting
>>> codebases. How can this attitude help D to prosper?
>>
>> I have to disagree with this. Many features of D are the result of many long
>> conversations with program development managers. They need positive
>> mechanisms in the language to prevent or at least mitigate the effects of
>> common, very human, programming mistakes. C and C++ are seriously deficient
>> in this area. That you disagree with the efficacy of one the solutions does
>> not at all mean I am uninterested. A very large part of D is providing
>> support for writing robust code.
>>
>>> Your measure adds an indeterminately timed exception fire, in the case
>>> that a programmer doesn't add a return 0. That's great, so far as it
>>> goes. But here's the fly in your soup: what's to stop them adding the
>>> return 0?
>>
>> Absolutely nothing. But as I wrote before, if he's looking at fixing the
>> code after the exception fired, he knows he's dealing with a bug that needs
>> fixing. In the case of the compiler error message, there is not necessarilly
>> a bug there, so the easy temptation is to throw in a return of some
>> arbitrary value. Is that bad programming technique? Absolutely. Does it
>> happen anyway? Yes, it does. I've been in code review meetings and listened
>> to the excuses for it. Those kinds of things are hard to pick up in a code
>> review, so removing the cause of it and trying to mitigate the damage is of
>> net benefit.
>>
>> Let's put it this way, here are the choices (numbers pulled out of dimension
>> X):
>>
>> 1) A bug catching feature that 90% of the time will cause the programmer to
>> write correct code, but 10% of the time will result in code that has an
>> insidious, nasty, hard to reproduce & find bug.
>>
>> 2) A bug catching feature that 70% of the time will cause the programmer to
>> write correct code, but the 30% that get it wrong results in code that when
>> it fails, fails cleanly, in an easy to reproduce, find and therefore fixable
>> manner.
>>
>> It's a judgement call, not dogma. I'd rather have (2), and I believe that
>> (2) is better for the long term success of a code base. I do not like (1), b
>> ecause the penalties of such bugs, even though they are less frequent, are
>> so severe they overshadows everything else.
>>
>>
>
>

Got my vote, on both counts.

Contracts 'on' by default and, perhaps more pressing, a means to retain the contracts whilst removing asserts, invariants, array-bounds, etc.

I don't suppose there will be any real agreement upon which of the latter are appropriate or not; hence it would seem prudent to expose a compound flag, controlling which of those tests should be on or off ... <sigh>

- Kris


In article <cu65vg$289g$1@digitaldaemon.com>, Matthew says...
>
>
>"sai" <sai_member@pathlink.com> wrote in message news:cu65me$27i4$1@digitaldaemon.com...
>> Anders_F_Bj=F6rklund?= says...
>>>Okay, so -release is "intuitive" and "self-explanatory" - but you'll have to read the docs to find out what it does ? Does not compute :-) I find "-debug -release" to be a rather weird combination of DFLAGS ?
>>
>> Yes, -release means ..... it is a release version with all contracts
>> (including
>> pre-conditions, invariants, post-conditions and assertions) etc etc
>> turned off,
>> quite self explainatory to me !!
>
>I think the original issue under debate, sadly largely ignored since, is whether contracts (empty clauses elided, of course), should be included in a 'default' release build. I'm inexorably moving over to the opinion that they should, and I was hoping for opinions from people, considering the long-term desire to turn D into a major player in systems engineering
>
>
>

On Mon, 7 Feb 2005 09:33:27 +1100, Matthew <admin@stlsoft.dot.dot.dot.dot.org> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message
> news:opslsqnpdr23k2f5@ally...
>> On Sat, 5 Feb 2005 17:46:37 -0800, Walter <newshound@digitalmars.com>
>> wrote:
>>> What you're advocating sounds very much like how compile time
>>> warnings  work
>>> in typical C/C++ compilers. Is this what you mean?
>>
>> <snip>
>>
>> To me, there seems to be one important difference between this
>> proposition  and the current compile time warnings of a c/c++
>> compiler.
>>
>> That difference is that the D compiler is going to do something about
>> it,  eg.
>>
>> switch(a) {
>> case 1:
>> case 2:
>> }
>>
>> a C compiler might say, "Warning: no default case". The D compiler is
>> going to add a default case which throws an exception if triggered,
>> now,  can't it also issue a notification of what it has done eg.
>> "Note: default  case added".
>>
>>
>> To me, this behaviour cannot be called a 'warning' but either the
>> literal  definition of the word:
>>   http://dictionary.reference.com/search?q=warning
>> or by the behaviour we are all used to.
>>
>>
>> According to the web pages, the reason for removing warnings..
>>
>> "No Warnings
>>
>> D compilers will not generate warnings for questionable code. Code
>> will  either be acceptable to the compiler or it will not be. This
>> will  eliminate any debate about which warnings are valid errors and
>> which are  not, and any debate about what to do with them. The need
>> for compiler  warnings is symptomatic of poor language design."
>>
>> This new imagined behaviour does not violate the above paragraph.
>>
>>
>> As mentioned previously this new behaviour allows you to catch the bug
>> in  the compile phase and before the testing phase.
>>
>> Regan
>
> Sounds like a pretty excellent compromise to me!!

It did to me too, however after more thought it appears more complex, see my later post dated:

Mon, 07 Feb 2005 12:21:58 +1300

in this same thread for my later ramblings.

Regan

Ben Hinkle wrote:
>>14) list classes with high cyclomatic complexity measurements
> 
> 
> Interesting idea but it could be hard to compute and hard to know what to do about it. Can you see a code analysis program saying something like "Your code is too complicated. Make it simpler."
> Or are you hinting at a dangerous problem involving cyclic references?

I was just thinking about a list of classes sorted by their complexity,
showing potential directions of high-level refactoring.

>>15) list classes with getters/setters only
> 
> 
> why is this one a problem?

It's not.  I don't know why I wrote it down :p

>>16) rant on use of uninstantiated objects
> 
> 
> I like it - a lint with attitude. For those C++ programmers who don't read the documenation carefully enough.
> 
> 
>>17) highlight ill-named identifiers
> 
> 
> Style-guides would be nice - as long as they are very customizable and optional!
> 
> 
>>...
>>wait a sec.  is there anyone passionate enough to launch the dlint project?
> 
> 
> If it's still not done by the time MinWin gets settled (still many months) then I will definitely give it a shot. I could use a dlint ASAP. 
>

I suppose MinWin is more anticipated by the D community.
Keep up the good work :)

"Derek Parnell" <derek@psych.ward> wrote in message news:cu69r8$2gqi$1@digitaldaemon.com...
> On Fri, 4 Feb 2005 18:53:15 -0800, Walter wrote:
>
>> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:cu15pb$jqf$1@digitaldaemon.com...
>>> Guys, if we persist with the mechanism of no compile-time detection
>>> of
>>> return paths, and rely on the runtime exceptions, do we really think
>>> NASA would use D? Come on!
>>
>> NASA uses C, C++, Ada and assembler for space hardware.
>>
>> http://www.spacenewsfeed.co.uk/2004/11July2004_6.html http://vl.fmnet.info/safety/lang-survey.html
>>
>> That said, you and I have different ideas on what constitutes support
>> for
>> writing reliable code. I think it's better to have mechanisms in the
>> language that:
>>
>> 1) make it impossible to ignore situations the programmer did not think of
>>
>> 2) the bias is to force bugs to show themselves in an obvious manner
>>
>> 3) not making it easy for the programmer to insert dead code to "shut
>> up the
>> compiler"
>>
>> This is why the return and the switch defaults are the way they are.
>
> Of course, this is all a moot point if you compile using the -release
> switch. In that case, one gets neither run time nor compile time
> messages,
> but the bugs still remain. So a really lazy/ignorant/impatient/stupid
> coder
> just always compiles using -release and never gets nagged by the
> compiler.

Shit! Is that so? I hadn't cottoned on to that. If that is indeed the case, then this whole thing is just a joke.

Wake me up when things get sane again.