[Beowulf] Stroustrup regarding multicore

[Lux, James P]

-----Original Message-----
From: beowulf-bounces at beowulf.org [mailto:beowulf-bounces at beowulf.org] On Behalf Of Perry E. Metzger
Sent: Thursday, August 28, 2008 8:04 AM
To: Steve Herborn
Cc: Beowulf at beowulf.org
Subject: Re: [Beowulf] Stroustrup regarding multicore


"Steve Herborn" <herborn at usna.edu> writes:
> However, that being said I would think that it is usually easier to teach a
> Scientist to code, then a coder the PhD level of the science.

I think either is fine -- you wind up with someone who knows both. The
problem is when you try to segregate the two skills.

I think I finally have the right analogy. A physicist is interested in
advancing physics, not in advancing mathematics, but as the tools of
physics are all made of math, he cannot ignore the math or hope to
turn to a specialized hired mathematician who knows no physics to do
his math thinking for him. The math and the physics are integrated --
you need one mind to see both in order to get anywhere.

Writing good software for physics problems is no different. The
physics and the software are one. You can complain that you want to do
physics, not computing, but that's exactly like complaining you want
to do physics and not math. Indeed, software pretty much *IS* math.

The attempt seems to be to somehow treat the computer science as
though it were the software equivalent of machine shop work.

You're building a new instrument, so you draw up the parts, and then
you ask a machinist to make them. "I need a sheet of metal 12cm by
12cm with holes here and here."  It is somehow imagined that you can
do that with the software -- you make some vague guesses about what
you might need and write a spec (which is imagined to be like a
blueprint for a part) and ask a "software machinist" to make it for
you.

Unfortunately, this misses the point -- the computer programming is
not like machining the parts for the instrument, it is like
*designing* the instrument. That requires both knowledge of both
fields, not just of one. It is not at all like machining.

This is of course a serious problem. It takes at least several years
of effort to become facile with computer software just as it takes
several years of effort to become facile with calculus, differential
equations, etc., etc., and fundamentally one wants to be doing
science, not math or computer programming, but I can't see any real
way around it in the long term if progress is to be made.

Incidentally, THIS IS NOT A NEW ARGUMENT. It was only a little over a
century ago that people scoffed at the idea that engineers needed to
learn higher mathematics. "I'm trying to build a bridge, not to do
math!" was the general sort of attitude that was common. Eventually,
people realized that there was no way around it, you just had to spend
the time to learn the math or you couldn't be productive. I expect
something similar is going to happen here.

---------------

Sort of...

But there's a lot of "hidden process" in building high quality software that the consumer (the physicist in this example) doesn't need to be aware of.  An engineer building a bridge needs to know the properties of steel, and have some understanding of how steel is made (so the properties of various kinds fit in a context), but does NOT need to know how to run a foundry or rolling mill.  Likewise, I wouldn't expect a scientist to have to know how to manage a software development project, except where they have to interact at the boundaries (i.e. specification of requirements, test cases, etc.).

For example, a scientist saying "you must use the PGI compiler" is like the bridge building engineer saying "you must use Pennsylvania coal in the blast furnace".  In both cases, the only legitimate reason is if there is some articulated connection (we have a site license and can't afford anything else, or, my brother owns a coal company and will sell it to you cheap).

Jim