NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/arch/9146

Internet Message Format | 1992-09-01 | 8.7 KB

Xref: sparky comp.arch:9146 sci.math:10828 comp.lang.misc:2875 comp.lang.fortran:3359 comp.edu:1469
Path: sparky!uunet!utcsri!relay.cs.toronto.edu!neuron.ai.toronto.edu!ai.toronto.edu!radford
Newsgroups: comp.arch,sci.math,comp.lang.misc,comp.lang.fortran,comp.edu
From: [e-mail] (Radford Neal)
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Message-ID: <[e-mail]>
Organization: Department of Computer Science, University of Toronto
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: 2 Sep 92 00:51:38 GMT
Lines: 157

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

The following post is so profoundly incorrect that I feel compelled to
respond (despite the fact this is usually a Bad Idea on usenet :-).

Perhaps I should note that I have 18 years experience in programming,
have programmed in numerous assembler languages, and most high-level
languages you could think of (yes, including Fortran and Cobol :-),
and have lots of experience in both systems and application
programming, including statistical applications (in fact, the later is
the topic of the Ph.D. thesis I am currently working on). I'm not one
of those CS graduates who aren't sure what an assembler is, who have
been mentioned earlier in this thread...


>Software engineering is not that relevant in general.  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.

Someone has greatly mislead you concerning what constitues software
engineering. Your second sentence is a good first cut at a definition!

>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.
>
>    Evaluating the costs of using the tools.

This is a good second cut at defining "software engineering"!


>If a procedure can use some of the machine instructions and the languages
>available to the programmer cause code to run considerably slower because
>the languages cannot use those instructions, the languages are inadequate.
>No amount of software engineering, or compiler optimization, and get around
>this.  It is this feature which can make major differences in the relative
>speeds of computing on different machines.

This is seldom true. In fact, machines and programing languages have
co-evolved in such a way as to practically ensure this. (From a later
comment, perhaps you realize this...) The result may not be a global
optimum, but it appears that the effort required to do something
radical is not worthwhile at the moment, and will not be until the
rate of progress being achieved with present architectures slows down.
(Look at the state of "Lisp machines" to confirm this - and they
aren't even very radical, really!)

There are exceptions, of course. The CDC 6000 series had (has? It's
been years...) a special "count bits" instruction, for example. No
language has this as a built in operator. You can get at it via a call
to an assembly-language subroutine, however. The subroutine call
overhead will almost always be insignificant.

More generally, there are languages that lack certain capabilities
that are available in any assembly language. Pascal does not allow a
variable to contain a pointer to a procedure, for example. While some
of the time this will just be an oversight, more typically, it results
from a particular vision of programming, which the language is trying
to support. Such visions are essential to progress, much more so than
a miscellaneous collection of "features".

For example, the idea of variables (or structure fields) containing
pointers to procedures is seen to be much more useful when you know
how to use them to support object-oriented programming. This
conception did not originate via C, which has always had the feature,
but rather via Simula, which has never had explicit procedure
variables...


>The CS curricula exascerbate the problem by indoctrinating the student in
>the attitude that the machine instruction set is not to be considered in
>normal programming.

While "indoctrination" is, of course, undesirable, the indicated
attitude is indeed correct. Try writing a commercial program in
assembly language and see how popular you are with the boss when he
finds out that because of this the company can't switch to a new
machine that's cheaper and faster. Or that the program stops working
when a new release of the standard subroutine library is installed,
with a different calling convention. Or that there's a much faster
algorithm that a sensible programmer would have found, in the time you
wasted grubbing for microseconds at the machine level.

He'll probably be even less impressed if you did this for a one-shot
program for which none of the above are relevant.

There are some exceptions, of course. At one time, at least, the IBM
PC was so popular that one could economically justify spending
enormous effort making certain programs as small and fast as possible
by programming them in assembly language. At least, it became
economically justifiable to do this once enough other people did it
that, for better or worse, the machine had become inextricably tied
not just to a particular processor, but to a particular layout of
memory, devices, etc. (Using assembly language would now probably be a
mistake, except for coding of a few time-critical routines, since the
complexity of the applications is now much greater.)

Other cases would be software that has time-critical interactions with
the real world, or software that runs on a machine with an unusual
architecture (some parallel machines, perhaps), etc. This is why
indoctrination is bad - you need to known when an exception comes up.


>There can, and should, be interaction at compile time between the compiler
>and the programmer.  The compiler also should be able to suggest rearranging
>machine instructions, not just the output from HLLs.

This would occasionally be useful. I sometimes look at the output of
the compiler to see if it is generating reasonable code, and to find
out if there's any point in my doing certain optimizations at the
source level (e.g. loop unrolling). This is reasonable for me to do
because I have years of experience at this sort of thing. It probably
isn't reasonable for you to do it.

In any case, the sort of full-blown tool you describe just isn't on.
The effort involved would earn much higher returns if devoted to
producing a better debugger, a better optimizer, a better chip layout,
etc. The rapid speed increases we see don't just happen - they result
from huge investments in research and development. While you may not
realize it, you are essentially saying to the manufacturers, "Stop
working on that new processor that's twice as fast as my current one,
I'd rather you put your effort into letting me play with machine
code!"

Also, have you considered the number of bugs that such a facility
would contain? Despite what the manufacturers may want you to believe,
the current state of compiler reliability is not good. I find that
when I undertake a major project (a program of, say, 10000 lines), I
generally end up discovering two or three bugs in the compiler. I
usually find these bugs fairly rapidly (in fact, I find some of my own
bugs by unsuccessfully trying to demonstrate that they lie in the
compiler :-). I shudder to think how much time casual programmers may
waste when their perfectly good program malfunctions. Perhaps they end
up abandoning it. Can you really say that fixing these compiler bugs
is lower priority than producing a tool that maybe 5% of programmers
will use on maybe 5% of their programs, in order to gain a 5% speed
increase?


>What we are teaching the CS students, and even the software engineers, is
>essentially the mistake made in teaching methods without understanding in
>mathematics and statistics.  Someone who has only learned a particular
>collection of methods is extremely unlikely to consider anything not in
>that particular bag of tricks.  Training is not education.

Yes. A CS graduate who intends to work as a software engineer should
BE ABLE to work at all levels, even more so for a computer scientist
designing a new programming language or operating system. They should
also know enough not to work at the machine level unless there is a
good reason, which isn't very often for application programming. Most
non-professional programmers would be well advised to think about
their problem more, rather than learn the assembly language of the
machine they are using this month.

    Radford Neal