[Beowulf] Stroustrup regarding multicore

[Alan Louis Scheinine]

I needed to parallelize a code already written as a serial code (with
domain decomposition in anticipation of the parallelization) by someone
who was teaching himself C++.  The person put into the C++ everything
he was learning.  From that experience I created my own personal list of
what to avoid in C++.  I was delighted to see that many items on my list
were described in the fictional interview.  (I remember many, many years
ago in the comp.arch newsgroup someone said he wrote a fictional interview
and later met Stroustrup who said that if the author had contacted him he
could have given some ideas to make it even funnier.)

Several times I have modified Fortran programs written by other people
in which every variable referring to a specific physical quantity was
given the same name, even in the subroutines.  Of course the program
subroutines were too specialized.  But it was so easy to understand the
program when I could understand what was intended by using "grep" and by
looking pieces of the code.  For C++, in contrast, I need to see where a
pointer to a class was created (which could be dynamical, depending on
details of the execution) in order to know which virtual function is
being called.  The concept of function overloading and virtual functions
can result in a beautiful structure but fixing "structural flaws" can be
very difficult.

My preferred language is C++.  Paradigms such as counted pointers and STL
containers have simplified my life as a programmer.  I am trying to indicate
a reasonable approach in what is often a heated debate about programming
languages, a fools errand perhaps.  I recommend first writing C++ in a primitive
Fortran style, where variable names refer to what you think they "mean" even
in subroutines and give nearly similar subroutines different names if they
do things slightly differently and despite being interchangable.  And then,
moving towards the elegance of C++ as the code develops.  If the similar
subroutines are used as if they are identical in a few different algorithms,
then I create a generalized version with overloading, virtual functions and/or
templates.  On the other hand, it could happen that the similar functions evolve
to be more different, that different cases need to be handled much differently.

I'm not arguing for Fortran in general because of the horrors of computed
goto's, and also, I've seen programs that used obscure variable names of only
six characters long after that limit no longer applied.  But on the other hand,
there are some aspects of the Fortran style of programming (that are not
intrinsic to the language but part of the culture) that result in programs which
are easy to read -- in my experience.  In contrast, C++ programs often seem to be
labyrinths -- in my experience.

By the way, I almost always declare one-dimensional arrays for any array,
independent of the actual number of dimensions and independent of the language.
It seems to me to be more portable between languages and allows me to use
tricks that the compiler optimization ought to see but doesn't.

One more remark.  In my work I often do not know what technique will work well
until I implement the technique and try it.  Despite the terribly large amount
of time required to rewrite a program, in my experience I need to rewrite the
overall structure of a program several times during the development.  When code,
in any language, becomes a maze then it needs to be rewritten.  One would hope that
C++ would provide reuse and extensibility.  Abandon that hope.  Limitations of the
human intellect dictate that as code develops, major rewrites will be necessary.
Sometimes this rewrite will increase the use of the refined elegance of C++,
even overloaded operators, but these should be added when they clearly
simplify the existing code -- I would like to suggested based on my
limited experience.

Best regards,
Alan

-- 

  Alan Scheinine
  5010 Mancuso Lane, Apt. 621
  Baton Rouge, LA 70809

  Email: alscheinine at tuffmail.us
  Office phone: 225 578 0294
  Mobile phone USA:   225 288 4176  [+1 225 288 4176]