Where would you like to spend that resource? (WAS: yup!)

Uh-oh, I feel another soapbox sermon coming on. Feel free to run away
while I put on my stiff white collar and rile the crowd with a cries of
zealotry. Ok, now that I've self-selected the audience to the few truly
faithful and confused, here goes...




wulf@capa.cs.Virginia.EDU writes:
>[The person who wrote
>
>> I'll give up substantial speed even in the final product to gain
>> productivity
>
> is missing the point. S/he doesn't have to give up *anything*,
> his/her customer does. The customer is giving up either
> functionality or the ability to use the left-over resources.]


Perhaps I am missing the point. I say many things and I'm often
convinced otherwise after I've said them. I think it's called
``getting an education'' :-)


Still, the world in which I live has products that come out after
deadline and with bugs. By design or accident, most of the machines I
run on have spare cycles most of the time. I like programs that are
fast, but I especially like programs that are correct.


Note: I'm not making any argument about *optimizers*, I'm expressing an
opinion about the (lack of) necessity of speed.


I've used lots of programs that broke when I used them. Why? Becasue
I typed ``supercalafrajalisticexpialdocious'' (to quote Henry Spancer)
where the original author typed ``foo''. The original programmer used
(for example) an unchecked reference in to a fixed-size array rather
than the (less-efficient) checked reference in to a resizable array.


Yes, the programmer *can* write the checked version -- I do it all the
time. But the programmer on a limited time budget may well choose code
that runs quickly and incorrectly. I've seen it far too often. ``We''
the tool designers could instead shift the emphasis and provide also
easy-to-write constructs that give checked/reallocatable array access.
Using them blindly may cause the program to run a factor of two slower
than arrays that are checked only when absolutely necessary, but the
programmer's keystrokes and coding time are cut and productivity
increased (this is an opinion, not a statement of True Fact). If the
programmer has time left over, there's always room for tuning. If
there isn't -- and there never is :--) the customer is trading their
CPU cycles for a program with improved functionality and/or fewer bugs.




To summarize: the computer is only one of the finite resources. In the
idea/design/build/ship/use/maintain cycle, the majority of the CPU
cycles *are* spent in the `use' phase. But sometimes it's worth (IMHO)
trading some of those cycles for the finite resources of the programmer
in order to get more reliable or better-featured code.




I've also got a bug to sell you and in the meanwhile, I'm running out
of soap, so I'll go now!


;-D oN ( The augmented argument ) Pardo
--

Return to the comp.compilers page.
Search the comp.compilers archives again.