Re: Brian Kernighan, maybe I'm not worthy, maybe I'm scum

On Mon, 31 Dec 2007 05:11:23 -0600, spinoza1111 wrote
(in article
<7dc877ca-3229-4efd-a874-42d8af0bfc8a@xxxxxxxxxxxxxxxxxxxxxxxxxxx>):

On Dec 31, 5:56 pm, Randy Howard <randyhow...@xxxxxxxxxxxxxxxxx>
wrote:
On Mon, 31 Dec 2007 01:56:48 -0600, spinoza1111 wrote
(in article
<25fd92c7-0454-4489-9bbe-883533d2a...@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>):

Oh yes, the performance comparision. I wasn't addressing performance.

No, you assumed, and admitted so, that the compiler would address it
all for you. That is but one aspect of the "code" in question, but one
for which we at least managed to focus on technical realities, and not
subjective opinion, like the other debates over hungarian variable
naming, which you seem to have abandoned somewhat in your recent
posting here.

No, I make no such assumption,

You did, and you said so at the time. You may realize your error now
and not be willing to admit it, but reading below it seems that you are
still misled about this one.

Bite me.

Is this an example of the collegial discourse you recommended earlier?
If so, I would have to descend uncomfortably far to meet it with you,
so I decline.

but because I'm not a Computer Thug,

But by your own definition provided upthread it certainly appears that
you are...

No, I'm not. I don't sit behind a terminal and respond to the good-
faith posting of code for comments and correction by a global trashing
of a person based on ignorance. This is what you do, and you are a
Computer Thug.

Your posts here, even your most recent ones, make completely false
claims, which definitely appear to be based on ignorance. Such as C
being a part of C++. Or code written in C should compile and run
without effort in C++ .NET. If you could come up with some reason
/other/ than ignorance to explain why you make such ridiculous claims,
I'd like to hear them. But by the definition you use above, or your
earlier one, you meet the description to a T.

I don't think you're an experienced programmer.

And vice versa.

Not in your little shop. I don't have experience in running people
down and running my mouth, always "proving" that I'm such a Big Man by
always "proving" that your foil is a homo and a girlieman. If this is
what experienced programmers do, I'm not an experienced programmer.

I leave this intact only as a reminder to others of what you think
passes for sane, on-topic discourse, while encouraging others to speak
to each other collegially.

I think you programmed for a living.

You are entitled to your opinion, just as anyone else.

Screw you.

Ditto.


You seem angry. Earlier, you claims that I was the angry one, that I
lost it when talking to you, but I think we can all see the truth here
now, whether you admit it or not.

But your behavior in this thread
indicates that your mission in life is making sure that Everyone Loves
Randy, the Computer Thug.

We will have to add "inability to arrive at accurate conclusions" to
the list of things that describe you.

I don't care if you love me, or anyone here loves me. It's not even
remotely important that you or they do so. So stop playing shrink,
you're really pathetically bad it. To my knowledge, none of the
hundreds of your pseudo-shrink claims have been even remotely accurate,
with a far worse batting average than if you were to simply attempt to
draw a correct assessment out of a very small hat.

You lack of self-knowledge is not my concern.

More apparently, your lack of knowledge about me in any tangible form
doesn't seem to concern you at all either, yet you make armchair
assessments of my mental condition. Looking above, I'm not concerned
about who looks most in need of mental help here, but you probably
should be.

I'm telling you, from
the outside, how you come over here to me, and probably to a lot of
sensitive lurkers: as Yet Another Coding Loudmouth.

Fair enough. I'm telling you, how you come over to me:

A loudmouth that can't even be called a coder with a straight face.

I make no claims as to how you might appear to others, lurkers or
otherwise.

Programming is about something else.

It might certainly be true that programming is about other things to a
degree, but the thing you seem to have lost, is that it is about
programming too. To a great degree. Since you seem to have some areas
of difficulty regarding that, particularly with respect to C, and
apparently with C++ as well, you might want to focus on that when
you're done worrying about the off-hours sexual proclivities of people
you've never met.

to wit:
putting yourself in the
customer's shoes by stuying his culture as opposed to getting rolled
by Wanchai bar girls (which is probably your favorite thing to do here
in HK, Computer Thugs needing their play time)

I suspect this tells us way more about you than it ever will about me,
but that would be unsupportable at the present time.

In fact, comp.programming needs healthy threads on why it sucks to be
an American programmer, why programming jobs no longer carry health
insurance, why the mortgage securities meltdown is caused by lack of
audit trails or the time to program them, why Kernighan never spoke
out against Lucent's abuse of its engineers (to my knowledge), and why
programming shops are dominated by ignorant loudmouths such as
yourself.

You have certainly attempted to strike up discussions on many of these
topics in the past. You have had a few nibbles on the troll line to be
sure, but there does not seem to be a lot of general agreement. I
suspect that there might be more of it than you have experienced, if
your prose wasn't so littered with random synaptic firings. You don't
seem to be able to control that though, so I can see why you have been
frustrated at the attempts to steer discussions in these directions.

YOU CAN'T STAND IT.

I clearly can, because I have, and continue to do so. If I couldn't, I
would have killfiled you or unsubscribed long ago. What you can't
stand, is you don't succeed in your attempts to force thers into not
pointing out the flaws in your unsupportable claims by slinging a fire
hose of words at them, which to an outside observer would likely appear
to be randomly selected in many cases.

You can't stand the fact that I know more about REAL programming and
REAL computer science,

I don't need to be able to stand "facts" that not only have not been
demonstrated, but ones for which numerous proofs of their fallacy have
been provided.

Ah, so it has been around for more like 30+ years. I accept the
correction.

I worked in graduate school.

You think that makes you special? You think that has a bearing on my
accepting your claim that 25 years was an insufficiently long term for
the use of "hoist" in the CS field? Pray tell how it does. On second
thought, don't. Just be happy that you were able to find something
about which someone else could agree with you for a change.

Well, for starters, you mistakenly called me a liar merely because I
was in graduate school while working 12 hours a day at Baxter-Travenol
in 1976.

How could I have? I said nothing about your work hours, or 1976, or
Baxter-Travenol at all That would have been exceedingly difficult,
since I didn't know them until right now. If you mentioned them 4
years ago, I have forgotten them, because no matter what you think the
above means, it can't possibly have any bearing on me saying that I
agree with your claim that the time period was 30 years or more,
instead of the 25 I mentioned previously.

What did I lie about? FFS, I /agreed/ with you, and you want an
apology? Other than being comical, what purpose does this serve?

then the same logic applies to a non-optimizing compiler, or an
assembler, or to a bootstrap loader.

It certainly does. However, we were discussing that you want to rely
on the optimizer to do something for you, which empirical testing with
a wide variety of platforms and compilers has shown simply does not
happen, regardless of optimizer settings. You are free to provide an
example of a C compiler that /will/ do these things, if you know of
one, and a test fixture to verify it if you like.

I don't have to do that. I've proved the possibility. If the variables
used in the for header computation aren't assigned or passed by
reference, they can in nearly all cases be automatically moved out of
the loop.

No, they can't. Because the primary issue here is a function call, and
the compiler doesn't have the free pass to /assume/ that the function
call won't return different values, or modify external state in some
fashion on each iteration of the loop. That's the bubaboo here from
the compiler's side of things. From your side, calling strlen() n
times inside of a loop, particularly for anything other than trivially
short strings is a real bonehead move. And sadly, not one that the
compiler can generically repair for you.

No compiler optimization procedure can guarantee 100% correctness.
This is a risk shared by all possible code. The point being that most
managers would rather not hire loudmouths who want to do all the
optimization by hand, while bullying their mates.

Nobody has recommended doing all optimization by hand to my knowledge.
If you saw someone recommend that, provide a link the article, because
I missed it.

They'd rather hire
quiet, intelligent people who turn on the optimizer after testing the
code and then making sure the same results are attained by a test
suite which those quiet, intelligent people have built, not under
orders, but because they know their trade.

Since you have expressed anger in the past that you had a hard time
obtaining and maintaining employment as a programmer, ostensibly
because the because the evil American culture was out to get you, I
suspect you must have some other data that allows you to know what sort
of person people would "rather hire", outside of your own experience.

Even the existence of a single compiler that does do it for you won't
make it a good idea, it merely extends hope that someday you might be
able to do so if other compilers adopt it, and a future C standard
might codify at as defined behavior. More importantly though, you

Compiler behavior in optimization simply has no place in a language
standard,

You misunderstood again. I was not asking specifically for
documentation on what the compiler optimizer would do for you, but for
what some new language extension would provide to enable this
alternate, non-current-C behavior of a code inside a for loop that you
long for would provide.

and even having to narrate what the compiler "must" do in a
standard means that the language bites the big one.

Taken as it stands, are you sure you wish to make that claim? Are you
suggesting that a language standard should not provide any guarantees
on what expected behavior are for a given syntax construct? Really?

Oh for Christ's sake.

for (i = 0; i <size*expansion; i++) doFoobar;

is equivalent to

int limit = size*expansion;
for (i = 0; i < limit; i++) doFoobar;

UNLESS size and expansion aren't local and are global, something the
compiler knows.

As previously discussed, the above is NOT the code that his been
discussed here on and off for 4 years now. You know this very well,
this is nothing but a deliberate attempt to mislead people, but it
isn't working, because you see, you don't have a magic eraser that
makes your old posts disappear where you can lie about what really
happened later and nobody can prove otherwise. The strawman above is
new as of the last few hours. That might be very convenient for you to
be able to pretend otherwise using this magic eraser, but to date you
have not shown you have this technology available to you.

You'll have to learn how to program as I learned how to program my
first machine,

Based on your posting here to date, I see zero reason why I would want
to mimic anything you have done in your "learning".

I agree it's too late and that you should retrain for another
profession.

Agreeing with something that wasn't said is a child's ploy.
Try harder.

The experience of working 24/7 and seeing a relationship with my
girlfriend destroyed

I think all the projection about other programmers and their assumed
unhappiness can be better understood now at least. Thanks for the
explanation, it clarifies a lot of things you have said. I'm truly
sorry that things went so badly for you. This probably won't help any,
but we haven't all suffered this way, so expecting that your
experiences apply to the rest of us is probably not going to be
fruitful.

Shove your phony compassion up your ass, Howard.

More collegial discourse is demonstrated. Again, I pass on returning
the favor.

This was ancient history, and I learned from it.

Well, you did bring it up now, so you apparently had some reason to
dredge it up. I can't figure out quite what it would be right now. I
could guess, but not with any accuracy. You might look into that last
bit and learn from it, but I don't hold out much hope at this point.

Nilgewater aside, nothing in that implies /anything/ about a compiler
optimization doing what you think it *should* do, because it can't
reliably *guess* your intent there, without some means of at the very
least hinting to it if it is okay to assume that a function call will
return the same value each iteration and that not calling it won't
cause some desired side-effect to not actually take place N times via
those calls. You could argue the evils of side-effects, but the fact
is the language provides for them anyway. If you want more guarantees
in this regard, you might investigate Haskell, for example.

In a normal C text, the side effects can happen only to global
variables. It is true that once the programmer in C starts to use
addresses and aliasing, all bets are off. This doesn't mean that
optimization fails to work for the VAST MAJORITY of C programs (all
commercial compilers come with it).

Feel free to provide an example on ANY "commercial compiler" that
supports a correct optimization for your original code, not the
strawman above. If you wish to admit that you put no faith in your
original code being handled as you thought, feel free. Any further use
of the above code instead of your original will certainly appear to be
a tacit admission of that.

It DOES mean that C should no longer be used

I will stipulate that I agree that you should no longer be using C, if
that makes you feel any better.

False, false, and false. If you /really/ believe that bugs in
optimizers are vanishingly rare, then you /really/ need to use them
more. Also, you previously stated "Any code can have bugs." Do you
recant that now?

No, I don't. Your code has bugs. My code has bugs. We fix these one by
one as quickly as possible.

I do. You have shown a strong reluctance to admit bugs, much less fix
them, but you may very well fix them privately, even if you are not
willing to admit doing so publicly.

Go to comp.risks. Most software errors are created, not by automated
tools, but by individual programmers making assumptions. Most of them
are loudmouthed bullies, is my guess.

You see overly reliant on guessing. Perhaps that is the core issue
here. If your crystal ball worked better, you might even get away with
it.

I thus profited from the 2003 discussion, but no thanks to you. The
most useful information came from Programmer Dude.

The same programmer dude you called a bully and part of this evil group
aiming to annoy you earlier. Ok, we can now add "fickle" to the list
of descriptives.

I abandoned C for the same reason I abandoned IBM mainframe assembler
when IBM finally released usable PL/I compilers in 1974.

Yes, I well remember this PL/I tangent. Your claims of it and your
"understanding" of it were raised in a PL/I newsgroup, and taken to
task. Don't try again.

Even in C, we can tell if the for variables are modified in most

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw





.

Relevant Pages

  • Re: Letter to US Sen. Byron Dorgan re unpaid overtime
    ... >> considered to be a convenience by those who use the C language. ... I make no claims to being a VB.NET programmer. ... Ritchie SCREWED UP in designing the for loop because ... I do not believe that you are capable of writing a conforming C compiler. ...
    (comp.programming)
  • Re: SETF and variable issues in Self Similar program.
    ... The way to get a compiler to optimize a tail-call ... call optimization turned on. ... It changes the semantics of the language in a big way. ... In Common Lisp it has to interact with condition handling, ...
    (comp.lang.lisp)
  • Re: why still use C?
    ... > to be at the mercy of the compiler and its designer, ... as a programmer I am no ... > program using templates and expect it to work identically on different ... > in mind that a programming language is a tool to make programs. ...
    (comp.lang.c)
  • Re: left-to-right (was In-Out Parameters for functions)
    ... > What I would expect from a good compiler is factoring out the cycle ... > implicit order is the one assumed by the programmer. ... That is not possible in Ada 95; it would be possible in "left-to-right ... > sort of premature optimization Knuth wrote about. ...
    (comp.lang.ada)
  • Re: Letter to US Sen. Byron Dorgan re unpaid overtime
    ... a professional programmer however. ... >> The 'compiler mechanisms' for handlng for loops in various languages, ... I know Richard isn't so incompetent as to attempt to implement a compiler ... the defined semantics for that language. ...
    (comp.programming)