If I understand your point, it is that applications users often won't use
the standard interface in any case: They will use instead some more
application-specific software built upon the standard interface. I agree,
and I stated so in an earlier message. If you are suggesting that this is
a justification for making the standard interface complex, I disagree. In
fact, if this premise is taken to be true, I think it makes sense to leave
all of the niceties targetted to the applications programmer out of the
standard, because they can just as well be included in the layers between
the standard and the applications programmer *if they are needed for that
application domain*.
> Let's look at the Unix graphics world for a moment. Your arguments
> contradict common practice in X, (Open)GL, Motif, etc. Every quarter a
> member of our staff teaches some fundamentals of these graphic
> languages to 40 or so UCSD undergraduate students in the context of
> application-based programming assignments. Certainly these students
> don't study all 2100 pages of X+Motif! But they do achieve surprising
> levels of functionality. The two reasons I see for this are (a) they
> master the fundamental concepts and primitives of graphics programming
> and (b) they learn how to use some very powerful tools along with
> simple primitives to achieve their goals.
It is certainly possible for an application programmer with expertise in
some certain field to use X+Motif. (In fact, everyone in my group has done
this at some time or other, and we could probably all be considered experts
in something.) But each big package that must be learned is one more obstacle
to getting things done, and one more piece of brain clutter. Just think of all
the combined neurons and minutes across the world that will be devoted to MPI
that could be going to what they are really trying to get done :-). I think
it's fine for people like those on the forum to use their neurons this way.
I just don't like the idea of every message-passing programmer in the world
doing so, and I think its possible to avoid it. (A neuron is a terrible thing
to waste.)
> If you are a tool builder and think that some higher-level systems than
> MPI should be targeted at application areas: please, please, please go
> build them. In my opinion, building them on MPI primitives would be
> a good idea.
If the MPI standard combines actions which are not necessarily related (e.g.
creating processes and manipulating communicators) into a single primitive,
this restricts the interfaces being built upon the standard to have the
same combined actions. I believe that it is much more effective to build
a specialized interface out of small and easy-to-understand primitive actions
than it is to refashion complex actions into a different form, and I would
posit that it is difficult and/or inefficient to try to refashion complex
actions into simple primitives through an intermediate interface.
Again, I don't want to overstate the case. I just want to say that there is
power in simplicity, and I hope that the forum is taking this into account at
every opportunity.
-Dave
========================================================================
David C. DiNucci | MRJ, Inc., Rsrch Scntst | NASA Ames Rsrch Ctr
dinucci@nas.nasa.gov| NAS (Num. Aerospace Sim.)| M/S T27A-2
(415)604-4430 | Parallel Tools Team | Moffett Field, CA 94035