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

From: "David E. Bernholdt" <[email-masked]>
Date: Fri, 11 Jul 1997 13:13:25 -0400

It idea of mixed language programming is to use languages most
appropriate for the task at hand, not just for speed, but for ease of
implementation.  Such decisions are usually fairly coarse-grained.
For example, you might prefer to use C code to implement operations on
a fairly complex data structure, while a computationally-intensive
section might better be written in Fortran.

If the code is well encapsulated, there should be little problem
(conceptually) and no performance degredation from hooking up code
written in multiple languages.  Of course that's different from making
a poor choice of programming language to implement a given component.

It is true that interlanguage programming is not standardized (yet),
but as a practical matter, on a given platform you can expect that
most languages (from the same vendor at least) will follow a similar
underlying structure and _will_ be able to interface.  It is also true
that relatively little documentation of these interfaces is
available, but in most cases it is really fairly straightforward.

Some things, like mixed Fortran77 and C, are now so common that there
is a community of people out there who understand pretty well how to
do this and even some packages/templates to help you do it in a
platform-independent way.  If you seek out such people, you can
probably find them without too much trouble.

I can't recall a case where I had to know more about the
"processor-dependent nitty-gritty of numerical computation" to do
mixed-language programming than I needed to do a good job of
scientific programming in one language -- the interfaces are rarely so
fine-grained as that.

> Ultimately, most folks are more concerned with optimizing their time
> use than the computer's :-) .

In my opinion, this is the reason _to_ use mixed language
programming.  If I wanted to write a robust input parser for a large
chemistry software package, I'm sure I could write it in Fortran, but
it would take a lot of work.  These days, there are tools to do this
quite easily in C (lex, yacc, etc.).  For many people, the time
required to write the parser in C _and_ the time to sort out the
interface to Fortran would be shorter than writing it in scratch from
Fortran.  And the C-Fortran interfacing skills learned during the
exercise could easily be reused for other projects.
--
David E. Bernholdt                      | Email:  [email-masked]
Northeast Parallel Architectures Center | Phone:  +1 315 443 3857
111 College Place, Syracuse University  | Fax:    +1 315 443 1973
Syracuse, NY 13244-4100                 | URL:    http://www.npac.syr.edu