MDAY@XX.LCS.MIT.EDU.UUCP (11/02/87)
Soft-Eng Digest Sun, 1 Nov 87 Volume 3 : Issue 15
Today's Topics:
Usenet Discussions (Overview)
Software Technology is NOT Primitive (14 msgs)
----------------------------------------------------------------------
Date: 01 Nov 87 18:12:32 EST
From: Mark S. Day <MDAY@XX.LCS.MIT.EDU>
Subject: Usenet Discussions (Overview)
I have attempted to summarize for the digest a number of messages that
fell out of a discussion of software technology's apparent failings
compared to hardware technology. The last issue of the digest dealt
with a series of complaints about current languages and their
failings. This issue returns to the subject of whether software
technology is "primitive."
As before, there are two phenomena of Usenet discussions that I have
tried to edit out. One is the "me too" message where someone adds a
small delta to the discussion without really making any significant
point. The other is the "interruption" style of arguing a case, where
a previous message is dissected sentence-by-sentence, with various
comments as interruptions of the original text.
--Mark
------------------------------
Date: 25 Oct 87 18:55:02 GMT
From: cunyvm!orion.bitnet!ken%psuvm.bitnet@ucbvax.Berkeley.EDU (Kenneth Ng)
Subject: Software Technology is NOT Primitive
Shouldn't you be taking the software program as a whole and the hardware
as a whole? Saying the hardware today is just an ALU, registers and
memory is like saying all of today's software is an assignment, compare
and branch statement. To compare your description of software today to
hardware today, try adding LRU caching, address lookaside buffers,
I/O processors, massive error detection and correction logic, ethernet
and other communication technology, paging, the entire virtual memory
schemes on a lot of machines, etc., etc, etc.
Kenneth Ng: ken@orion.bitnet
------------------------------
Date: 26 Oct 87 15:27:02 GMT
From: decvax!ima!haddock!stevel@ucbvax.Berkeley.EDU (Steve Ludlum)
Subject: Software Technology is NOT Primitive
Hardware doing the same thing faster? Parallel processors are not just faster
they are different. Symbolic machines use different hardware techniques, i.e.
tags. Laser disk do simply store more information but the difference means
much more than just being able to do more of the same thing. Specialized
hardware designs such as DSPs are opening up new areas such as speech and
vision automation, oh and don't forget those little network controllers
on a chip.
Anyway all of the progress in software has just been taking care of a
few more special cases :-)
ima!stevel
------------------------------
Date: 27 Oct 87 04:22:44 GMT
From: pyramid!weitek!rober@hplabs.hp.com (Don Rober)
Subject: Software Technology is NOT Primitive
When was the last time you wrote a Data Management System; or a spreadsheet
program; or a transcendental package; or a compiler, linker, etc?
When was the last time you wrote a mail package from scratch, a grep program
and all of the other UNIX utilities?
WHile there is a long way to go, I think if you look at it, we've done okay.
Don Rober UUCP: {pyramid, cae780}!weitek!rober
Weitek Corporation 1060 East Arques Sunnyvale, CA 94086
------------------------------
Date: 27 Oct 87 13:17:12 GMT
From: cbosgd!osu-cis!tut!tut.cis.ohio-state.edu!mumble%karl@ucbvax.Berkeley.EDU (Karl Kleinpaste)
Subject: Software Technology is NOT Primitive
crds@ncoast.UUCP writes:
We have
processors today which can out-run the processors of 1978 (10 years
ago) by 20 to 1. 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? Why don't I
see ANY software advances that are even an order of magnitude above
1978? This would give me 200 times the power, considering the
advances in hardware!!
In watching this discussion, it seems the only metric which people
want to apply to software is performance. Raw performance, how many
widgets can you prefrobnicate in minimal picoseconds. It seems to me
that this is not the right way to view software.
Aside from the fundamental problems of P?=?NP and similar questions, I
tend not to like looking at software from the sole standpoint of how
fast it goes. Yes, speed is important - anything written by a
programmer should be designed to be fast, as fast as possible. I
think I do much more than an adequate job of that in the code I write.
But I am not looking for pure speed in what I design; I am also
looking for new functions, new capabilities, a different way of doing
something, a different way of looking at an old problem.
Consider the case of bit-mapped window displays. The hardware to
implement them is relatively simple. A largish memory, an ability to
move large bit patterns fast, possibly a dedicated co-processor for
managing the whole beast. The rest is software. I think this is an
excellent example of a wonderful marriage between advances in hardware
and software. Hardware provided the ability to do something in new
software. The new software provides new capabilities and new power
for the user of the whole package.
Now consider the resulting power of that package. I'm sitting in
front of a Sun3 using X. The hardware provided here is exactly what
is needed to support the software concepts required. But to me, the
resulting power of this box is really embodied in what the software is
doing. On my screen right now, there are 10 windows. All of them are
doing useful things. Granted, some of them are not doing very
interesting things; I have an analog clock in one corner, and two load
meters in another. But that still leaves 7 other windows doing real,
vital, practical work. Even those two load meters are vital to my
work, because it's those meters that I will be watching to see if
something causes a performance spike, and that will cue me to go look
at the indicated system to see what's going wrong. So in practical
terms, I have 9 simultaneous activities going on which are of value to
me.
That's roughly an order of magnitude improvement over the days of
1978, when I sat in front of a dumb CRT, connected to exactly one
system, doing exactly one thing. The parallelism inherent in my brain
is being put to positive use. I didn't even need parallel hardware to
do it. An approximation of parallelism through timesharing is
sufficient for my mind to fill in the remaining gap.
I am not attacking or denigrating the advances in hardware in any way
whatever. (My graduate work was in software performance increases,
after all, trying to take better advantage of existing recent hardware
improvements.) But I think that software has come rather a long way
in the last 10 years. It just hasn't come to us in terms of raw
performance. It's exactly those areas of user-friendliness,
ergonomics, and expanded user capability that provide the final
improvement in the real power of the machine.
-=-
Karl
------------------------------
Date: 26 Oct 87 12:19:34 GMT
From: cbosgd!mandrill!hal!ncoast!crds%ncoast.UUCP@ucbvax.Berkeley.EDU (Glenn A. Emelko)
Subject: Software Technology is NOT Primitive
I have been involved at an engineering level in both hardware and software
design for about 10 years. Across these years I have seen advances in both
industries, but I must say that I am more impressed with what I see in the
way of hardware technology. In some ways, it seems, software has degraded
somewhat because of hardware progress. This has been, and most likely shall
continue to be one of my pet peeves of the whole industry.
First of all, I can remember (as many of you can too) machines which had 4K
of memory, or 16K, and still had to have a rudimentary OS running which could
perform some tasks and still allow the user to load a program. In those rough
times, 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. 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). 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.
Further more, it seems, now that we have 3-MIPS and 5-MIPS and higher-MIPS
machines being sold over the counter at reasonable prices, very little time
is spent by the software engineer to really PUSH that machine to it's gills.
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. Case and point: I can recall designing a
sorting algorithm for a data management system which was very popular in the
early '80s for a specific Z80 based computer, and then one day pulling out
a copy of the "state of the art" data management/spread sheet program of '84,
which ran on a 8088 based system, and benchmarking them against each other
for about 20 different test cases (already sorted, sorted reverse, alpha only,
numeric only, fractional numbers, alpha numerics, and numerous data sets),
and watching the Z80 based computer beat the 8088 based system 10 to 1 at
WORST! And as an added note, the sort on the Z80 was stable, and the one
on the 8088 was not!!! Yes, I am talking about the "most popular" spreadsheet
of 1984, and a lowly Z80 machine ripping it to shreads! Is this the current
state of software technology? Yes, I believe so.
At the same time that I have shared these "beefs" about software development,
I have mentioned advances in hardware which allows the software guru to get
lazy and still be considered current. We have processors today which can
out-run the processors of 1978 (10 years ago) by 20 to 1. 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? Why don't I see ANY
software advances that are even an order of magnitude above 1978? This would
give me 200 times the power, considering the advances in hardware!! I would
like to get my hands on a copy of "current software" which shows me this
capability, please email me info, or respond on the net.
Yes, these opinions are specifically mine, and reflect upon nothing other than
my own personal experiences, pet peeves, and general bullheadedness. Feel
free to differ with any or all of the above, but at least get a laugh out of
it. I find it funny myself.
Glenn A. Emelko
...cbosgd!hal!ncoast!crds
Somehow, this borrowed caption seems appropriate:
"When I want your opinion, I'll give it to you."
------------------------------
Date: 28 Oct 87 17:54:16 GMT
From: sunybcs!sher@ames.arpa (David Sher)
Subject: Software Technology is NOT Primitive
(Followup's to comp.lang.misc)
Time for a stupid analogy:
Someone gives me a 2 watt power line and asks me to build a toaster:
So using my electronics ability and ingenuity I build a toaster that
toasts a piece of bread that was very carefully placed in it in about
15minutes.
However things advance and he now hands me a 2 Megawatt power line
and says ok buid me a toaster, and I throw together a toaster that
toasts bread in about 1 minute. (The most work going into making sure
the user does not electrocute himself.) He then comes back and complains,
I gave you a million times as much power and you only give me a factor
of 20 speedup! Power engineering sure advances faster than electrical!
Disclamer: As should be obvious by now, I know nothing about constructing
appliances. This story is not true, and the names have been changed to
protect the innocent and all that stuff.
-David Sher
ARPA: sher@cs.buffalo.edu BITNET: sher@sunybcs
UUCP: {rutgers,ames,boulder,decvax}!sunybcs!sher
------------------------------
Date: 27 Oct 87 16:54:08 GMT
From: uplherc!esunix!bpendlet@gr.utah.edu (Bob Pendleton)
Subject: Software Technology is NOT Primitive
Why compare hardware and software at all? Its like comparing roads and cars.
Cars even run on roads, much like software runs on hardware. ( Forgive the
awful analogy. It is deliberately obsurd. ) Even though they affect each
others development, the technologies are very different.
Look at LRU caching and paging. This technique depends on a statistical
property of programs in general, but to get maximum performance from a
given machine a programmer needs detailed knowledge of its implementation
on that specific machine.
Two very different technologies. Two very different points of view.
Two different cultural heritages.
Bob P.
--
Bob Pendleton @ Evans & Sutherland
UUCP Address: {decvax,ucbvax,ihnp4,allegra}!decwrl!esunix!bpendlet
Alternate: {ihnp4,seismo}!utah-cs!utah-gr!uplherc!esunix!bpendlet
I am solely responsible for what I say.
------------------------------
Date: 29 Oct 87 04:59:41 GMT
From: ken@cs.rochester.edu (Ken Yap)
Subject: Software Technology is NOT Primitive
Let us not forget that the computer is a tool and that raw computing
speed is but one measure of the effectiveness of the hardware. If that
computing power has to "go to waste" in a spreadsheet program, I don't
care, as long I get *my* job more effectively. All those cycles going
into painting a bitmap window, think it's a waste? Fine, want to design
METAFONT characters with punch cards, or even a glass TTY?
I used to wonder what we would do with all those MIPS of computing
power hardware would give us. Now I realize that there is at least one
application that can soak up any amount of CPU power you can get -
advanced interfaces. Have a look at the October SciAm issue. Take the
Wired Glove. Imagine a biochemist being able to experiment with
molecules by "handling" them. Would you begrudge all those cycles
required to support this mode of interaction? I certainly wouldn't.
Ken
------------------------------
Date: 29 Oct 87 20:56:15 GMT
From: ihnp4!ihlpf!joelynn@ucbvax.Berkeley.EDU (Lynn)
Subject: Software Technology is NOT Primitive
Having programmed on the old Z80 based TRS80 with 4k and then 16k to work on,
I have just gotten tired of trying to keep up with the hardware.
It seems the more I learned about the machine's capabilities, the faster
the machine changed. The sooner my programs became obsolete. I just
got tired of relearning a new operating system to find it out of date in
a couple short months. For this reason, I welcome UNIX.
BUT...
I have been handicapped by UNIX simply because it cannot use the total
environment available to it. This, i think is due to the inability
of the current generation of programmers to look at the whole picture
of what is to be done, and what may be requested of the routine.
------------------------------
Date: 29 Oct 87 12:23:18 GMT
From: pur-phy!hal@ee.ecn.purdue.edu (Hal Chambers)
Subject: Software Technology is NOT Primitive
In article <4943@ncoast.UUCP> crds@ncoast.UUCP (Glenn A. Emelko) writes:
>... I can recall designing a
>sorting algorithm for a data management system which was very popular in the
>early '80s for a specific Z80 based computer, and then one day pulling out
>a copy of the "state of the art" data management/spread sheet program of '84,
>which ran on a 8088 based system, and benchmarking them against each other
>for about 20 different test cases
>and watching the Z80 based computer beat the 8088 based system 10 to 1 at
>WORST!...
This reminds me of a time about 10-12 years ago when I was using a program
which looked for new energy levels in an atom given a list of known levels
and a list of currently unclassified spectrum lines for that element.
This program generated huge lists of numbers which then had to be sorted
and then examined for matches. The program ran the the CDC6600 here at
Purdue and took large amounts of time which meant: submit job wait till
next day for results. I examined the sort routine which was written in
COMPASS (the CDC assembly language) for "speed".
What a revelation when I realized the algorithm used was a Bubble sort!!
I wrote a modified Shell-Metzner sort in FORTRAN and got a 30-fold
improvement. Then I hand-compiled that subroutine into COMPASS and
got another factor of 3 improvement. Those jobs now run in less than
8 sec. of processor time and turn around is essential immediate.
Hal Chambers
------------------------------
Date: 29 Oct 87 11:51:56 GMT
From: mcvax!ukc!stc!praxis!gauss!mct@uunet.uu.net (Martyn Thomas)
Subject: Software Technology is NOT Primitive
I don't understand the comparisons which are being made between hardware and
software technology - they seem to be comparing the wrong things.
The advances in hardware technology are advances in *fabrication* technology
mostly. The feature sizes get smaller, the substrates can be grown with
fewer impurities, the masks can be drawn more accurately. There are few
useful analogues of this in software.
Software is design, in a pure form. The *design* technology of hardware, at
the logical, behavioral level rather than the physical place-and-route, is a
long way behind software - mostly because the complexity of most hardware
designs is relatively low. (This is changing rapidly, as 100K+
gate-equivalent ASICs become more common). Surely a reasonable comparison
would be:
HARDWARE SOFTWARE
Schematic capture Flowcharting
Gate-level design Assembly-language programming
Most HDLs FORTRAN
ELLA/VHDL Modula 2 / ADA (Don't take this too
seriously - these
are not really close enough
to compare).
LCF/LSM VDM or Z or CSP ie formal methods.
The main weakness of this sort of comparison is that the design problems are
different, and that there is no agreed taxonomy of software design
techniques. The table above is *not* a linear progression from
less-advanced to more-advanced, it is rather an unstructured, pairwise
comparison of different aspects of hardware design technology with rough
software equivalents.
In general, hardware designers are using only limited "structured methods"
(to use a software phrase) and almost no (mathematically) "formal methods".
There are notable exceptions: in the UK, Inmos are using CSP and OCCAM to
prove the correctness of transputer components; RSRE (UK MoD) are using
LCF/LSM to prove the correctness of VIPER, their formally-verified 32-bit
microprocessor; and increasingly other companies are learning the benefits
of a (more) formal approach to design. Such methods are in much more
widespread use for software development, and the corresponding research
papers were published about ten years earlier for software.
The hardware designers are catching up fast, though, just in time to merge
their skills with the software engineers' to make a new breed of systems
engineer.
Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK.
+44-225-444700. ...!mcvax!ukc!praxis!mct OR mct%praxis.uucp@ukc.ac.uk
------------------------------
Date: 30 Oct 87 21:13:41 GMT
From: uh2%psuvm.bitnet@ucbvax.Berkeley.EDU (Lee Sailer)
Subject: Software Technology is NOT Primitive
Twenty years ago, writing a Pascal compiler, a Basic interpreter,
a screen editor, a mail package, a text formatter, etc etc etc, was
considered a MAJOR project.
Today, any of these would be considered a stiff challenge for a talanted
college senior. Why? Because techniques and strategies in Software
engineering have changed, changed a lot, and changed for the better.
I agree. We've done OK.
------------------------------
Date: 31 Oct 87 16:58:41 GMT
From: tektronix!reed!bart@ucbvax.Berkeley.EDU (Bart Massey)
Subject: Software Technology is NOT Primitive
Probably I shouldn't add to this discussion, since it seems to be basically
going nowhere. But I couldn't resist putting in my 2-cents-worth...
The arguments being presented for primitive software technology,
as I have interpreted them, are these:
Hardware designs have gotten more general-purpose and reusable in
the past 20 years. Software designs haven't.
Hardware has gotten more much more efficient wrt speed and size in the
past 20 years. Software has gotten less efficient in that time.
Seems to me that the most reasonable lines of counter-argument runs
like this:
Hardware costs money to manufacture. If a sufficient number of copies
of a design are sold (as with ICs) the manufacturing costs swamp the
design and distribution costs. This isn't true of software. An infinite
number of copies may be manufactured for free, and design costs are
generally the constraining factor. Thus, much more design effort is put
into a typical hardware project. On the other hand, many more software
designs are actually implemented. This is why hardware is used for
general-purpose tasks, and software for specific problems. The
major task of the hardware designer has been to do general-purpose tasks
faster and smaller, at which s/he has succeeded admirably. The major
task of the software designer has been to do a wide variety of specific
tasks, at which s/he has also suceeded admirably.
It just isn't true that our knowledge about how to do small, fast
software has *decreased*. Anyone who believes this should look at the
original 64K Apple Macintosh ROMs. Certainly, the coding there was in
the same range of size/speed efficiency as the 4K Tiny Basic I used 10
years ago. And yet there was 16 times as much of it. What has happened
is that run-time efficiency has been traded for design-time efficiency.
At Reed College, there is an abundance of machines, and a major
shortage of programmers. Thus, we try to use the programmers
efficiently, not the machines. Contrary to some people's claims, we
believe that there's no way to optimize both simultaneously. Always
choosing the people optimization makes good economic sense for us.
And for most people.
In summary, 20 years ago, you couldn't do a lot of things, period. The
things you did do, you did almost solely in hardware. Today, a mixture
of general-purpose hardware and specific-purpose software is being used
to do a lot of new things more cheaply and easily.
My personal opinion based on the above evaluation is that name-calling
software technology "primitive" or "20 years out of date" is a little silly.
Suggesting specific ways that either sofware or hardware technology could be
improved is not. The recent discussions in this group about the extent to
which compiler syntax can reasonably be modified at run time, about the ways
in which languages can be optimized to make code-sharing easier without
significantly increasing design expense, about the costs and benefits of OO
programming, seem much more relevant and useful. Let's take up those
topics and drop this one.
Bart
------------------------------
Date: 29 Oct 87 01:33:36 GMT
From: pyramid!prls!philabs!pwa-b!mmintl!franka@decwrl.dec.com (Frank Adams)
Subject: Software Technology is NOT Primitive
Another point worth making: if hardware design is advancing so much faster
than software design, why does the latest trend in hardware design (RISC)
involve putting more of the burden on software?
--
Frank Adams ihnp4!philabs!pwa-b!mmintl!franka
Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108
------------------------------
End of Soft-Eng Digest
******************************
-------