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

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. I still use Hungarian.

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.

I think people, and code READABILITY, are more important than
generating extra variables to save pico-seconds.

That is a fair point, the only issue being that pico-seconds are /not/
what is being addressed. The results of some fairly simple test runs
against your "readable" and apparently recommended usage were far more
measurable than that. Worse, you know it, but for some reason simply
refuse to admit it.

At some point, while looking at the archives, I discovered some
numbers developed by the Dude in which his favorite solution was an
order of magnitude faster than mine. The problem is that this wasn't
the issue under discussion. It was instead whether OO code was more
easier to understand.



I was addressing reliable and transparent code

Since it wasn't reliable, given bugs were pointed out which you
actually /did/ admit to, and "transparent" is a buzzword, especially
here, since your meaning doesn't meet reality. Transparent code by any
rational meaning doesn't make experienced programmers sit up and say
"what in the hell is this guy thinking here??".

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 think you programmed for a living.

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

Screw you.

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






It's not a buzzword, it's a word that has been used in the industry for
/at least/ 25 years, probably much longer, and not only that, the word,
unlike much of CS terminology, is actually very descriptive of the
action taken.

I don't think you've been in the industry that long.

a) I didn't say I was.
b) You have no idea whether I have or not, just as I have no idea
whether you are 15 or 85. Such are the perils of remote
unauthenticated discourse.
c) It doesn't matter anyway.

Sure, you're a sniper from concealment who destroys communicative
societies, as were the Chetniks in Sarajevo, because owing to military
post-traumatic stress, sexual anxieties, or other syndromes, YOU CAN'T
STAND IT when this forum is used as intended.

Quite the contrary, I prefer it when it is. Talking about the
oppression of the chinese, or referring to the mistakes about the order
of "first" and "last" names of individuals from a completely foreign
culture is racist, or snipers in Sarajevo, or the evils of corporate
America is not, I'm willing to wager, the manner in which this
newsgroup was intended to be used. They probably do have newsgroups
where that is appropriate, but I am extremely confident that this isn't
it.

I have said it before. It is IMPOSSIBLE to adhere to a focus Nazi's
rules, and he knows it. Programming is about something else. In the
case of international data processing, 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) is Job One, not claims
that "I can do dat in HTML".

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 CAN'T STAND IT. You can't stand the fact that I know more about
REAL programming and REAL computer science, and somehow find time to
read a quality newspaper and several books a week, because I don't
waste my time pushing people around. My "verbosity" is simply the fact
that I can relate things about which you and other Computer Thugs are
bone ignorant, and when I post code, this drives you crazy, because
you struggle to understand your own chosen profession, and you fail.




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. An apology is in order for your stupid and insensitive error,
and if I were you (which I am not) I would use that as a pretext for
even more bullying.



Computer Thugs (not "programmers") have been creating messes and
billing Yuppie Thugs for cleaning them up by attempting manual code
optimization, for quite a long time.

Not that you would know necessarily, but programmers have been writing
code longer than their have been optimizing compilers, or compilers at
all. More recently, most, if not all compilers have had multiple
optimization bugs at one time or another, and real programmers are
expected to work around these issues, not blame their failures on the
compiler(s).

This is just nuts.

No, I'd say that ranting and raving about "Computer Thugs" and "Yuppie
Thugs" ad nauseum fits that a lot more closely than discussing compiler
optimization issues, any way you slice it.

What you can't stand is the ability to do two things at once. I am no
expert in optimization, but, I discuss its basics and implemented
constant folding and other simple techniques in the compiler for my
book. How about you?



Any code can have bugs.

Agreed.

We're making progress


If you really believe that the (remote) possibility of bugs in a
commercial optimizing compiler,

Some words missing there? If I believe the possibility does what?
Exist?

If you really believe in the possibility ...

Don't pretend you can't read. You already seem rather ignorant and
insensitive, so there's no need to play the fool.

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



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, and even having to narrate what the compiler "must" do in a
standard means that the language bites the big one.

would also need to demonstrate that that optimization (making an
assumption about the volatility of a string and whether or not it might
be modified outside a loop, and guessing (or having keyword changes)
as to whether or not the programmer desires this shortcut to be taken
would not introduce more bugs. It is also highly likely to introduce a
lot of new bugs, for those that don't make false assumptions about the
compiler's behavior and for whom a function call inside the loop would
/not/ be an optimization. Good luck with that one.

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. The only problem is the small but real possibility
that (say by looking at addresses as long integers inside doFoobar),
the idiot who coded doFoobar discovered, in his mind, how to get to
the runtime environment at the stack, and uses this knowledge.

The stud professional who wants to do the optimizer's work for it,
being a damned fool, may be as unaware of doFoobar's access to runtime
stacks as the compiler itself.

All we're saying is use the goddamn optimizer...and then test again,
if only to see what it's bought for you in terms of time and space.



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. Why do you force me to do as you do, and try to get you to
leave by such a global questioning of your existence? Is this what you
wanted all along, to be made to look like a fool?


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. This was ancient
history, and I learned from it.

People who write compilers will in fact do what I did, and show the
limit calculation in a for loop in a de minimis situation, because
they know how, unlike you, to do quality assurance by desk-checking
code, and they accomodate their own limitations, along with the time
limits imposed by thug capitalism, by not generating extra variables
named foo or work.

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). It DOES mean that C should no
longer be used, nor should a book published in 2007 claim that ANY C
code is "beautiful".



You may think that you know what it *should* do, but it can't possibly
guess correctly in all cases, at least not as you implemented it.

This way they do indeed ship working optimizing compilers which you
need not worry about, in part because you're not qualified to worry
about them, because you haven't studied the subject.

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.

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.


Read the theory, in COMPILERS: Principles, Techniques and Tools. Job
one is to PRESERVE THE SEMANTICS of the code, even your crap code.

Job one and achievement one should be the same, but alas they are not
always. More importantly, since you have already admitted that when
you wrote the code, you had a rather glaring misunderstanding of the
SEMANTICS of the code in question, I do not see why it is so hard for
you to just admit it and move on, instead of all this misdirection.

I'd forgotten the semantics which were at the forefront of my
consciousness between 1987 and 1992, when I used C heavily. As a
result of my relearning them, I included a special heads-up as regards
the different semantics of Basic in my book. Basic languages (which
need to be referred to in the plural owing to their diversity) for the
most part implement the "by value, precalculated" for loop when they
do the structured constructs at all, and I discussed how I implemented
this in the interpreter.

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

I abandoned C for the same reason I abandoned IBM mainframe assembler
when IBM finally released usable PL/I compilers in 1974. It isn't
"intelligent" to be the sort of idiot savant who owing to adult-onset
autism can never forget a detail, such as the fact that MVC in IBM
assembler doesn't work past 255 bytes (I think).

Even in C, we can tell if the for variables are modified in most
instances by looking for assignments, whether the use of the
assignment operator or the use, in a procedure call, of the address of
a variable as a parameter, and the compiler can move the for
calculation to the initializer of the loop.

Given that you didn't even /know/ how assignments worked in a C for
loop, by your own admission, as late as 2003, yet you claimed to have
been using C "professionally" far earlier, why should I believe that
the "we can tell" claim should include you in ...

I don't know what you're talking about. If you mean that when I coded
the for loop, I used a style influenced by the VB semantics, and
naturally calculated the value of an expression in the condition, I
plead "guilty" because I was discussing why OO is more readable, not
pico-efficiency. If you're saying I don't know C assignment, I pity
you, because I know (and I taught) that one of C's few virtues is the
fact that assignment is just another operator whose left side is an
lValue. I rather doubt that you can write a coherent definition of an
lValue right here, so if you'd like to continue to bully and trash
people, let's hear you do so.


read more »- Hide quoted text -

- Show quoted text -

.

Relevant Pages

  • Re: Brian Kernighan, maybe Im not worthy, maybe Im scum
    ... and just hone in on the stuff related to programming and this newsroup] ... moron that was taken from optimization which does hoist when to do so ... compiler design and optimization, including my 1976 text in graduate ... loop in a language in which the designers messed up, ...
    (comp.programming)
  • Re: Why is C# 450% slower than C++ on nested loops ??
    ... The posted benchmark was crucial to ... > compilers generate for the loop and get over with it. ... > additions in the outer loops, which the C# compiler doesn't. ... gotten around to implementing every possible optimization in every language, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Brian Kernighan, maybe Im not worthy, maybe Im scum
    ... No, you assumed, and admitted so, that the compiler would address it ... Randy, the Computer Thug. ... manual code optimization for quite a long time. ... Not that you would know necessarily, but programmers have been writing ...
    (comp.programming)
  • optimizers are overrated
    ... I started learning ASM not long ago to improve my understanding of the ... The first function uses a typical C style loop to ... which one is more efficient all you guys would reply "the compiler will most ... so my "write C like ASM" optimization worked. ...
    (comp.lang.c)
  • Re: the quality of assembly language code
    ... what people considered "optimization" when Tony Hoare wrote this paper ... > this potential of assembly language code "beating" the compiler is ... programmers are too lazy to write the code efficiently. ...
    (comp.lang.asm.x86)