NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/sci/math/10901

Internet Message Format | 1992-09-02 | 6.0 KB

Xref: sparky sci.math:10901 comp.lang.misc:2900 comp.lang.fortran:3391
Path: sparky!uunet!elroy.jpl.nasa.gov!swrinde!network.ucsd.edu!mvb.saic.com!unogate!beckman.com!dn66!a_rubin
From: [e-mail] (Arthur Rubin)
Newsgroups: sci.math,comp.lang.misc,comp.lang.fortran
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Message-ID: <a_rubin.715469580@dn66>
Date: 2 Sep 92 21:33:00 GMT
References: <[e-mail]>
 <[e-mail]>
 <[e-mail]> <[e-mail]> <[e-mail]>
Lines: 104
Nntp-Posting-Host: dn66.dse.beckman.com

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

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

Well, I have 20-22 years experience in programming, have programmed in
numerous assembler languages, and many high-level languages, (including
Fortran, C, Snobol), and have lots of experience of both systems and
application programming.

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

What distinguishes "software engineering" from programming, then.

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

What distinguishes "software engineering" from programming, then.

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

Consider the "index of largest bit"  on an integer variable.  Any binary
machine with integer and floating point hardware, and communication between
them, can generate that number; to do so in assembler may require precise
knowledge of the floating point format (not all machines have IEEE floats);
and it is not available in most programming languages.  (It is available
indirectly in  most extensions of C.)

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

(Perhaps) a minor point:  the subroutine call overhead will almost always
be more than the execution time of the special instruction; it is
frequently significant.

>>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 didn't say "writing in ... assembler language"; he said be aware of the
machine instruction set.  (I admit most of the improvement would be by a
small factor, but....).  For instance, in writing programs for machine
which don't have hardware multiply and divide, you should generally avoid
using multiplies and divides in the program, even if there is an emulator
package to perform those functions.  For a more modern example, if you are
programming a vector machine, you should attempt to use a vecorizable
algorithm, even if it appears a little less efficient because it performs
unnecessary operations.

--
Arthur L. Rubin: [e-mail] (work) Beckman Instruments/Brea
[e-mail] [e-mail] [e-mail] (personal)
My opinions are my own, and do not represent those of my employer.
My interaction with our news system is unstable; if you want to be sure I see a post, mail it.