🚀 go-pugleaf

In article <Snews.960814.195625.chris.1268@keris.demon.co.uk>
           chris@keris.demon.co.uk "Chris Croughton" writes:

> In article <839979287snz@wash.demon.co.uk>
>            ka9qwww@wash.demon.co.uk "John Washington" wrote:
> 
> >It's a tad over 2K now, that's the trouble with 'development'.  :-)
> 
> I can never remember, is a 'tad' bigger or smaller than a 'smidgeon'
> <g>?

Tads are most definitely bigger than smidgeons:

A 'tad' over the original spec implies a *noticeable* increase
in size (I'd guess around 10% in most cases), whereas a smidgeon 
is of no real consequence (save that it might encroach on the 
next cluster on your disk, thereby wasting most of it).

More often than not, tads can be reduced to smidgeons by careful 
optimisation and/or removing a 'frill' or two (though it must be 
said that some frills take up far more memory than can really be 
justified by function).  Equally, smidgeons can be made to 
disappear by the same method (though only *original* smidgeons: 
the only way to get rid of smidgeons that were originally tads is 
by resorting to direct OS calls or assembler).

Tads (Technically-unavoidable ADditions) often arise due to 
over-optimism on the part of the programmer.  And let's face it: 
one has to be optimistic to be a programmer - if we didn't 
believe that our latest creation would compile and run 
(error-free) first time, we'd give up, right?

Smidgeons OTOH (SMall Increases Due to Generalised Encoding, 
Optimised Not-a-lot) are normally down to inadequacies of the 
compiler, though can be caused by inelegant code construction.  
And since this latter is impossible to contemplate, one has the 
choice of changing compiler (not usually viable) or resorting to
the introdution of non-portability (as mentioned above).

Sorry - can't keep a straight face any longer <Broo-Ha-Ha-Ha!!>
It's been a long week....
-- 
Pete