This is getting a little off topic, but I think OpenPGP has a
programming philosophy of elegance and simplicity, so it isn't too far
off. So I apologize in advance but will still respond ;).
On Fri, Jul 21, 2000 at 10:14:32AM -0400, Paul Koning wrote:
"Tom" == Tom Zerucha <tz(_at_)execpc(_dot_)com> writes:
Tom> On Thu, Jul 20, 2000 at 11:22:37AM -0700, hal(_at_)finney(_dot_)org
wrote:
>> > balance sheet > > value of 1.6 G bytes > ($200 IBM 20Gb drive,
>> y2k) $12 > > value of 50 hours programming > ($100 per hour, y2k)
>> $5000 > > net gain (loss) to society > from the Zimm Buddism >
>> ("every byte is sacred"): ($4988) > > The 2nd millenium is over.
>> Save programmers, not bytes.
>>
>> This is a misleading comparsion. There are circumstances where
>> bytes can be extremely costly, such as in the new wave of wireless
>> devices, smart
Tom> You miss the biggest point.
Tom> Value of 50 hours programming - $5000.
Tom> value of 0.6 Mb (I assume this is the number) - $12 PER DRIVE.
Um, no.
Right now drives are about $10 per GB. So 0.6 MB cost less than a
penny. It takes nearly a million drives to break even.
And it drops each year. Just wait and we will all have 10GHz
processors with a terabyte drive connected by high speed optical...
The cost of Palm RAM is around $4000/GB. And it doesn't have a hard
drive port. The cost of extra kilopackets on the VII if you don't
have unlimited is quite high.
If you want to embed something in 1M devices, the difference between a
$15 and a $20 chip will pay for a lot of engineering time.
In one sense your argument says that the US cars of the late '60s and
early '70s were optimal because steel and fuel were cheap and getting
cheaper, so 4-5K pounds wasn't a problem and maybe an asset in an
accident.
Not only that, but the cost of extra programming is not just time
spent, but also quality reduced, which can be a lot more expensive.
This assumes it reduces quality. Normally collapsing a complex (and
big) interface into something which is both smaller and simpler
increases quality.
In my experience, the number of bugs is inversely proportional to the
complexity of the system, and simple systems don't produce a lot of
extra bytes.
In the original context, I think the argument was "We could add this
feature although it will take extra memory". Arguing your point, we
shouldn't add such extra features because the cost won't simply be the
extra memory, but the programmer, tester, and fixup time due to bugs
or other incompatibilities said feature would introduce.
Also, such things tax other programmers who want to interface with the
software. That extra byte might cause hundreds of other programmers
hours of grief.
In fact, if it introduces just one more bug that causes 1% of the
users $1 worth of extra hassle, you've already paid for the extra
bits.
There is a point of diminishing returns, but I know of very little
software that isn't 60% extra junk and gratuitous changes when new
versions come out with all the problems you note - and I am not even
talking about actual bugs. Bloat is something that is anti-quality -
more interfaces, more code, more structures, more bytes that can be
misinterpreted.
Most of this applies to W32, less so for Mac, far less for Unicies
where you get complaints about being too simplistic to be usable.
The desire to reduce memory requirements is an indirect way to prevent
bloat, and as such is probably inefficient or even wrong in some cases.