NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/lang/c/16648

Internet Message Format | 1992-11-17 | 3.7 KB

Xref: sparky comp.lang.c:16648 comp.software-eng:4338
Newsgroups: comp.lang.c,comp.software-eng
Path: sparky!uunet!mole-end!mat
From: [e-mail]
Subject: Re: Will we keep ignoring this productivity issue?
Message-ID: <[e-mail]>
Organization: :
References: <[e-mail]> <[e-mail]>
Date: Tue, 17 Nov 1992 01:46:38 GMT
Lines: 59

In article <[e-mail]>, [e-mail] (As if I'd tell you!) writes:
> In article <[e-mail]> [e-mail] (Phil Howard ) writes:
> >...

> >In EE you START from the bottom and work your way up.  You learn to
> >understand the building blocks.  Computers SHOULD be taught the same
> >way.  In fact I am awfully tempted to say that the circuit theory and
> >digital circuits courses should be taught to even though wanting to
> >become programmers.  At least some machine language should be.

> I'm currently enrolled in the EE program at UC San Diego and I will be
> switching to CS soon.  ...  the EE and CS programs are pretty close to
> each other in some of the upper-division classes and identical in the
> lower-division.  The lower-division classes include Assembly Language on
> a 68030 chip along with introduction to basic hardware concepts and
> implementations such as logic gates, etc. ...  So you see, there are
> computer scientists being taught the building blocks.

I think this is a grave mistake.

In invoking the `engineering model' I do not mean that programmers should
be trained in the subject matter in which electrical engineers are trained;
I mean that they should be given tools of thought that apply to their work
as the engineers' tools apply to the engineers' work.

Back when electrical engineering was immature and the basic theory not well
worked out, the `basics' in an EE education were the construction and physics
of devices.  As time went by, these `art' (as in `state of the') of these
devices advanced.  This had two effects.  First, it took stronger theory to
understand how to construct the device.  Second, the external behavior of
the device became more uniform, more nearly ideal, and could more readily
be described by ideal theories (e.g. circuit theory).  As circuit theory
developed it became the tool by which everything else had to be understood.
The physical building blocks became advanced material.

We no longer program in assembler except out of necessity.  It is a
specialized art.  The average programmer doesn't need to know how a gate
works; in fact that knowledge will go out of date and come back in again
as circuit and logic topologies change with generations of hardware.
(Anyone remember I2L?  And how do you explain programmable gate arrays?
And for how many hardware generations will that knowledge be relevant?)
It takes more and stronger specialized knowledge to understand the
implementation.  But higher-level languages hide all this quite effectively.

What the average programmer needs to know first is how to formulate a
problem so that it is amenable to computer solution over the long term.
This demands a simple, powerful theory that can directly abstract what is
needed from the `physical' description.  I'm not saying that a programmer
shouldn't understand the architecture of a digital computer, but that such
an understanding will be an idealization, whose specifics cannot be applied
to any particular hardware, and that it will have vanishing impact on 99%
or more of his work.  His vital skills are in applying the tools he is given
to a problem, and to do that he must have a theory which provides him a
penetrating understanding of the problem.
--
 (This man's opinions are his own.)
 From mole-end                Mark Terribile

 [e-mail], Somewhere in Matawan, NJ