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!boylan
rob@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) Silverstein
geoff@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!geoff
alan@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