Subject: OOP in comp. chem

From: [email-masked] (Quentin McDonald)
Date: Wed, 9 Feb 94 15:35:59 -0500

February 9, 1994.

Dear netters,

I read with interest the comments of Ferenc Molnar 
([email-masked]) on the use of object-oriented
technology in chemistry. I have been thinking about this myself for some
time and the preliminary experiments I have undertaken have left me 
convinced that OOA/OOD/OOP (Analysis,Design,Programming) is certainly the 
way to go.  I should make it clear that these are my opinions and not 
necessarily shared (or even approved) by my employer. 

Firstly some comments on Ferenc's post:

>>> You need quite a long time for designing your program in an OOP-language
>>> when you are used to modular programming.

This is the famous learning-curve.  The most important thing is to develop
"object-think" rather than learning any particular language syntax.  You
can write "FORTRAN" in any language including C++; this would be reduced
if we had "pure" object-oriented languages available but for now the
mixed-paradigm of C++ seems to be the only game in town.  I should also
point out that you can also write OO programs in C and even in FORTRAN (I
have done the former myself and it works quite well for projects which
cannot be migrated to C++).

>> Second:
>> FORTRAN 77 is the most portable language (C programmers forgive me!).

You are forgiven.  I think all languages actually have some portability
problems as even if the vendors supply strict ANSI standard compilers
it still requires  discipline of the programmers not to use extensions
(and this can happen unwittingly).  We are using C++ on two platforms
(SGI and RS/6000 both with the vendor supplied compilers) and we
have not had any problems so far (but we do avoid templates and exceptions).

>>> Third and most important:
>>> As you always have a lack of hardware resources, you
>>> need a compiler which optimizes efficiently.
>>> Often the raw speed of your calculation is the crucial point.
>>> FORTRAN compilers have quite a history and are very effective in
>>> "number crunching" and are essentially bug free.
>>> The advantage of C++ (or say FORTRAN 90) is that you can handle
>>> dynamic memory allocations, but this can slow down the program and
>>> prevent effective optimization.

This I really disagree with.  Certainly I always wish my calculations
will go twice as fast but in reality I probably just have to wait
for next year's machines.  In my opinion the big challenge facing us
at the moment is verification of correctness not optimization.  If a 
language change makes a program slower by a factor of two or three then
it is no big deal - that may set us back a year.  But if we could introduce
a better and more robust design that would benefit us for the lifetime
of the program (which has been ~25years for codes like GAUSSIAN).  If
we want to go faster by orders of magnitude then only better algorithms
and/or faster hardware can do it for us; not compiler optimizations. But
most importantly we need the right answer not the fastest answer.

>>> In my oppinion OOP methods should only be used for large scale projects.
>>> These projects have to be supported by some organization like an
>>> university or a company and are scheduled for years.
>>> I think that in this case the financial grounds are there for even
>>> reprogramming functioning code (e.g. Hyperchem from Hypecube).

My own experience has in fact indicated that it is better to begin applying
OOP to smaller, less mission-critical applications (but design for 
reusablity) and then be able to "iterate" the design while the local
development environment builds up expertise in applying OO methods to
the problem domain at hand.  Unless you are a "natural" your first designs
are likely to be most useful as learning experiences only.

In my opinion the benefits we can obtain from object-oriented programming
are :

	1) Better modeling of the problem domain.  Atoms, molecules, 
	ensembles, and even electrons are objects and it begins to
	"feel" natural when these physical objects are encapsulated as 
	"objects" in the code.

	2) Better chance of correctness.  There are three reasons for
	this:
		i) Better static (i.e. compile-time) checking in a 
		language like C++ compared to FORTRAN and K&R C.
		ii) Object-oriented design allows complicated data
		structures to be expressed in a more natural way and
		one which is less likely to be misundertood.  The concepts
		of data hiding enforce a discipline which is rare in
		FORTRAN.  How many times have those of you who maintain
		large FORTRAN codes spent time scratching your head over
		what routine is fiddling with the value of FACTRX in COMMON?
		iii) If a program becomes a collection of "closed" objects
		then each of these can be tested and certified correct 
		independant of any applications.  Then the sort of errors
		that are hidden by "serendipitous compensation" ( and
		this does happen and cannot be revealed by application
		testing) will be less likely.
		
	3) Reusablity. In the wider world OOP is considered as a boon
	to productivity as it boosts the effective number of lines of code
	a programmer can generate in a given time.
	In science the big gain will be in providing a set of tools which
	scientists can use to rapidly try out ideas.  Take for example
	file conversion - this would be much easier if each format "vendor"
	provided a library which read their format and a standard interface
	for accessing the data. 

We have a small number of projects here at Columbia which use an 
objected-oriented approach (one will appear in the next release of 
MacroModel).  Rather than inflate an already way-long message with the
details I am happy to discuss our experiences with anyone who is interested
and I would like to hear from other people who are using this approach.

Quentin.

-------------------------------------------------------------------------------
Quentin McDonald.   ([email-masked])			*
Still Group, Dept. of Chemistry, 				      *	  *
Columbia University, New York, NY.                                      
Telephone (212) 854-8402.                 				* 
------------------------------------------------------------------------------