Re: The Plan

[Mark Galassi <rosalia@lanl.gov>]

Jerry, that's a very serious and thought-out message.

I like your discussion of the role of GSL, and your pointing out how
converting legacy code is a misleading characterization.

I disagree with your claims on C++ use by scientists, mostly because
in my fields of work, scientists only use C++ when they hire
professional software engineers to prepare packages for them.  And
these packages seldom work or get used.  When scientists write code to
do simulations and analyze data for themselves, they usually do it in
C or FORTRAN.

An example of this is in the story of the "black hole collision" grand
challenge grant.  Part of the grant was farmed off to professional
software engineers who wrote C++ class libraries, but the scientists
working on the project ended up not using that code much, and doing
their own business as usual.

On top of that, I observe a trend reversal against C++ in many fields.
VHLLs (or scripting languages) have a lot to do with it: although you
can wrap C++ libraries, the wrapping is usually clumsy and frequently
does not respect how the user wants to write the VHLL program.  One
clear example of this is Qt versus GTK+, where GTK+ has had Scheme,
Python and Perl bindings (no to mention Objective-C, Tom and other
languages) since the very beginning.  As a result, GNOME's libraries
and almost all of its applications (including the Panel and Gnumeric)
are written in straight C.

I think you are probably right about the "current field of Linear
Algebra attempts", but that might just be because most of those
researchers are currently building large template-based C++ systems
these days, so practial software that comes out of current research
ends up being in C++.

I'm quite sure that the C library will continue to be important, and I
think it's worth exploring various design possibilities, all of which
have been used in production systems:

* Object-oriented library written in C.  Bad example: Xt; good
  example: Gtk+

* Procedural C library with C++ bindings.  You've argued against it,
  and I'm not ready to argue for it right now because easy examples
  aren't coming to my mind.

* Object-oriented library written in C++, but with a procedural C
  API.  This is done in eCos, Cygnus's embedded OS.  The kernel is
  written in C++, but a C API is offered because embedded system
  programmers use C overwhelmingly.

* Object-oriented library written in C++ with proper C++ class
  interface, and a layer written on top of it to give a C API.  I have
  not seen a nice example of this; I have only seen a very
  unsuccessful attempt at using MICO (a CORBA implementation in C++)
  in C programs in the early days of GNOME.  This worked so poorly
  that Red Hat hired a guy to write a new ORB.  This seems to be what
  you are proposing, and I have not seen it work well.

* Procedural C library written in C with a C template mechanism.  I
  forget where I've seen these C templates, but I'll look it up.  I
  thought offhand it was GTK+'s GLIB, but I don't find them there now.

* Maintaining both a C and C++ library, written separately and sharing
  almost no code and just the algorithms.


Everyone gets annoyed with C++ shortcomings, and it is worth looking
at those which really impact everyday work: I deal almost daily with
the fact that a complex C data structure cannot initialize itself, so
you always have to remember to initialize it before use.  The tricks
to make sure your software does not use the data structure
uninitialized are pathetic.  But I do not chose to bring in C++'s
syntax because of that.  Ooops: I'm getting into personal dislike for
C++, so I should stop now.

I would not mind seeing Jerry's plan go through: we complete GSL, and
keep GSL maintainance at a low level while exploring a C++ library.  I
just don't think it will end up being used for several of our goals.
I think that Scientists writing programs for themselves will still use
the C library, and packages like Octave will still want a natural C
API.