Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!samsung!usc!elroy.jpl.nasa.gov!ncar!noao!arizona!dave
From: dave@cs.arizona.edu (Dave P. Schaumann)
Newsgroups: comp.software-eng
Subject: Re: Effect of execution-speed on reliability/testing
Message-ID: <654@caslon.cs.arizona.edu>
Date: 13 Jan 91 18:12:52 GMT
References: <1990Dec19.102005.11830@engin.umich.edu> <470@eiffel.UUCP> <1047@gistdev.gist.com> <15809.278a0d04@levels.sait.edu.au> <12212@pucc.Princeton.EDU> <1991Jan12.093726.4935@metapro.DIALix.oz.au>
Organization: U of Arizona CS Dept, Tucson
Lines: 53

In article <1991Jan12.093726.4935@metapro.DIALix.oz.au> bernie@metapro.DIALix.oz.au (Bernd Felsche) writes:
>In <12212@pucc.Princeton.EDU> EGNILGES@pucc.Princeton.EDU (Ed Nilges) writes:
>
>[.. notes about "CORRECTNESS" deleted ]
>>                               ...   As to speed, you shouldn't even
>>worry about it until you have a correct program, and ....
>
>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.
>
>As with all engineering problems, there is always more than
>one solution to a problem.  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 would have to disagree.  In a situation where there you have no deadline for
completion, you might be able to do this.  You might never finish, too.  In the
real world (even in school) you have intense pressure to get it done.
A bubble sort that works now is better than a heap sort (or maybe a quick sort?
or maybe some other sort?) that will work in a month or a year.  (Yes, I
realize this is a contrived situation).

Writing good code involves a thorough understanding of the problem.
Unfortunately, you don't really have a complete understanding of a
(non-trivial) problem until you've written a program for it.  It's been my
experience that the best way to write programs is to use 20-20 hindsite --
that is, write something that works, look at it, and say "how can this be made
better?"

If you try to see the best solution without writing any code, you could get
hoplessly mired in your problem.  How do you know you have the best solution?
You really can't know how good a piece of code is until you see it in the
context of the rest of the program.  Maybe you'll discover you will never need
to sort more than 10 items, in which case a bubble sort will be perfectly
adequate, and using a O(nlogn) sort would be overkill.

>Far too much code gets generated which produces the "right" numbers,
>but takes forever to crunch.  Some more thought about the problem,
>before the keyboard got bashed, would have revealed much more 
>efficient and manageable code, giving results in a far shorter time.

I agree that it is easy to implement the first thing that pops into your head.
Thinking about different ways to approach a problem is a Good Thing.  But
searching for *the best* solution before you write any code is impossible.

>______________________________Bernd_Felsche______________________________
>Metapro Systems, 328 Albany Highway, Victoria Park Western Australia 6100
>Phone: +61 9 362 9355   Fax: +61 9 472 3337   bernie@metapro.DIALix.oz.au

Dave Schaumann      | We've all got a mission in life, though we get into ruts;
dave@cs.arizona.edu | some are the cogs on the wheels, others just plain nuts.
						-Daffy Duck.