🚀 go-pugleaf

In article <13380@megaron.arizona.edu>, gudeman@arizona.edu (David Gudeman) writes:
> In article  <9015@june.cs.washington.edu> kolding@june.cs.washington.edu (Eric Koldinger) writes:
> >...
> >Why?  Just because someone doesn't want to be a CS major doesn't mean that
> >he/she doesn't want to learn to program, or have need to program.  What about,
> >for instance, engineering majors who often have to design large programs, but
> >aren't CS people, per se?

			......................
	[Several examples of bad algorithm design are given]
> 
> This has brought me to the conclusion that the era of non-professional
> programmers has past.  The programming discipline has advanced to the
> point where it really does take four (or more) years of in-depth study
> to become competitive in the field.  Would you expect an electrical
> engineer to design a car?  A mechanical engineer to design a microchip?
> If not, then don't expect either one to design software either.

I agree that bad algorithm design is a major problem.  But the current 
teaching of professional programmers, and even programming consultants,
is worse.  I do not see that the gurus do that well.  If the designers
of the languages were not that arrogant, and asked those who do understand
what they want to compute and how hardware affects it, we would not have
the atrocious languages of today.

I know of a professional programmer who told a former colleague of mine
that to compute the numerical value of an integral it was necessary to
use a numerical integration procedure.  Now in this case, the quick and
dirty formula I gave him was of comparable speed to using a highly
optimized method to compute ONE function value.

Recently, a language guru's comment on an algorithm to compute a specific
function, not writable in C or any other HLL to my ken, that I should 
profile the behavior and find the places most used instead of using a
program based on machine instructions.  There is one conditional branch
in the program, based on an "overflow" bit, which involves a quick
adjustment.  Every other instruction is executed a fixed number of times.
Profiling, indeed!

I keep hearing that computers are getting so fast, etc.  I keep telling my
students that they must do analysis before numerical analysis.  Yet the push
is to develop packages which an ignoramus can use, but which provides little
more for the skilled artist.

The so-called good programmers cited by David Gudeman really have not done
all that well.  In programming something well, it is necessary to take into
account what is being attempted.  A professional programmer may do a good
job at producing an editor, or possibly an assembler.  But a programming
language which is good for people doing mathematics, no.  This effectively
means that the mathematician must be the programmer.  The engineer who
programs is being an applied mathematician, not an engineer at programming
time.  As such, he knows what the program is supposed to do.  If he 
understands the machine, he will have a very good idea of how to do it
well.  But will the language let him wihtout working hard?

-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)