HDTenEightyP/NetNews huggingface dataset:
From: sca@gese.ge14.mdadv.gv.at (Petzi Schweda)
Subject: Re: The Correct Way To Write C if-Statements
Originator: sca@gese0n.ge14.mdadv.gv.at
Organization: MD-ADV
Date: Thu, 12 Nov 1992 13:07:10 GMT




     if   (condition)
          nice statement;
     else {
          lot's of statements ...
          }

     if   (cond)
          do_this;
     else if   (cond)
               do_that;
          else got_lost;

     for  (and so on ...)
          {
          body ...
          }

     while(cond)
          {
          and so on ...
          }
    
Got the main idea ?
Not only the "if's" but all blocks take the same
indention: 5 spaces.
To avoid another discussion: I like to have the 
paranthesis under each other VERY much, especially
the opening and closin one's. Who the hack has invented
this unlucky 
     if  (cond) {
         ugly_statements;
         }
paranthesis-into-if-line-style ????

regards, Petzi
-- 
----------------------------------------------------
Petzi Schweda (sca@gese.ge14.mdadv.gv.at)
MD-ADV, Municipality of the City of Vienna, Austria
-- 
----------------------------------------------------
Petzi Schweda (sca@gese.ge14.mdadv.gv.at)
MD-ADV, Municipality of the City of Vienna, Austria
Newsgroups: comp.lang.c
From: tim@unipalm.co.uk (Tim Goodwin)
Subject: Re: Order of evaluation?
Organization: Unipalm Ltd., 216 Cambridge Science Park, Cambridge CB4 4WA, UK
Date: Fri, 6 Nov 1992 12:54:09 GMT

Josef Moellers <mollers.pad@sni.de> writes:

>My understanding was (and still is), that functions need only be called
>as far as necessary.
>E.g. in an expression like
>	a() * b() * c() * e() * f() * g()
>the compiler might decide to generate code to test the intermediate
>result to be 0, in which case the rest of the expression might be
>dropped.

No.  C operators are eager, that is, they always evaluate all their
arguments.  (The exceptions, which were mentioned earlier in this
thread, are || and &&, which might be better thought of as flow control
constructs.  Perl and sh programmers tend to think of them in this way.)

In the quoted example, each of the functions must be evaluated (although
there is no guarantee about the order in which they are evaluated).  It
is possible that the compiler might avoid some of the multiplications,
if it happens to notice that they are unnecessary, but it may not omit
any of the function calls.

Tim.
Newsgroups: comp.lang.c
Subject: Re: Is this ANSI C?
From: a_rubin@dsg4.dse.beckman.com (Arthur Rubin)
Date: 9 Nov 92 18:15:01 GMT
Organization: Beckman Instruments, Inc.
Keywords: A bet

In <1dhkrtINNj99@duvel.cs.ubc.ca> hassan@cs.ubc.ca (Moustafa Hassan) writes:

>#include <stdio.h>
>void main(void)
>{
>  printf("hello world\n");
>}

>To settle a dispute, would someone please tell me whether the above
>is ANSI C.  I claim that 'main' (according to the pure ANSI standard)
>must return an integer value, but nonetheless, some non-purists claim
>that the above is ANSI.  Please do not respond via email; I want 
>my opponent (8^) to be able to see all the messages.

You are correct.  (Many compiler/OS combinations don't care, except they
may produce extraneous error messages on termination.)
--
Arthur L. Rubin: a_rubin@dsg4.dse.beckman.com (work) Beckman Instruments/Brea
216-5888@mcimail.com 70707.453@compuserve.com arthur@pnet01.cts.com (personal)
My opinions are my own, and do not represent those of my employer.
My interaction with our news system is unstable; please mail anything important.
Newsgroups: comp.lang.c
From: darcy@druid.uucp (D'Arcy J.M. Cain)
Subject: Re: How to use 'return' in c?
Date: Thu, 12 Nov 1992 12:55:24 GMT
Organization: D'Arcy Cain Consulting

srhqla!quest!kdq writes:
>darcy@druid.uucp (D'Arcy J.M. Cain) writes:
>> Whenever I see TRUE and FALSE in code I am maintaining I remove the
>> #defines.  If they are defined, they should never be anything but
>> TRUE = 1 and FALSE = 0.  Anything else is confusing and misleading.
>    On the other hand, since C does not truly support the boolean type,
>I consider it misleading to assign a numeric value to a boolean.  I
>define TRUE as (1==1) because the result of this is a boolean - the
>fact that it is represented by a numerical value is misleading.

Well as you say, C does not support the boolean type.  A true expression
evaluates to 1 and a false to 0.  That's the definition of the language.
(1==1) evaluates to 1 so it is the same as defining TRUE as 1.  If I see
TRUE and FALSE in your code i *still* have to check that it is defined
correctly.  The fact that your definition works is irrelevant, it still
costs me time to confirm that.

To me it seems like defining SEVEN as 7.  It's correct but I wouldn't
do it.

-- 
D'Arcy J.M. Cain (darcy@druid.com)  |
D'Arcy Cain Consulting              |   There's no government
Toronto, Ontario, Canada            |   like no government!
+1 416 424 2871          DoD#0082   |
Newsgroups: comp.lang.c
From: msb@sq.sq.com (Mark Brader)
Subject: Re: retrospective on evaluation order
Organization: SoftQuad Inc., Toronto, Canada
Date: Wed, 11 Nov 92 06:46:22 GMT

At the end of a very nice article, Steve Summit (scs@adam.mit.edu) writes:

> P.S.  In this article, I have deliberately been casual rather
> than rigorous in my explanations.  (In particular, I have freely
> used the term "precedence" which Chris correctly points out can
> be superfluous as well as misleading.)

I would like to point out one more place where Steve was casual.
He wrote:

> In the expression
> 
> 	d + e + f
> 
> ... associativity tells us that d should be added to e and the
> sum added to f, i.e. that it should be evaluated as
> 
> 	(d + e) + f

And later:

> We can now turn to a couple of final points, the first of
> historical interest only.  K&R ("Classic") C gave a compiler
> license to rearrange associative operators.  That is, given
> 
> 	d + e + f
> 
> , the compiler might emit code to add e to f first, or even d to f.
> This license has been revoked under ANSI C ...

The possibly confusing term here is "associativity".  The reason it's
confusing is that it might be taken to imply that + is an associative
operator... i.e., that (d+e)+f HAS TO be equal to d+(e+f).  In fact
that isn't what the term means.  It refers to the property of the
formal definition which implies that, as the paragraph says, d+e+f
is treated like (d+e)+f.  The casual term "associativity" for this
arises because this property is sometimes described with words such
as "the + operator associates left to right".  To above this confusion,
some of us prefer to use the verb "groups" here instead.

The reason this is significant is precisely that the operations +
and * are _not_ necessarily associative on a computer.  In ordinary
arithmetic, of course, they _are_ associative, and THAT is what the
reference to "associative" in K&R and in the last quoted text means.

For comparison, note that the - operator is not associative in ordinary
arithmetic, nor on a computer of course; but it too "associates [or
groups] left to right", because c-p-r means (c-p)-r.
-- 
Mark Brader			"What a strange field.  Studying beings instead
SoftQuad Inc., Toronto		 of mathematics.  Could lead to recursive
utzoo!sq!msb, msb@sq.com	 problems in logic."	-- Robert L. Forward
						(The Flight of the Dragonfly)
This article is in the public domain.
Newsgroups: comp.lang.c
From: hamjavar@hydra.unm.edu (Farid Hamjavar)
Subject: cvs
Date: Tue, 10 Nov 92 20:38:34 GMT
Organization: University of New Mexico, Albuquerque


Hello : 

Has any one heard of this softeware called CVS  -- for managing
project source codes.  Do you know if it can be obtained free from
some archive (ftp).

I appreciate if you reply by e-mail.


Thanks 
Farid Hamjavar
Xref: sparky comp.lang.c:16486 comp.lang.c++:16251
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Newsgroups: comp.lang.c,comp.lang.c++
Subject: Re: *** IMPORTANT DISCOVERY ***
Date: 13 Nov 1992 23:00:59 -0600
Organization: Kansas State University
NNTP-Posting-Host: matt.ksu.ksu.edu

What the hell was that?

-- 
Dan Odom
Kansas State University
danodom@matt.ksu.ksu.edu
Member of the League for Programming Freedom; mail lpf@uunet.uu.net
From: CC024NAC01@trent-poly.ac.uk (Neil Chick)
Newsgroups: comp.lang.c
Subject: Borland C Using Extended Memory
Date: 12 Nov 1992 14:25:39 -0600
Organization: UTexas Mail-to-News Gateway
NNTP-Posting-Host: cs.utexas.edu

Borland C using Extended Memory
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Can anyone help me with a problem using the extra memory in Borland C?

I am trying to process a TIF file using Borland C on a 386 with 4 Megs of RAM
However I can only get access to 1Mb of Memory not access to the full 4 Megs..

Which means I can't read the TIF file complete into memory so it becomes
very hard to carry out processing on it.

Has anyone got any ideas on how to access the full extended memory using
Borland C?

If this is the wrong Newsgroup then tell me which one to use, Please.

Please reply via Email cause I can't read News :-(

Thankyou for any help..

Neil Chick
cc024nac01@trent.ac.uk

Newsgroups: comp.lang.c
From: brown@NCoast.ORG (Stan Brown)
Subject: Re: DEC VMS VERSION OF C - HOW TO ASSIGN FILE NAME?
Organization: Oak Road Systems, Cleveland Ohio USA
Date: Sun, 8 Nov 1992 19:35:47 GMT

In article <1992Nov6.072147.16000@sbcs.sunysb.edu> rhorn@csws11.ic.sunysb.edu (Robert Horn) writes:
>
>Look up fopen (and fclose while you're at it) in your favorite C
>book (which should be K&R 2nd Edition).

Ordinarily, this is good advice.  However, when dealing with a
particular compiler it's generally advisable to look at the manual for
that compiler.  In the particular case of VMS C, which is not ANSI C but
a DEC-enhanced version of "classic" C, either version of K&R will
mislead you on many points of libraries.  For instance, if you want
to write a normal text file, you must specify _four_ arguments to fopen:
   fileptr = fopen(filename, "w", "rat=cr", "rfm=var");
You won't find that in K&R.

-- 
Stan Brown, Oak Road Systems                      brown@Ncoast.ORG
Cleveland, Ohio, USA
"Only the futility of the first flood prevents God from unleashing another."
            --Chamfort, as quoted in Claude Arnaud's {Chamfort: A Biography}
From: blume@kastle.Princeton.EDU (Matthias Blume)
Newsgroups: comp.lang.c
Subject: Re: To Recurse or NOT to recurse?
Date: 7 Nov 92 20:57:04 GMT
Reply-To: blume@kastle.Princeton.EDU (Matthias Blume)
Organization: Dept. of Computer Science, Princeton University

In article <geyke2W00VQsEhTcIK@andrew.cmu.edu>, Richard Dale Romero
<rickr+@CMU.EDU> writes:
|> Excerpts from netnews.comp.lang.c: 6-Nov-92 To Recurse or NOT to
|> recurse? Stephen Schow@netcom.com (577)
|> 
|> > What is better to do when traversing a linked list..... SHould I use
|> > recursion to search down through the list for the last node, or should I
|> use a while loop?  What or the pro's and con's of each?
|> 
|> Some compilers are really smart, and they will turn your code into (if
|> it is tail recursion) into a while loop.  Others won't.  If it doesn't,
|> are you wasting space?  Yes.  How much?  Well, you're using O(N) space
|> when it can be done in O(1) space.  That's a lot as far as I'm
|> concerned.  And speed?  Bit trickier, and dependent on the machine you
|> use, but I'd lay odds on the while loop, say 10:1, that it'd be faster.
|> 
|> -rick
|> 
|> 

I would not count on such a ``smart'' C compiler, because there are lots
of issues, which can prevent it from generating loop code for a tail recursive
function.  (Think about addresses of local variables, setjmp/longjmp and
alloca).
In a language like Scheme, which is *defined* to produce code, that runs in
constant space for tail recursions, you can (and in fact must) count on it.

-Matthias
Xref: sparky comp.lang.c:16454 comp.software-eng:4264
From: ooprb@Msu.oscs.montana.edu
Newsgroups: comp.lang.c
Subject: Reading 0x0D in a binary file returns 0
Date: 3 Nov 92 03:52:37 GMT
Article-I.D.: Msu.00963079.30E098C0
Reply-To: ooprb@Msu.oscs.montana.edu
Organization: Montana State University

Could someone help me with reading in 0x0D in a binary file?
I've been using this:
	byte[ptr] = fgetc(in);
I've got it to read everything except 0x0d.  It is assigning
byte[ptr] to 0.  Does anyone know what I am doing wrong?  How
to fix this?  Examples?

Thanks in advance...

Please E-Mail to:
ooprb@trex.oscs.montana.edu

		Rocky
From: eager@eagercon.com (Michael J. Eager)
Newsgroups: comp.lang.c
Subject: Re: How to use make to create two different targets from the same sources
Date: 12 Nov 92 08:15:57 GMT
Reply-To: eager@eagercon.com
Organization: Eager Consulting

In article 4479@quintro.uucp, reb@quintro.uucp (Roger E. Benz) writes:
>I would like to setup a Makefile that would allow me to create two
>different targets from the same source files.  Our primary target is
>a 68k embedded system for which we use a cross compiler.  During
>development, however, we find it useful to build test version using
>the native compiler.  Currently, I have to edit my Makefile to switch
>compilers and then run: make clean.  If anyone knows of an easier way to
>accomplish this, I would be most thankful.

Have you tried specifying CC=/bin/cc or whatever on the make command line?

---
Michael J. Eager		Michael.Eager@eagercon.com
Eager Consulting		(415) 325-8077 
1960 Park Boulevard, Palo Alto, CA 94306-1141
From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: meanings of "void" keyword
Date: 8 Nov 1992 11:05:03 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley
Reply-To: torek@horse.ee.lbl.gov (Chris Torek)
NNTP-Posting-Host: 128.3.112.15

In article <27264@dog.ee.lbl.gov> I claimed that
>> `void' has two meanings in ANSI C ...

Oops!

In article <721104887@sheol.UUCP> throopw@sheol.UUCP (Wayne Throop) writes:
>Um.  I thought void had three meanings in ANSI C.  The above two, and 
>
>         - A void prototype (eg:   void f(void);      ) ...

Believe it or not, I actually wrote `three meanings', but then I could
only think of two when I went to enumerate them, so I went back and
`fixed' the claim.  I had the feeling I was forgetting something....

>In fact, these three uses are essentially independent.

Yes; this is obnoxious and misleading, just like the peculiar use of
`static' to affect function name scopes.  But it is not that big a
deal.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov
From: jamiller@hpcupt1.cup.hp.com (Jim Miller)
Newsgroups: comp.lang.c
Subject: Re: Help - What Is Wrong?
Date: 13 Nov 92 00:36:58 GMT
Organization: Hewlett Packard, Cupertino

>comp.lang.c / mjs@hubcap.clemson.edu (M. J. Saltzman) 
>
>Presumably, "i != 5" is "less safe" because a failure of the initial
>condition to satisfy i < 5 will not result in an infinite loop
>(especially if the initializer "i = 0" is replaced by, say, "i = j + 1",
>or if the initial i is passed as a parameter).  On the other hand,
>this may not be the best kind of "safety" to have.
>
>In _The_Science_of_Programming_[1], David Gries argues that the guards
>on loops should be as weak as possible, so that if the initial
>condition is violated, the program will fail catastrophically (i.e.
>with an infinite loop).  

IMHO: yes and no.

While unit testing, "i != 5" might be the better idea for the reasons stated,
for *production* I'd choose "i < 5".  If the program can continue to limp
along instead of crash/hang, the user may still be able to use it,
they may be able to save their data, they may even be able to survive.

I agree that for OS code the policy of "if anything is wrong: DIE
immediately" is the best policy, but I don't like applications that do that.

Just *why* do you want the user to have an application that hangs when the
task presently being performed might be a minor one?

The risk to user data will be, in general, no worse for continuing
than for aborting/hanging immediately.  (This is based upon absolutely
no data what so ever :-).

I usually have a backup of my old data, it's my work of the last 2 hours
that I want a *chance* to save.

An immediate halt/hang *will* cause loss of all currently changed data.
In the middle of many change operations, it *will* cause the data to
be useless.

Continuing may, or may not, cause loss of data.  Immediate halt/hang will,
however, should prevent any data from getting back to the disk (or other
device), which is why for OS code it may be the best policy (I don't want
my directories corrupted :-().

Think of real life: do you want your car to halt in the middle of nowhere
because the oil is low, or do you want it to tell you (using an idiot
light) that something is bad and let you take the corrective action?  

Note: in critical situations the argument changes.  While inserting
control rods in a nuclear reactor, I want the program to continue,
while removing control rods I want it to hang or abort -- except that
I do NOT want it to loop forever on "remove control rod i, i+1, i+2, etc".

Ok, David Gries and I disagree. 
So, an  expert  and I disagree.
So, what else is new?  :-)


   jim miller
   jamiller@cup.hp.com
   (a.k.a James A. Miller; Jim the JAM; stupid; @!?$$!; ... )
   Anything I say will be used against me ...
   But my company doesn't know or approve or condone anything of mine here.
Newsgroups: comp.lang.c
From: dfuller@portal.hq.videocart.com (Dave Fuller)
Subject: Re: Need help reading floats from file
Organization: VideOcart Inc.
X-Newsreader: Tin 1.1 PL3
Date: Sat, 7 Nov 1992 04:59:33 GMT

cee1@Ra.MsState.Edu (Charles Evans) writes:
: Ok, in getting data for an experiment to look at, I have
: 200 .xx floating point number, just a decimal point and 2 decimal
: places, put in 20 x 20 in a data file.
: 
: How can I read them into an array.. all i could think of was do 
: a HUGE fgets/sscanf thing with "%f %f ... %f".. 20 times and put into
: 20 parts of an array like : value[i++][j] on an on until i=20 then
: reset i and increment j..
: 
: data file looks like:
: 
: .11 .33 .00 .......
: .23 .45 .23 .......
:  .   .   .
:  .   .   .
: 
: 20 x 20
: 
Chuck,
  as long as its definitely a 20x20 this will work. if the size is variable
or if it may change then this needs to change.


float numbers[20][20];

/* note that each of the first elements has associated with it the 
/* 20 numbers that were on the line in the file
/*
/*  i.e.  numbers[1][5] = 6th number in the first line
/*                        yes 6th, 0 indexing here . . . 

FILE *fp;
int  i,  
     j;

fp = fopen("file", "r");

for(i = 0; i < 20; i++)
{
   for(j = 0; j < 20; j++)
   {
      fscanf(fp, "%f", &(numbers[i][j]));
   }
}

fclose(fp);

you don't need fgets because fscanf will continue past the end of
a line, it only fails at EOF.

Hope this helps you

Dave Fuller
dfuller@portal.hq.videocart.com


Newsgroups: comp.lang.c
From: bandy@netnews.jhuapl.edu (Mike Bandy)
Subject: Re: DEC VMS VERSION OF C - HOW TO ASSIGN FILE NAME?
Organization: JHU/Applied Physics Laboratory
Date: Sat, 7 Nov 1992 05:51:47 GMT

Robert A Rawlinson <34R33O7@CMUVM.CSV.CMICH.EDU> writes:

>I HAVE A COUPLE OF STUDENTS DOING SOME C PROGRAMING FOR ME. I AM NOT A
>GOOD C PROGRAMER SO I COULD NOT SEEM TO FIND THE ANSWER IN THE MANUALS.
>IN COBOL I CAN CODE A FILE NAME AND THEN WHEN I RUN THE PROGRAM I CAN
>ASSIGN A FILE NAME AND DIRECTORY. MY STUDENTS CODE IN C AND INDICATED THE
>FILE AND DIRECTORY HAVE TO BE HARD CODED. I SUSPECT THERE IS A WAY TO
>USE A NAME THAT I COULD ASSIGN A FILE AND DIRECTORY TO LATER AS IN COBOL.
>COULD SOMEONE POINT ME IN THE CORRECT DIRECTION TO SOLVE THIS?
>THANKS
>BOB

File handling as you require is not part of the C or Cobol RTL but built into
the operating system.  Use a logical name in your program, let's call it FOO.
Then you open FOO using the fopen routine:
    fd=fopen("FOO","r");
FOO is now hardcoded into the program -- but from DCL you can point FOO anywhere
you want using the DEFINE verb (or use ASSIGN if you'd rather).  Like:
    $ DEFINE FOO DISK$USER1:[DIR1]FILE1.XXX
Run your program against FILE1.XXX
    $ DEFINE FOO DISK$USER2:[DIR99]FILE99.XXX
Run your program against FILE99.XXX

You also have the option of passing the file name on the command line using
the parameters on main().  For example, code your C routine like:
    main(int argc, char **argv)
Then the filename is retrieved using argv[1] (check argc to be sure that it's
at least 2).

This requires you to create a local symbol from DCL for the program prior 
to it's execution.  Like this:
    $ MYUTIL :== $MYDISK:[MYDIR]MYPROG

Then run it like:
    $ MYUTIL DISK$USER12:[DIR21]FILE21.XXX



-- 

	Mike Bandy
	bandy@aplcomm.jhuapl.edu
	Johns Hopkins University / Applied Physics Lab
Newsgroups: comp.lang.c
From: cpcahil@vti.com (Conor P. Cahill)
Subject: Re: Malloc Debug
Keywords: debugging random free's
Organization: Virtual Technologies Inc.
Date: Sat, 7 Nov 1992 13:30:28 GMT

In article <30138@nntp_server.ems.cdc.com>, tbruseha@hollywood.ems.cdc.com (Tom Brusehaver) writes:
> I am porting some code, and I wish I could rewrite it, but I can't.  I
> need a tool to to debug malloc on an RS/6000.  I know there are Sun
> versions around (one is included in the pre-Solaris OS's).  I need an
> RS/6000 tool that will catch errant pointers before they crash my
> program.

Our product, SENTINEL, is such a tool and is currently in beta for the RS/6000.
Send email for more info.


-- 
*** SENTINEL(tm) The ultimate Debugging Environment - email for more info ***

Conor P. Cahill              (703)430-9247            cpcahil@virtech.vti.com
Virtual Technologies, Inc.  46030 Manekin Plaza          Dulles, VA 20166 
Newsgroups: comp.lang.c
From: nagel@kithrup.Irvine.CA.US (Mark D. Nagel)
Newsgroups: comp.lang.c
Subject: constant-expression
Date: Tue, 10 Nov 92 08:34:28 PDT
Reply-To: nagel@Kithrup.Irvine.CA.US
X-Mailer: uAccess - Macintosh Release: 1.6v1

I checked the FAQ and found not a clue to the following question.

Given an array declaration like:

const int foo[] = { 1, 45, 67, 4 };

why is the following code rejected (it is in MSC 6.0 at least)?

switch (integer_variable)
{
	case foo[2]:
		...
		break;

	...
}

I gather that the ANSI standard says that the indexing operation makes
the expression not a constant-expression, but it seems that a compiler
should be able to deal with this.  I could understand if the case
contained something like foo[i], but it doesn't.


-------------------------------------
Mark Nagel <nagel@mdn.uucp>

If at first you don't succeed, that's pretty much it.
				-- SDI Design Team
Xref: sparky comp.lang.c:16433 comp.software-eng:4260
From: nsridharan@faois.intel.com (Sridharan)
Newsgroups: comp.lang.c,comp.software-eng
Subject: Re: Will we keep ignoring this productivity issue?
Date: 13 Nov 92 02:16:32 GMT
Organization: Intel MST
X-Useragent: Nuntius v1.1

In article <BxKEv9.4K8@cs.uiuc.edu> Rob Hasker, hasker@cs.uiuc.edu writes:
>On what sorts of projects?  While there might be a difference for small
>projects, it certainly wouldn't be clear that there would be a
>difference for large projects.  Besides, there might not be enough
>"very good" people in your neighborhood to do a large project.  So you
>get the job done with the people on hand.  (And don't most companies
>promote the successful developers to management where they can't do
>this sort of work?)

Ahem ... the project wouldn't BE BIG if you used the "very good" people, would
it?

Try a hypothesis:  What if .. just what if .. the famous 80-20 rules works.
Examples: 80 percent of the function comes from 20 percent of the code
	80 percent of the value comes from 20 percent of the effort
	80 percent of the result comes from 20 percent of the people (in a large
project)
	and etc etc
So, if an ordinary programmer is a slave to the ordinary world
and if a talented programmer understands how to apply the 80-20 rule and can
get 80% of the most valuable work done in 20% of the effort; and  
if a "gifted" programmer is one who can apply the 80-20 rule twice over - and
can get
64% of the value with only 4% of the effort
- Would this account for the variability in productivity?

Since the argument is generic - you might say why then don't we see the same
in carpentry or shoe repair.  Aye, then , the subject matter is not so ELASTIC
and one cannot effectively do much in that subject.

Comments?