"Walter Bright" <newshound@digitalmars.com> wrote in message news:dsancf$2k92$1@digitaldaemon.com...
>
> "Matthew" <matthew@hat.stlsoft.dot.org> wrote in message news:ds9tq1$1r8n$1@digitaldaemon.com...
> > I'd love to be able to poo-poo your statements as laughable fantasy, but
I
> > have no doubt that you believe what you're saying and that you're
speaking
> > the truth about your own experiences. What continues to sadden me is the apparent narrow-mindedness in that you project a certain belief that
your
> > experiences are enough of a sample to make pronouncements and direct
tool
> > strategy for everyone else.
> >
> > I can tell you that there are plenty of times when a binary approach
such
> > as
> > you describe has not proved enough for me, perhaps as a consequence of
my
> > working with non-trivial C++ code (templates, etc.). There are often
> > instances where a combinatorial effect on the compiler cannot be reduced
> > in
> > the manner you describe, and many more where the effort involved to
bring
> > everything in one file is far more than necessary compared with
modifying
> > several in parallel.
> > I know you don't believe me about that, but that
> > doesn't make it not so.
>
> I know that you find this to not work, and you've often sent me those
cases.
> None of them resisted reduction to a few lines.

More assumption: that I've needed to consult you on all the cases that I've found, and that I've done so in all cases. Neither of these is true.

> I've been working on solving template related bugs for 10 years :-(. At
the
> end of the process, each and every one of the minimal examples goes into
the
> DMC++ test suite, so I have quite an extensive test suite (maybe a
thousand
> examples just for templates). Every one was reduced using the process I described, and they are all just a few lines of code.

None of that has the slightest relation to my point.

> And, as a pretty general rule, none of the problems made any sense until they were so reduced, and they often did start out as incomprehensibly complex templates.
>
> There is a very solid factual basis for what I said works in isolating problems. The proof is not only in the DMC++ (and DMD) test suite, but in the irreducible cases you sent me that I reduced and sent back. If you
want
> to dismiss such a successful track record, including success on your
cases,
> as laughable fantasy, what can I say?

Another furphy again. I don't poo-poo your track record. I point out that your software engineering is not monotonic, corresponding to only your experiences/opinions/practices, and that this detracts from D's general appeal and raises several manifest contradictions with your stated aims for D.

Seems that several others are pointing that out now, so I'll leave it before it degenerates any further.

"Walter Bright" <newshound@digitalmars.com> wrote in message news:dsaljv$2ikm$1@digitaldaemon.com...
>
> "Matthew" <matthew@hat.stlsoft.dot.org> wrote in message news:dsabfk$282a$1@digitaldaemon.com...
>
> >>Walter wrote:
> >>> Your point sounded like you were
> >>>worried about introducing bugs during chop-and-test. I recommended
> >>> making a copy first, then no bugs can be introduced.
> > It ignores the clear and very important issue that one might want to
> > continue to have warnings emitted, in order to keep the "mental picture"
> > of
> > the compilation output consistent, in order to ensure that any changes
to
> > try and stop the compiler from its ICEs, e.g. reordering seemingly
> > unrelated
> > statements, have not done anything that's a _new_ problem, in order to
see
> > if a commented out block highlights a new warning, and so on and so
forth.
>
> So I summed up your point accurately.
>
> > Of course, Walter can counter that each and every change should be
atomic,
>
> Nope. The only goal with the chop is "does the problem I am trying to isolate remain, or does it go away?" It's binary, yes or no. If you're introducing all kinds of other considerations, that's likely why you find chop-and-test to be so unusably arduous.
>
> > but it's not living in the real world, or at least not in my real world.
I
> > want to work how I work best, not how Walter works best.
>
> You often send me very large bug reports with a comment that you've been unable to chop it down further and that you've no idea what's going wrong. Every one of them I've reduced, using chop-and-test, to 10 lines or so
after
> a few minutes. None of them hinged on -w in any way or required more than
2
> of copies of any file. Your way isn't working (in the sense that it isn't finding the cause of the problem), why is it best?
>
> This would be probably helped a lot if I could look over your shoulder
while
> you're doing chop-and-test, so I could show you how to do it.

Good one.

At junior debating college they taught us that when your opponent starts to play the man not the ball you know you have him on the ropes.

Walter Bright wrote:
> "Bruno Medeiros" <daiphoenixNO@SPAMlycos.com> wrote in message news:dsaijo$2f0r$1@digitaldaemon.com...
>> One can say: oh but then you can disable warnings-as-errors when you're doing the test chop runs, and enable it when your doing 'non-chop' development. But that is plain idiotic. I'm not going to change my build config files every time I wanna change from on mode to another.
>> In fact, since different parts can be under work by different people, this idea is just not considerable.
> 
> Chop-and-test is not normal development. It is done with a local copy of the project, including the makefiles, not code that you or other people are working on.
> 
> The whole technique of chop-and-copy implies being able to hack and slash away at the project source with abandon. You don't worry about breaking the build, warnings, introducing bugs, or screwing up someone else's part. This is all possible because one is working with a local copy that will be deleted as soon as the problem is found and a solution identified. The solution is then folded into the real development branch. 
> 
> 

I think I might have misused the term chop-and-test. I meant any kind of test run (or runs) where you removed some part of the code, either by cutting or commenting. Your definition implies a destructive and more abragent version of this, which indeed, musn't happen often.

So I correct my previous statements: by chop-and-test I meant not really the proper chop-and-test, but rather one or more of any kind of *temporary short-lived* editing of the code, with the intention of running/testing the program afterwards. This editing will probably have the life span of only the most immediate task the programmer is doing. This situation, does occur often and is part of normal development.

And -w annoys the hell out of it.

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

On Wed, 8 Feb 2006 22:16:24 +1100, Matthew <matthew@hat.stlsoft.dot.org> wrote:
> "Walter Bright" <newshound@digitalmars.com> wrote in message
> news:dsaljv$2ikm$1@digitaldaemon.com...
>>
>> "Matthew" <matthew@hat.stlsoft.dot.org> wrote in message
>> news:dsabfk$282a$1@digitaldaemon.com...
>>
>> >>Walter wrote:
>> >>> Your point sounded like you were
>> >>>worried about introducing bugs during chop-and-test. I recommended
>> >>> making a copy first, then no bugs can be introduced.
>> > It ignores the clear and very important issue that one might want to
>> > continue to have warnings emitted, in order to keep the "mental  
>> picture"
>> > of
>> > the compilation output consistent, in order to ensure that any changes
> to
>> > try and stop the compiler from its ICEs, e.g. reordering seemingly
>> > unrelated
>> > statements, have not done anything that's a _new_ problem, in order to
> see
>> > if a commented out block highlights a new warning, and so on and so
> forth.
>>
>> So I summed up your point accurately.
>>
>> > Of course, Walter can counter that each and every change should be
> atomic,
>>
>> Nope. The only goal with the chop is "does the problem I am trying to
>> isolate remain, or does it go away?" It's binary, yes or no. If you're
>> introducing all kinds of other considerations, that's likely why you find
>> chop-and-test to be so unusably arduous.
>>
>> > but it's not living in the real world, or at least not in my real  
>> world.
> I
>> > want to work how I work best, not how Walter works best.
>>
>> You often send me very large bug reports with a comment that you've been
>> unable to chop it down further and that you've no idea what's going wrong.
>> Every one of them I've reduced, using chop-and-test, to 10 lines or so
> after
>> a few minutes. None of them hinged on -w in any way or required more than
> 2
>> of copies of any file. Your way isn't working (in the sense that it isn't
>> finding the cause of the problem), why is it best?
>>
>> This would be probably helped a lot if I could look over your shoulder
> while
>> you're doing chop-and-test, so I could show you how to do it.
>
> Good one.
>
> At junior debating college they taught us that when your opponent starts to
> play the man not the ball you know you have him on the ropes.

It is called "Attacking the person":
http://www.datanation.com/fallacies/attack.htm

But I don't agree that Walter is guilty of it here.

Regan

Bruno Medeiros wrote:
> Your definition implies a destructive and more abragent version of this, which indeed, musn't happen often.

Sorry, "abrangent" doesn't exist in english. I forgot to fix it before posting. "abrangent" means something like "encompassing", "far-reaching", "wide", etc. .

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

"Bob W" <nospam@aol.com> wrote in message news:dsb8qr$5r8$1@digitaldaemon.com...
> 1) Let us - just theoreticaly - assume that at one stage
> you want to disallow the optional C-like syntax of declaring
> arrays. If such a major move is going to happen in the not
> so near future you would be well advised to introduce
> warnings in several compiler releases instead of moving
> radically and forcing even newbies to search for an
> "allow deprecated features" switch to get their job done.

D has already done this a couple times in the past. It'll issue an error about a "deprecated" feature, suggesting the corrected approach. The -d will allow it to continue to compile (I'm not sure why -d would be hard to find for newbies, dmd doesn't have many switches). After a while, it becomes a hard error that can't be overridden with -d, though the fix is still suggested. Eventually, even that is removed and it's just invalid syntax. I think this approach has worked well as long as plenty of time accompanies each stage; at least nobody has complained about it <g>.