Path: utzoo!mnetor!uunet!husc6!psuvax1!burdvax!sdcrdcf!trwrb!aero!venera.isi.edu!raveling From: raveling@vaxa.isi.edu (Paul Raveling) Newsgroups: comp.software-eng Subject: Re: A Cynic's Guide, part 1 Message-ID: <5019@venera.isi.edu> Date: 12 Mar 88 04:12:47 GMT References: <2541@Shasta.STANFORD.EDU> <5313@utah-cs.UUCP> Sender: news@venera.isi.edu Reply-To: raveling@vaxa.isi.edu (Paul Raveling) Distribution: na Organization: USC-Information Sciences Institute Lines: 37 In article <5313@utah-cs.UUCP> shebs%defun.utah.edu.UUCP@utah-cs.UUCP (Stanley T. Shebs) writes: > >All three of these approaches in the software realm fall victim to the same >concern: efficiency. This is partly a legacy of the 50s, when the self-taught >programmers of the time were willing to do *anything* to squeeze out a few >more cycles or a few words of memory. It was OK to violate any abstraction >or to use any quirk of the system. ... There's another side to this coin. What I see now is lots of software being written without regard to performance. Squeezing every ounce of speed and size out of the code made sense when (for example) my time cost a princely $3.08/hr and the machine cost $125/hr. But those old machines taught us that efficient algorithms were a bigger win than efficient code. They forced us to learn good habits in both algorithm design and optimal coding. We had to do so much "optimal coding" that it was quite painless to abandon it when machines grew enough to eliminate the need. Now I see lots of software being put together with minimum implementation time as its sole goal. Yes, we have lots of uncommented Lisp. The benchmarks show it runs about 3 times slower than C, which is about 3 times slower than machine language. All that runs over an operating system, Unix, which switches contexts an order of magnitude slower than some other systems. ... and one of us (not me) wonders why his "high-tech" workstation has worse response time than his PC at home. --------------------- Paul Raveling Raveling@vaxa.isi.edu