Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!spool2.mu.edu!uwm.edu!bionet!agate!ucbvax!cs.hull.ac.uk!rst
From: rst@cs.hull.ac.uk (Rob Turner)
Newsgroups: comp.software-eng
Subject: Re: Effect of execution-speed on reliability/testing
Message-ID: <16514.9101161849@olympus.cs.hull.ac.uk>
Date: 16 Jan 91 18:49:36 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 53

Bernd Felsche writes:

>I beg to differ! I don't believe one line of code should be
>written until the most efficient method of calculating the
>correct result has been determined.

If we take this to extremes, no software would ever get written, as
for most problems there is no way of knowing whether you have the
"most efficient" (whatever that means) method of solution.

> ... If you don't seriously consider at least
>half a dozen significantly different ones, then you are doing
>yourself and your client a dis-service.

I'm not sure where you picked up "half a dozen" from, but I generally
agree with this. The number of possibilities must change considerably
from problem to problem, though.

>I have seen code to drive graphics displays, which used trig
>functions to compute pixel positions for drawing circles.

This is an interesting example. For graphic displays, speed is of the
essence (far more so than most pieces of software), so you should be
looking at the fastest answers even though it might mean not many
people can understand your code. I suspect "software engineering"
flies out of the window for tasks such as drawing circles. It only
gets applied at the higher levels like designing window managers.

You have to work out the time it would take you to work out all the fancy
algorithms for plotting circles, against the trigonometric solution,
which requires virtually no thought, as most people are aware of the
equations for drawing circles.

In a given time, more (admittedly slower) software will be written if
you choose the conventional, well-known or obvious techniques rather
than spending a lot of time making software which doesn't need to run
fast go like a bullet. The software will also be easier to understand.
The choice is yours.

With the advent of large software engineering environments, the
implementation of a lot of programming tasks is being taken out of the
hands of the programmer. People have been saying that we need code
reusability, and they have to realise the consequences. The
consequences are that half (could be any proportion, actually) the
code in your program will not have been implemented by you. You then
have to hope that the person who *did* code it made it fast enough for
your requirements. To make things worse, I suspect that most of the
code that already exists as libraries (or any fancy name you like)
within the environment will be very general purpose code (i.e. slow)
by definition, as it is going to be used in a lot of different
situations.

Rob