Subject: Re: CCL:Design/OO/standardization

From: Fabien Campagne <[email-masked]>
Date: Sat, 09 Aug 1997 18:12:33 +0100

Konrad Hinsen wrote:
> 
> > Development of software for Computational Chemistry
> > by researchers is usualy focused on new methodologies.
> > That's a matter of specialization: people who develop
> > and maintain scientific software have less time to use
> > these software to applied research than people interested
> > in applications only. These two communities have distinct
> > needs:
> >...
> 
> The needs are distinct, but that doesn't mean that they can't be dealt
> with in a single implementation. A well-designed modular system
> would consist of well-tested high-performance modules for established
> techniques and experimental modules for experimental techniques.

A common "design" could be used, not a common "implementation".
Going from "experimental modules" to "well-tested high-performance
modules" imply changing the implementation: at the end of the process
the program won't be the same one (different executables: different
implementations). Ok, this remark is a bit particular, I agree :-)

> > Computer scientific community uses standardization commitees
> > that consist of experts in one field talking together until they
> > agree on a standard: ONE way to do something that meet experts
> > idea of what is important (performances, reusability, extensability..).
> 
> That is one possibility, but equally many products are essentially
> designed by a single person. There are good and bad aspects about
> both approaches.

You point out the main difference between these two approaches:
PRODUCTS "are essentially designed by a single person"
STANDARDS are designed, discussed, refined, finaly accepted
and documented by a set of people that represents a
large panel of needs. These needs reflect needs of the much
larger number of people that will work with the final standard.

It seems to me that the final product of a software design, 
whatever it is about, reflects experiences (sometime opinions or
convinctions, sometime knowledge of the logic under the system to be
designed, sometime statistical observations) of the people involved
in the design.
If one person is to design a product because this product will be 
used by himself only, that's fine (same thing with "team" for
"person").
In case of standards, which actual goal is to offer a COMMON
solution to a problem that interests a community, the least you
can do is give as much people as possible the oppportunity to
discuss and criticize the choices before they are adopted as 
the standard.
If you fail to do so, the "standard" won't be adopted by the 
community (ie. won't be used) because it won't reply to the needs
of the majority of the people in the community. 

> > What about standardizing interfaces for common algorithms ?
> > It seems to me that a minimization algorithm looks like
> > another and should be used the same way from the code
> > I'm writing (whatever the implementation I actually decide
> > to retain)
> 
> Almost. Minimization algorithms do essentially the same job, but
> require different parameters for controlling convergence, step sizes,
> etc. And there are many more situations in which various algorithms
> have almost the same interface.
> 
> An OO solution to this problem is to encapsulate the algorithm in
> an object that also stores all the parameters. For example, you

The Standard Template Library, which IS part of the standard C++
library, proposes algorithms (for each, find, sort, transform,...
to name a few) that are not designed as objects. They are implemented
using "generic programing" in C++. 
to learn more about this alternative approach, you could
read http://www.ipmce.su/~fbp/stl/StepanovUSA.html
and look at
http://www.cyberport.com/~tangent/programming/stl/resources.html
for information about STL.

The "generic programing" approach seems well suited to
fine grain algorithms (very low level components) because
its C++ implementations can be very efficient. In any case,
it's certainly a good idea for a C++ programmer to know about..

> could create a "steepest descent object" with a certain parameters
> and a "conjugent gradient object" with another set of parameters,
> and then apply the two in exactly the same way to a molecular
> system.
> 
> > Couldn't we design our software so that algorithms are
> > parameters for algorithms (at compile time). Maybe an example
> 
> Once algorithms are encapsulated in objects, this is trivial:
> the algorithm object is simply passed as an ordinary parameter.
> For an example, look at the description of minimizer objects
> in my Molecular Modelling Toolkit; the relevant page of the manual
> is http://starship.skyport.net/crew/hinsen/mmtk_manual/dynamics.html.

I agree with you that OO design is a good way to design evolutive
systems. The point I would like to insist here again, is:
if we want to be able to reuse computational chemistry software
components (pieces of code written by different labs or
individuals and made available to ohers) -- in a rational way --,
we need to design, carefully, a common interface to related components.

I understand some people reading this post may be not familiar
with the terminology: components, design, interface (interface 
beetween two pieces of code, not graphical user interfaces).
I'm currently writing a few www pages to describe these
concepts and the way they can be useful to computational chemistry
software reuse. I'm convinced the real problem that curb the
ermergence of interfaces between already existing components
is a lack of information on 1/ the advantages of the method
2/ the "how to" problem.
I'll post an announce to CCL once this resource will be available.

Fabien Campagne -- [email-masked] | Lab. de Chimie Theorique
phone: +33 (0)3 83 91 20 00  extension 3236 | Nancy, France.
           http://www.lctn.u-nancy.fr/viseur/FC.html

---

From: Konrad Hinsen <[email-masked]>
Date: Sat, 9 Aug 1997 19:38:29 +0200

> implementations). Ok, this remark is a bit particular, I agree :-)

True, but only individual modules would change. The majority of the
implementation would remain the same.

> large panel of needs. These needs reflect needs of the much

The distinction is not that clear-cut. Often de-facto standards are
defined by a single product (e.g. the IBM PC or the Visual-Basic
language) that is later copied. And even official standards are
sometimes to a large degree based on the work of one person; for
example, the coming C++ standard would not exist without the
preliminary definition of C++ by Bjarne Stroutstrup.

> of the majority of the people in the community. 

And even if everyone is involved in the definition of a standard, it
may well in the end be ignored, typically because it became irrelevant
during the long time of the standardization process. Anyone using
ISO-Pascal out there? Probably not. When it was ready, all Pascal
dialects other than Turbo-Pascal had essentially disappeared.

> to name a few) that are not designed as objects. They are implemented

Because they do not need parameters for their specification. Besides,
templates are a technique specific to C++, not a general OO technique,
therefore the STL approach is not easily generalizable.

> it's certainly a good idea for a C++ programmer to know about..

Obviously. In fact, the whole STL is something C++ programmers
should definitely know about!

> we need to design, carefully, a common interface to related components.

Ultimately yes. But I think we are still far from a state in which
such as decision could be made. There is hardly any practical
experience with OO program packages in computational chemistry. But
designing a standard requires first analyzing existing solutions to
find their good and bad properties.

> beetween two pieces of code, not graphical user interfaces).

Which is the proof that there is not enough practical experience
around! Anyone taking part in a standardization process must not only
be familiar with such terms, but also have practical experience with
these concepts.

> is a lack of information on 1/ the advantages of the method

Right. But I am not sure that explaining all that on a Web page
will be sufficient - the difficult part could be convincing people
to read it!
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: [email-masked]
Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------