NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/arch/9250

Internet Message Format | 1992-09-07 | 5.9 KB

Xref: sparky comp.arch:9250 comp.lang.misc:2950
Path: sparky!uunet!gatech!purdue!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
From: [e-mail] (Herman Rubin)
Newsgroups: comp.arch,comp.lang.misc
Subject: "Training" of programmers
Message-ID: <[e-mail]>
Date: 6 Sep 92 12:51:02 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail] (USENET News)
Organization: Purdue University Statistics Department
Lines: 94

In article <[e-mail]> [e-mail] (Robert Firth) writes:
>In article <[e-mail]> [e-mail] (Herman Rubin) writes:

>>What is relevant is
>>the translating of the problem to be computed into the collection of bits
>>which the machine can understand to accomplish the task.  This involves

>>    Knowing the algorithmic processes which can be applied, their
>>    strengths and weaknesses, and what happens to them on the particular
>>    machine when they are translated using the available languages.


>Whether scientific programmers need to understand the hardware is a
>debateable topic, but on the issue of fact that Dr Rubin raises, please
>let me add my firm support to his assertion that most programmers,
>scientific or otherwise, in fact do not understand the machinery
>beneath their feet.  Allow me to relate a story from my own experience,
>which is perhaps of some relevance to the issue of machine and system
>architectures.

        [Details of interesting story deleted.]

>Now, these people were not fools - they were PhD's in computer science
>and some of the brightest folk you could meet.  And this was not a cheap
>and cheerful hack; it was supposed to be an industrial strength optimising
>compiler with register tweaking, loop scrunching, dead code eulogisation,
>you name it...  So why, then, did they implement this simple feature in
>the most grotesquely inefficient way imaginable, with a design one would
>expect a developmentally-challenged tree sloth to be able to pick to
>pieces in ten seconds?

>I believe the answer is this: these people had between them about 30 years'
>eduucation in academic computer science.  They knew about stacks, queues,
>lambda calculi, invariants, NP-completeness; they could use words like
>"isomorphic" over morning coffee.  And, in all that time, they had never
>been taught to visualise *what really happens when real code runs on
>real machines*.

They know about details, theorems, and specific methods.  They still knew
nothing of the basics of how a computer operates.  One course tells how
everything can be done on a stack machine; another shows how it can be
done on a primitive von Neumann machine.  It is like the joke about the
mathematician who undoes several steps which have already been done, so
that the problem is reduced to the previous case.  This may be acceptable
in proving that the traveling salesman problem is NP-complete, but it gets
nowhere in implementing code to run in a reasonable length of time.

>This problem is pervasive.  Each generation sees a new and more monstrous
>bloat in the size and cycle consumption of what I still think of as basic
>system software - device drivers, editors, compilers, linkers.  And the
>reason the programmers are so profligate of resources is that they have
>never been taught that resources matter - they are told that, in computer
>science, "everything is virtual", and all resources are infinite and free.
>There is no technical perception of the machine as a real engine, with
>finite capability, and no aesthetic perception that economy of means is
>one of the cardinal qualities of good engineering.

Given a large enough memory, and a small amount of fixed code, any computer
can be simulated on any other.  Computers are not infinitely fast, and,
despite the rapid speedup of PCs, limits are being approached.

>This must be changed.  Or real companies, with real problems, will continue
>to hire english majors, biochemists and quantum mechanics to write their
>programs; because, as a senior member of one such company told me: "It is
>cheaper to train than to re-train."

The problem is even more pervasive than that.  Our educational system never
did that great a job of educating rather than training, but at least students
used to be tested to a fair extent on understanding rather than rote.  This
has almost vanished from the elementary and secondary schools, and is rapidly
disappearing from the universities.  The calculus course never did that great
a job on teaching the concepts, and only a fair one on examining them, but
now even that is reduced.  What CS program does more than barely hint to the
students that there is much more to what a computer can do than Pascal or C++?
Or that there are real problems where these other things are useful?

Educating a trained person is much harder than an untrained person.  I teach in
a statistics department; teaching statistical understanding to those who have
taken methods courses is very difficult, and extends even to PhD statisticians.

And then the hardware designers, being told that something is useless, drop
it from the instruction set?  Designing flexibility in both hardware and
software is not that expensive; putting in something left out may be.  A
simple example is that of square root.  The cost of putting in square root
on any machine which has "classical" division hardware is essentially zero
at the design and construction stage, but an algorithm to do it is otherwise
is necessarily slow and costly.  Bit vectors do not necessarily start on a
word, or even a byte, boundary, and again, it is easier to deal with the
problem at hardware design time rather than in software.
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: [phone]
[e-mail] (Internet, bitnet)
{purdue,pur-ee}!pop.stat!hrubin(UUCP)