Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!ima!bbn!rochester!crowl
From: crowl@rochester.UUCP
Newsgroups: comp.lang.misc,comp.software-eng
Subject: Re: Software Technology is NOT Primitive
Message-ID: <3671@sol.ARPA>
Date: Wed, 28-Oct-87 15:19:34 EST
Article-I.D.: sol.3671
Posted: Wed Oct 28 15:19:34 1987
Date-Received: Sat, 31-Oct-87 08:43:04 EST
References: <3405@ece-csc.UUCP> <638@its63b.ed.ac.uk>
Reply-To: crowl@cs.rochester.edu (Lawrence Crowl)
Distribution: comp
Organization: U of Rochester, CS Dept, Rochester, NY
Lines: 56
Xref: utgpu comp.lang.misc:774 comp.software-eng:18

In article <4943@ncoast.UUCP> crds@ncoast.UUCP (Glenn A. Emelko) writes:
>In those rough times [of 16K memory], people were very concerned and concious
>about storage, both on disk, as well as memory usage.  This forced software
>engineers to think creatively, to tighten code, and to produce very powerful
>LITTLE algorithms that could do many things and could be called from many
>other parts of the code.

It also forced them to spend a lot of money achieving these goals.

>Code was many times designed to be recursive, if not reentrant, and it was
>expected that the software engineer knew alot about the machine and
>environment (in terms of the hardware) that was hosting the program, which
>allowed for tricks and little magical wonders to happen (laughing, in other
>words, the designer took advantage of what was available).

It also make anyone else maintaining or porting the program spend weeks (read
thousands of dollars) just trying to understand a small program in order to
accomplish the task.

>In contrast, today, many designers know nothing about the destination machine
>(it's a UNIX box?), and most are not very concerned about how much memory,
>disk space, or anything else that they use, and really could care less if
>there are four subroutines in their code which could be combined into one
>general purpose all encompasing sub.

The also produce a functionally equivalent program in far less time which is
available on far more machines.  (Boss, I can spend eight more weeks and double
the speed of program.  Of course, then it will only run on the 40 or so
machines which are exactly like our development machine.)

>In fact, I have noted many specific cases of generally sloppy, slow, and
>out-and-out crude coding techniques passing as "state of the art," simply
>because it is running on a machine that is so blindingly fast that it does
>make that code seem reasonable.

Not fast, cheap.

>Yes, I am talking about the "most popular" spreadsheet of 1984, and a lowly
>Z80 machine ripping it to shreads [speed-wise]!  Is this the current state of
>software technology?  Yes, I believe so.

Which goes to show that raw performance is not highly valued by customers.

>We have software today which can probably be out-run by the software of 1978,
>even when we use it on that powerful processor.  Sure, it's USER FRIENDLY,
>ERGONOMIC, etc., but does it keep pace with the advances in the industry?

Raw speed is only one aspect of advances in the industry.  Hardware
concentrates on speed while software concentrates on functionality.  (Mr.
Customer, I am giving you a fast sort, but I do not have time to implement
a backup utility.)

-- 
  Lawrence Crowl		716-275-9499	University of Rochester
		      crowl@cs.rochester.edu	Computer Science Department
...!{allegra,decvax,rutgers}!rochester!crowl	Rochester, New York,  14627