🚀 go-pugleaf

In article <5868@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>What about problems that are well understood by the mechanical engineer
>and poorly understood by the software engineer? While the mechanical
>engineer's program is likely to be less efficient, it's more likely to
>actually produce the correct result. Which is, after all, the bottom line.

I'm somewhat doubtful.  Non-professional programmers are likely to
write simplistic programs.  They will probably work properly in common
situations, but many non-pros don't have experience in incorporating
features such as robustness.  They'll make assumptions about library
routines (e.g. they'll use gets() of scanf() in C when reading input
from the user, and be surprised when they don't perform as expected).

On the other hand, a programmer alone won't understand the problem
domain well enough to write the program well.  What's needed is a
partnership.  The mech-e should write a spec, or perhaps make an
initial stab at the program if he has some programming experience.
Then the programmer takes over, refining the spec or program, getting
clarifications from the mech-e, etc.  I tend to think of the
programmer as working for the mech-e, turning the latter's ideas into
a fully-featured and robust program.

Had Voyager been programmed by astronomers, it wouldn't have made it
to Neptune.  Had it been programmed by programmers, it might have made
it but wouldn't have sent back as much useful information.  But I'm
sure it was programmed by a team that included experts in both areas,
and now we're seeing the benefits.

Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar