From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Date: 1 Sep 92 21:26:02 GMT
Organization: Purdue University Statistics Department

In article <1992Sep1.115849.13522@relay.nswc.navy.mil> bwallet@apssgi.nswc.navy.mil (Brad Wallet) writes:
>In article <1992Aug31.195540.13074@ctr.columbia.edu>, shenkin@avogadro.barnard.columbia.edu (Peter S. Shenkin) writes:

			.................

>As I have said previously, you are getting computer scientists and 
>software engineers confused.  Software engineering is the discipline
>concerned with writing good code.  Software engineers study the design
>process, design philosophy, testing, life style management, reliability,
>and all that other stuff that defines good code.

>Computer science compares to software engineering much as math and physics
>compare to the various engineering fields.

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

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.

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 design people then continue the process by producing
hardware manuals in which the description of the operations, and considerations
for producing good code, is written so as not to use any structure, and thus
takes several times as many pages, and is hard to understand.  And the only
adequate language to use the machine is an assembler language with an 
atrocious syntax.  Often the HLLs do not have convenient ways of including
the instructions.

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.  The translation of 
other HLL-type operations into machine code should be essentially the same
as that of such standard operations as + and *.  These can be provided, and
should.

Current software seems almost designed to prevent the user from doing anything
the HLL designers did not think about.  Then hardware leaves out what even a 
fairly intelligent user will use, which the software does not get at.  And so
it goes.

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.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@pop.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!pop.stat!hrubin(UUCP)
Xref: sparky comp.edu:1343 comp.lang.fortran:3178