Re: About coordinated efforts on scientific software.

[Christos Siopis <siopis@umich.edu>]

On Tue, 22 Oct 2002, JJ Gomez-Cadenas wrote:

> Let me bring an important subject to the discussion, that of
> wrappers. If GSL is going to be truly the core of free-software
> numerical calculations, wrappers are needed. For HEP it seems
> one would like C++ and python wrappers. I have played for more
> than a year now with a C++ wrapper for GSL and a number of
> non-trivial issues emerge, such as the speed, correct use of
> error handling, minimizing of copying of structures and the
> like, which often end up by suggesting re-implementation rather
> than wrapping (at least for some parts of the library). It would
> be nice to understand better and to discuss all those issues.

Interesting issues, indeed! Some of our very own GSL developers have
thought about some of them, see e.g.:

http://t8web.lanl.gov/people/jungman/except.pdf

My little personal experience with this is that there is a dichotomy
between "big project" folks and "Joe Numeric" folks.

If you talk to people involved with the development and maintenance of big
codes, they will probably propose some elegant top-bottom design, which
usually requires an object-oriented programming methodology to implement
and, increasingly, component programming. These folks will also often
insist that any code bigger than a hundred lines needs to follow a similar
path :) and that "a project rarely starts with the intention to become
big" but in the end, it does, so better plan early on.

If you talk to Joe Numeric, he'll wonder why you need anything else but
Fortran, he'll tell you how annoyed he is by NAG's requirement to return
error numbers, and will reprogram a new single-variable equation solver
each time he needs one because he hates black boxes :)

Seriously though, i wonder if your experience with C++ wrapping ultimately
means that we are doomed to reprogram our libraries every time we move
from one language family to another (at least if we want to do a good
job)...

Christos