From: zaphod@cs.mcgill.ca (Morris BERNSTEIN)
Newsgroups: comp.lang.c,comp.software-eng
Subject: Re: Will we keep ignoring this productivity issue?
Date: 23 Nov 92 21:26:41 GMT
Organization: SOCS - Mcgill University, Montreal, Canada

In article <Bxx865.A4v@cdsmn.mn.org> wells@cdsmn.mn.org (Rich Wells) writes:
>mat@mole-end.matawan.nj.us wrote:
>:                                           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.
>
>This may be true for MIS types programming in 4GLs and the like,
>but I find that a knowledge of the particular hardware one is
>programming for is necessary for two reasons: (1) for the few
>times that one needs to resort to assembly language to get the
>needed performance, and (2) for debugging.  I have seen a
                                                   ^not?
>competent debugger who did not have intimate knowledge of the
>hardware she was working on, nor have I ever seen a competent
>programmer who was not also a good debugger.

A dissenting opinion is offered (i.e. I strongly agree with mat).
Very few applications need that extra boost from assembly code.
Assembly-language programming is a legitimate area of specialization.
If one has the skill to write good assembly, one should not waste the
talent grinding out the 90+% of code that is routine.  Since the
assembly code is such a small portion of the project, the specialist
can divide his/her energies among several projects.

Personally, I would rather use techniques that give me more leverage.
You seem to be sneering at 4GLs.  As a professional, I have designed
and implemented 4GLs (technically, application-domain languages) and
then coded in the 4GL to deliver the application.


As far as requiring machine-language skill for debugging, that's
ridiculous.  I've had to debug applications across multiple platforms
and I don't have time to learn the intimacies of each one.  In the
past year, I've written and compiled code for Sun-3s, SPARCs, NeXT,
Macs, MIPS (DecSystems) and HP RISCS.  I can't recall the last time I
had to go down to machine level to solve a problem.

Debugging happens when the system doesn't work the way it's expected
to work; it just requires some basic problem-solving skills and some
tools.  I have a single question that covers the vast majority of
debugging problems: Is that TV set plugged in?  For the remaining few
cases, you have to be systematic and methodical.  It also helps if you
design the application with debugging in mind.


>
>(BTW: my opinion here comes from the two areas I work in on a day-
>to-day basis: high-end, high performance photo retouch systems,
>and embedded systems for controlling graphics output devices.  I'm
>always interested in hearing from people in other application
>areas as to how their perceptions on this sort of matter differs
>from mine.)

OK.  You picked a particular application area where you do want to
push the envelope.  In your case you do want to squeeze every last
cycle out to the hardware.

The systems I've worked on solved different problems.  In my case, if
performance was a problem, we could get faster hardware or tune the
application without resorting to assembler.

The thing that concerns me about assembler is that it tends to be less
maintainable and less portable than high-level code.  I need to be
convinced of the need before resorting to it.


Morris
Newsgroups: comp.lang.c