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

Internet Message Format | 1992-09-04 | 6.1 KB

Xref: sparky comp.arch:9231 sci.math:10998 comp.lang.misc:2934 comp.lang.fortran:3428 comp.edu:1534
Newsgroups: comp.arch,sci.math,comp.lang.misc,comp.lang.fortran,comp.edu
Path: sparky!uunet!mcsun!dxcern!dscomsa.desy.de!zeus02.desy.de!hallam
From: [e-mail] (Phill Hallam-Baker)
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET News System)
Nntp-Posting-Host: zws012.desy.de
Reply-To: [e-mail]
Organization: Deutsches Elektronen Synchrotron, Experiment ZEUS bei HERA
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 4 Sep 1992 16:29:38 GMT
Lines: 107

In article <[e-mail]>, [e-mail]
(Radford Neal) writes:

|>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 :-).

|>>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!

Yep, quite so, learning sorting and searching is not the point, any decent
graduate should have the nouse to be able to look that up in a book. What is
relevant is the engineering skills of applying expert knowlege to a problem.


|>>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.

RISC machines are fast bercause they abolish support for assembly code. On a
RISC machine instructions are provided for the sole benefit of compilers.


|>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".

This is just the generic language war taken to root. Of course no language can
provide more capabilities than machine code. However this is irrelevant since
working at such a low level of abstraction is too error prone to be feasible for
anything like a large project.

|>>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.

The machine instruction set is of very little relevance since it is very rarely
the case that the target machine is known. I can predict the machines we will be
using for the next 18 months/2 years, no more. We will certainly have at least 3
major manufacturers involved. People who piddle about optimising their code to a
particular machine end up stuck with it. This is OK for embedded controllers
which we rarely change but not for general purpose stuff.


|>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.

We run massively parrallel machines and have a massive data rate to cope with.
Thats why we *have* to use high level languages, the complexity of the problem
is too great to allow use of machine code.


|>>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.

If we needed that type of optimisation we would either buy a compiler which did
it or write our own.

|>>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.

We shiould stop calling it Computer Science and call it engineering.

Machine code is important, CS graduates should know how to build compilers and
processors.

--

Phill Hallam-Baker