Re: Letter to US Sen. Byron Dorgan re unpaid overtime

From: Edward G. Nilges (spinoza1111_at_yahoo.com)
Date: 12/23/03 

Date: 22 Dec 2003 19:15:46 -0800

Richard Heathfield <dontmail@address.co.uk.invalid> wrote in message news:<bs7m88$le5$1@titan.btinternet.com>...
> [Lots of snips, because this is getting silly]
>
> Edward G. Nilges wrote:
>
> > Richard Heathfield <dontmail@address.co.uk.invalid> wrote in message
> > news:<bs5f83$53q$1@hercules.btinternet.com>...
> >> >
> >> >> If you don't like C, don't use it. But
> >> >> to try to impose your likes and dislikes on others is an exercise
> >> >> doomed to failure.
> >> >>
> >> > It appears to me that this is what you do, the only difference happen
> >> > to be that your opinions coincide with those of the tribe.
> >>
> >> Well, I'm a great believer in personal choice. I don't believe in
> >> imposing /any/ language on /anyone/. C happens to be /my/ language of
> >> choice. That doesn't mean it's right for everybody.
> >
> > A computer language is not a lifestyle, and the very idea of
> > transferable expertise seems to be beyond you.
>
> Well, how things seem to you is very different from how things are in
> actuality. Here in the Real World, we use common sense a lot more than on
> Planet Nilges.
>
> > Instead, you judge
> > people by fabricated metrics which inappropriately foreground
> > transient issues, like a poor head-hunter.
>
> No, I just find it hard to believe anyone could be so stupid as not to cache
> processor-intensive calls.

Yeah, while letting the system as a whole go to hell. I don't think
you know how minimal the cacheing under consideration would be in
effect.

>
> > Richard, I was frankly shocked to learn that you are unclear on the
> > very idea of a runtime instruction that would scan a string for a Nul
> > character,
>
> Oh, I'm not unclear about it AT ALL. I have posted results elsethread that
> show quite conclusively that you're talking through your nose (for the
> benefit of anyone still naive enough to think you have the slightest idea
> what you're talking about).
>
The results are always posted somewhere else, aren't they, because you
are not in this conversation to conduct a dialog. Instead you are
playing to a sort of peanut gallery.

> >> > Also, this is an ugly piece of code. It increments the line counter
> >> > unnecessarily since rc is set to a value, then thisline is incremented
> >> > (for some strange reason, in a nonstandard fashion, in a
> >> > preincrement), then the condition is evaluated.
> >>
> >> The line count increment is necessary because the value is used as an
> >> offset into the array. The preincrement is not non-standard at all. The
> >> Standard defines the behaviour perfectly. The condition is evaluated
> >> before each loop iteration, not after. You really don't understand this
> >> language at all, do you?
> >
> > Not true. The increment is NOT performed before each loop iteration in
> > the code
>
> Hey, idiot, read my lips - the CONDITION is evaluated before each loop
> iteration. That's what I said. And this is why I said it: YOU (wrongly)
> said: "then thisline is incremented (for some strange reason, in a
> nonstandard fashion, in a preincrement), then the condition is evaluated."
> That's absolute twaddle, and I was correcting it. Sheesh, man, get a clue!
>
I did not say that the condition is evaluated after the increment,
since I started with the assignment to the rc, in the middle, and then
narrated what happens. I know the sequence of evaluations, but in
trying to give the false impression that I don't to add to your absurd
charge ***, you gave the impression you don't.

That's because you've entered this dialog dishonestly and as a bully.
Your bad attitude causes misunderstanding at warp speed, and, it is an
example of what I was talking about when I pointed out that
programmers can no longer conduct effective walkthroughs.

I am relieved that we both know the order of evaluation in a for
statement: initialize, test, increment, back to test. You gave me the
transient impression that you did not because you communicate only to
maintain a dominant position.

And you took your incorrect reading as final while I repeatedly
expressed my hope that you actually know the sequence of evaluations
in a for loop. I suggest you learn some basic courtesy (hint: it has
NOTHING to do with counting "swear-words", *** wad, and EVERYTHING to
do with deep semantics and that understanding, *** wad, that comes
with reserving judgement UNTIL you fully understand what was said.
 
> >
> > for (intIndex1 = 0; intIndex1 < strlen(strInstring); ++intIndex) { ...
> > }
> >
> > and I REALLY hope you know that the iteration is performed AFTER the
> > iteration.
>
> Typical Nilges - the iteration is performed after the iteration, is it?
> Well, that's just wonderful. Here on Earth, we prefer common sense.

No, just a typo. I don't want to waste too much time with you, and
your bullying upsets me, so I make errors. Stop the insanity and there
will be fewer typos...on both sides.

>
> > I really hope you know that the C compiler will generate code to (1)
> > increment intIndex and (2) throw it away and that this code will
> > physically be after, and be executed after, the code in the curly
> > braces.
>
> The value is not thrown away; and the fact that you believe otherwise is
> symptomatic of your ignorance.
>
"It" refers to the stacked value. The incremented value remains, of
course.
 
> > If intIndex were somehow evaluated in the step condition,
>
> step condition? What are you talking about now? There's no such thing as a
> "step condition"!

The step, then.

>
> > the
> > incremented value would be used. If I replaced ++intIndex in debugging
> > with a command to print intIndex such as printf( "d10\n", ++intIndex)
> > I would see the value after the increment, and this is why it was poor
> > practice to preincrement and not postincrement.
>
> Don't be so silly.
>
> (a) Learn to use a debugger.
> (b) Even if you must use debugging printf, that's a stupid place to put one.
> (c) Even if it were a sensible place to put one (which it isn't), it
> wouldn't work - all it would print is "d10\n"
>
I see, when you type in code you can make errors, but I can't. Of
course, C requires some silly symbol in front of d.

You are playing games because you had dominated this ng
inappropriately with commercial promotion of the C language when I
posted the popular thread on Steve McConnell's book. You are
determined to drive me away which is common practice in ngs because
programming culture has been disempowered and tribalized. But you are
reduced to equating typos and arguable issues of style with science
and this makes you look like a nasty clerk.

> > I'm not an expert in C
>
> Correct. At last, a correct statement from Edward G Nilges.
>
> > although I play one in the movies. But in
> > charity I think you are getting so upset that you are making errors.
>
> No, I'm not upset at all, and I'm not the one making the errors.
>
> >> if(rc != SUCCESS)
> >> {
> >> /* no adjustment required */
> >> fprintf(stderr, "Error on line %lu\n", (unsigned long)thisline);
> >> }
> >>
> >>
> > Untrue. At the point of early exit on fail, the index in thisline will
> > still contain a zero based value because ++thisline doesn't have the
> > effect you seem to think it does.
>
> Nonsense. Here's proof:
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <time.h>
>
> int main(void)
> {
> int i;
> int rc = 0;
> srand(time(0));
> for(i = 0; rc == 0 && i < 100; i++)
> {
> printf("In Loop: %d\n", i);
> /* simulate error */
> rc = (rand() % 11 == 0) ? 1 : 0;
> }
> printf("Out of loop: %d\n", i);
> return 0;
> }
>

This code will produce a one based index properly. It goes through a
contortion to work because you're not man enough :-) to do the right
thing and put a break where it belongs.

The contortion is that you set a return code to show what is a break
condition, and then wait to wrap around to the fetishized and reified
termination condition, where in your urban legend sodden brain, the
ONLY exit is permitted.

A prohibition ("a loop must have only one exit"), an urban legend,
replaces science in a dialectic of enlightenment, and this causes you
to create YET ANOTHER ugly "temp" variable, rc. Each one of these busy
little sods create a possible point of failure but this is no
nevermind to you: you've obeyed a rule.

Why not just break and in the report, Code What You Mean by explicitly
incrementing the variable?

for ( intIndex1 = 0; intIndex1 < strlen(strInstring); intIndex1++ )
    if ( rand() % 11 == 0 ) break;
printf( "At character %d of &d\n", intIndex+1, strlen(strInstring) );

Cudgel thy brains over this code:

(1) It uses Hungarian notation because Hungarian notation makes it
more readable. End of story.

(2) The use of strlen is only micro-inefficient EVEN IF the compiler
does not optimize the strlen to a single machine language instruction,
and this is because if the application is properly designed, most
strings will be in the range 1...1000 characters. The developer will
be MORE concerned with ensuring that long strings are not passed in
the first place because of the global resource consumption.

For example, and in a compiler, the developer with a vision larger
than a few lines of code, will know that the above code SHOULD NOT BE
USED, and should not start at 0, when strInstring is the complete
source program. Instead he will get the start index from a parameter,
and, it will probably be the end index of the previous token or
element.

(3) The use of strlen follows Kernighan's rule in The Elements of
Programming Style: code what you mean. If your C compiler generates a
linear search for the end of the string, get an optimizing compiler or
abandon C.

(4) Last but not least, the break visually makes it plain that the
loop anticipates an early exit condition. Your code hides this fact.

> >> > Here is better and cleaner code.
> >>
> >> Not better, not cleaner.
> >>
> >> > for (intLineIndex = 0; intLineIndex < intLineCount; intLineIndex++)
> >> > if (processLine(strLine[intLineIndex]) != SUCCESS) break;
> >>
> >> 1) Clumsy variable name choice. intLineIndex needs to be of type size_t,
> >> obviously, so the int prefix is a misnomer.
> >>
> > Yeah, you have a Thing about size_t. Not sure why this is so.
>
> Yes, I have this thing about correctness. Obviously that isn't something
> you're overly concerned with.
>
> > I
> > thought you as a C expert might have info I don't, but above it seems
> > you believe that if in a step clause of a for loop, one places the ++
> > before the variable, the variable is incremented before the loop body.
>
> No, that's just your inability to read, shining through in the usual way.
>
> > Gee, maybe that is actually the case.
>
> No, it isn't. Stop making stuff up.
>
> > The C community since I stopped
> > using the language may have suffered an influx of nut bags. But in
> > charity I think you blew a brain fart on that one.
>
> No, you just can't read properly.
>
> >> > Your expectation is malformed by overexposure to C.
> >>
> >> My expectation was actually based on the normally sound basis that if Mr
> >> Nilges says it, it's probably wrong. That rule of thumb simply broke down
> >> on this occasion. I use Basic so little nowadays that I cannot consider
> >> myself to be an expert therein, which is why I don't say much about it in
> >> this newsgroup.
> >>
> > No, you think I am wrong because your feelings were hurt when I
> > entered the ng in Dec 2000, and created a popular thread on Steve
> > McConnell's book "After the Gold Rush".
>
> Don't be so stupid. I tend to start with the assumption that you are wrong
> for the simple reason that, as assumptions go, it works so very, very well.
> That it breaks down occasionally is no reason to discard it as a rule of
> thumb.
>
 
> > Since then you have conducted
> > a rather vindictive campaign and now we seem to be at the stage of
> > exposing what I fear are your limitations.
>
> Yes, I limit myself to correct programming (as far as I am able), whereas
> you clearly do not consider yourself bound by that limitation. Any old crap
> will do, eh?
>
> >> >> I do not believe that you are capable of writing a conforming C
> >> >> compiler. Please provide evidence that you have done so, if you wish
> >> >> to be persuasive.
> >> >>
> >> > I've clarified this. I wrote a subset compiler for business rules that
> >> > doesn't support typedef.
> >>
> >> I don't believe that, either. Do you have any supporting evidence for
> >> this assertion?
>
> I'll take that as a "no".
>
> > Well, big man, I am very good at programming,
>
> But you have proven this not to be the case, over and over again.
>
> <irrelevant stuff snipped>
>
> > I really think you don't believe that in
> >
> > for ( ...; ...; ++i )
> >
> > i is incremented before the body of the loop starts up.
>
> No, of course I don't. You really must learn to read.
>
I am relieved to hear it. I might pay more attention if you had some
social skills.
>
> < C# program snipped as being utterly irrelevant to this discussion>
>
> > But you may be unclear on what the compiler does.
>
> No, I'm perfectly clear on what the compiler does, thank you.
>
> >> >> > I am completely not
> >> >> > interested in your continued sniping since when I need the knowledge
> >> >> > I go to the book.
> >> >>
> >> >> THEN WHY DIDN'T YOU?
> >> >>
> >> > Because you are not worth the time.
> >>
> >> And that's why you write bad code? Because I'm not worth the time?
> >> Sheesh, your manager must love you to bits.
> >
> > Employability may be your concern. It isn't mine.
>
> Neither is logic, obviously. You seem utterly impervious to it.
>
> > It is true that if bad praxis and misunderstanding is normed, I can
> > look "bad" to the uninformed.
>
> And, indeed, to the informed. Trust me on this.

Why should I? You know the outdated language C but are deficient in
social skills. This means I can't trust you.

I am relieved that you know the order of evaluation in a for
statement. However, you don't see that the for statement hides an
important fact, and this is that it evaluates variables "by reference"
each time through. It cannot be optimized to put the limit in a fast
register and this "feature" belongs in a distinct statement.

The for statement is in fact an ugly mishmash of a by-reference while
and a Fortran Do loop and you don't see this because you are too busy
playing wannabe alpha male games on newsgroups and writing "efficient"
code that doesn't see the forest for the trees.

You are, in public, failing Job One of the effective programmer and
that is to disambiguate his knowledge from the details of a
programming language.