NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/edu/1479

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

Xref: sparky comp.edu:1479 comp.lang.fortran:3370 comp.lang.misc:2885 comp.arch:9165 sci.math:10859
Path: sparky!uunet!usc!zaphod.mps.ohio-state.edu!darwin.sura.net!dtix!relay!apssgi.nswc.navy.mil!bwallet
From: [e-mail] (Brad Wallet)
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Message-ID: <[e-mail]>
Date: 2 Sep 92 12:41:17 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Naval Surface Warfare Center
Lines: 111

In article <[e-mail]>, [e-mail] (Herman Rubin) writes:
|> In article <[e-mail]> [e-mail] (Brad Wallet) writes:
|> >In article <[e-mail]>, [e-mail] (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.
|> --

I have to disagree on several points.  As an analyst, I understand the
problem to be solved intimately.  I am going to provide formulations that
solve the problem at hand.  I am going to give any constraints that are
necessary.  I will not tell the software engineers how to implement the
formulations.  That is up to them as long as they implement the equations
and constraints that I have provided.  It is their responsibility to
prove that they have implemented my formulations correctly.

I used to think that the software engineers needed to understand the
math and physics of the problems being solved.  I am not so sure anymore.
They have theirs hands full as it is.  No, I guess they need some familiarity
with the material, but they do not need to be experts.

I was forced to do software engineering for a brief period.  Greatest
thing that I ever did.  First, it improved my ability to code.  This is
very important if you do a lot of computational experiments.  I learned
to write reusable code.  You would be surprised how useful this can be.
I also learned to big into systems and understand how they were implemented
and why.  I am now able to communicate better with the programmers.  I am
a pretty good programmer because of the experience.  Anyone can be a good
programmer.  Being a greater software engineer is what takes talent.  I
think I would become bored doing this.  Let us be thankful some people like
this.

You would be surprised how much software engineers now about the hardware,
operating systems, and all that.  Little things like changing the order
you search an array to match the compiler's implementation can really speed
things up.  These people are professionals, they are sharp, and you shouldn't
sell them short.

If things are fast enough, why do some of the stuff you suggest?  Hardware
is cheaper.  Man power is $50 an hour.  Software engineers should and do
write easy to test and easy to maintain code.  Besides, I put nothing
past past optimizers.  If the optimizer can suggest away to improve the
code, it should be able to verify that the change is mathematically correct
and merely effect the binary.  Those computer scientist can be sharp cookies
too.  I recall an article recently where a defense contractor was ordered
to redo a system that had illegally done in assembly in Ada.  They did redid
a part in Ada to prove it couldn't work.  The result was that the Ada ran
faster and in less memory that the assembly.  Rewritting in Ada saved them
enough time in testing to negate the time it took to redo the system.

-------------------------------------------------
Brad Wallet                 Mathematician
[e-mail] Naval Surface Warfare Center
[phone]               (AVN)249-4950
DSMAC - "Tomahawk's Eyes"
"I can neither confirm nor deny that these opinions
are entirely my own and may or may not reflect those
of the US Navy."