Subject: Re: CCL:Object-oriented means for computational chemistry programming

From: Andrew Dalke <[email-masked]>
Date: Mon, 21 Jul 1997 19:12:32 -0500

Konrad Hinsen <[email-masked]> commented:
> Just a crazy idea: create an institution
> devoted to "scientific computing" for the academic community. Staff it
> with application scientists and computer scientists, and let it work
> on a high-level language for scientific applications ...

  That's somewhat like what the Numerical Algor. Group does (www.nag.com).
From http://www.nag.com/0h/AboutNAG.html :
> NAG produces and distributes numerical, symbolic, statistical and
> visualisation software for the solution of problems in a wide range of
> applications in such areas as science, engineering, financial analysis
> and research. 
> 
> For users who write programs and build packages, NAG produces
> sub-program libraries in a wide range of computer languages (Ada,
> C, Fortran, Pascal, Turbo Pascal). [...] NAG provides several
> powerful mathematical and statistical packages for interactive use.

  In a non-commercial sense I think most application domains have
their own set of tools, and it will be very hard to convince     
mathematicians to give up MatLab/Mathematics and astronomers to
give up AIPS/AIPS++ and statisticians give up S-Plus and ...
Granted, scripting languages like Python can incorporate all of    
these interfaces, but it takes time, money and expertise.

Konrad went on to say:                       
>  I'd like to propose an alternative
> model for developing scientific code: define a "lifetime" of between
> five and ten years for each package (depending on the speed of method
> development) and throw it away after that time, replacing it with
> new code containing the useful part of the functionality and written
> according to the state of the art of programming.

If the code is implemented "correctly" there is no reason to do
this.  When was the last time you needed to upgrade ftp, or      
telnet, or bc, or yacc?  I use libpdb from the CGL to read PDB files 
and the library hasn't changed in years (though the PDB format has :).
Yet it still works very well.  The C and Fortran APIs for PVM 
haven't changed very much over the last 5 years, and there isn't
much call for a change.

  I think the problem isn't that code naturally decays over
time but that it wasn't well designed in the first place.  Flaws
in the architecture are glossed over as the project grows until
it becomes a morass of hacked fixes, until finally the thing is
chucked.  Done well (modular code, consistant design, well
thought out APIs, etc.) there's no reason you shouldn't use
a 15-year library.

  However, it is hard to do.

						Andrew Dalke
						[email-masked]
P.S.
  Oh yeah, and another reason for code to change -- creaping featurism!