rob@rabbit.UUCP (07/12/84)
Those who can, do; those who can't, comment.
boylan@dicomed.UUCP (Chris Boylan) (07/13/84)
From: rob@rabbit.UUCP
Those who can, do; those who can't, comment.
Barf. Don't say this kind of stuff, you never know who will
believe you ...
--
Chris Boylan
{mgnetp | ihnp4 | uwvax}!dicomed!boylanrob@rabbit.UUCP (07/13/84)
Sorry; i repent. here is an improved version of one of the hoc routines,
to set a new style of example.
Here is the original:
bltin()
{
Datum d;
d = pop();
d.val = (*(double (*)())*pc++)(d.val);
push(d);
}
And the improved version:
/********************************************************************************
* *
* *
* bltin *
* *
* *
********************************************************************************/
/*
* Evaluate a built-in
*/
bltin() /* Declare the function */
{
Datum d; /* Declare the variable d of type Datum */
d = pop(); /* Call pop() and place the result in d, which was
(conveniently) already declared */
/*
* This is the clever part
*/
d.val = (*(double (*)())*pc++)(d.val);
/*
* Whew! that was hard.
*/
push(d); /* Return a result */
}
/********************************************************************************
* *
* *
* end of bltin *
* *
* *
********************************************************************************/ajs@hpfcla.UUCP (07/14/84)
From rabbit!rob (presumably Rob Pike, co-author of tUPE): > Sorry; i repent. here is an improved version of one of the hoc routines, > to set a new style of example. > > Here is the original: > bltin() > { > > Datum d; > d = pop(); > d.val = (*(double (*)())*pc++)(d.val); > push(d); > } > > [ followed by a horrendous example ] Ugh. Surely you jest. But it does you discredit, for you mockingly assume there is no better way to do it without getting ugly. Since you fired the opening round, I'll volley back with a better example (in all seriousness). Forgive me if the comments are erroneous; I'm not sure from your listing what exactly this procedure DOES. :-) And I'm not going to even try to untangle that (undoubtedly efficient but who cares?) ugly procedure call. /*********************************************************************** * B U I L T I N * * Call a built-in function with data from the expression stack and * advance the procedure pointer as a side-effect. The ugly procedure * call treats the current procedure pointer as a {hell I can't tell, * and cdecl doesn't help either, so it bloody well should be explained * here or below, because most of us aren't C compilers}. */ local void BuiltIn() { Datum data; /* working copy */ data = PopData(); data.value = (* (double (*)()) *proc++) (data.value); PushData (data); } /* BuiltIn */ /*********************************************************************** Alan Silverstein, Hewlett-Packard Fort Collins Systems Division, Colorado {ihnp4 | hplabs}!hpfcla!ajs, 303-226-3800 x3053, N 40 31'31" W 105 00'43"
ajs@hpfcla.UUCP (ajs) (07/14/84)
From: rabbit!rob:
> Those who can, do; those who can't, comment.
Those who can, do; those who can't, comment; and those who can do better,
do better, and comment, too.
-- Alan (real engineers love their software) Silversteingeoff@callan.UUCP (Geoff Kuenning) (07/21/84)
Rob Pike (rabbit!rob) has successfully demonstrated that anyone
can set up a straw man and knock it down. I won't repeat Rob's
deliberately noise-loaded posting, since all it contained was a lot
of specious lines to prove that his terminal has an asterisk key.
Following is Rob's original uncommented program and a suggested way
to code the same function with USEFUL comments.
Rob's original:
bltin()
{
Datum d;
d = pop();
d.val = (*(double (*)())*pc++)(d.val);
push(d);
}
And a TRULY improved version:
typedef double (*pfd_t) (); /* Ptr to func returning double, to clarify */
/* ..the C syntax below */
bltin() /* Execute any built-in function */
{
Datum scratch;
scratch = pop (); /* Get value to operate on */
/*
Run the function pointed to by "pc" on the top-of-stack value
*/
scratch.val = (*(pfd_t)(*pc++)) (scratch.val);
push (scratch); /* Store result */
}
Certainly, the sample routine is small enough that a good C programmer can
understand it, with or without comments, in a few minutes. Rob's deliberately
obfuscatory "comments" are successful in making this a harder task. But
well-written comments can turn those few minutes into a few seconds, which is
important when you are dealing with a 50- or 100-line routine that is part
of a very large program.
In passing, let me note that Kernighan & Plaugher have sufficiently
addressed the "i++; /* Increment i */" type of "comment" that Rob so
loaded his "example" with. If he really thinks that that is what commenting
is all about, I suggest that he investigate some of his co-author's other
books.
--
Geoff Kuenning
Callan Data Systems
...!ihnp4!wlbr!callan!geoffalan@allegra.UUCP (Alan S. Driscoll) (07/23/84)
Rob Pike tell us:
> Those who can, do; those who can't, comment.
Funny. I thought it was:
"Those who can, do; those who can't, write books."
--
Alan S. Driscoll
AT&T Bell Laboratories