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

From: Konrad Hinsen <[email-masked]>
Date: Sun, 20 Jul 1997 14:22:18 +0200

Coming back from the EBSA conference in Orleans, I found a few messages
on this topic that I would like to comment on:

--------------------------------------------------
Anthony J. Duben:

> IMHO there is another alternative -- Ada.  It is designed for writing solid
> software engineering
>  applications, lacks the arcana of C/C++, and has versions available for
> most systems.

Ada has an impressive collection of arcana of its own; it might easily
be the most complicated language in existence. However, it definitely
has advantages as compared to C/C++, and I think it deserves a closer
inspection for numerical applications (which to my knowledge barely
exist in Ada). Personally, I just don't like it, and I don't like the
idea of using a language that is so complicated that most programmers
will never be able to learn all of it.

--------------------------------------------------
Irene Newhouse:

> There ARE reasons why FORTRAN is still used by scientists.  Of course
> there's the legacy code argument -- people who don't have time to reinvent
> the wheel continue to use stable, well-developed subroutines for parts of
> their code.

Right. But you can continue to use all that legacy code while writing
new stuff in another language - that's why I mentioned mixed-language
programming. My Python code for linear algebra uses LAPACK, for example,
but users don't see that directly.

> 2nd, you cannot confuse aesthetic structure
> with efficently executing code!!!!  I work in a user services environment
> where we help people optimize codes.  Spaghetti code is ugly, but it
> executes.  Every subroutine call adds overhead, and we've seen some
> gorgeous OOP stuff that runs like molasses in January, dragged down by all
> the overhead...  FORTRAN has a decades' long head start in compiler opt.

This is a matter of using good compilers. Compiler technology has
progressed tremendously, although numerical optimizations are often
ignored except in the case of Fortran compilers. I am sure that
we will see better compilers for other languages as soon as scientists
and engineers begin to express a real interest in those languages
to compiler writers.

--------------------------------------------------
Gabriel Berriz:

>    The bottom line: no single language is perfect. I think scientists
>    should get used to the idea of mixed-language programming.
> 
> This sounds great in theory, but I think it is hard to put into
> practice.  The reason is that, while anyone can easily find pretty
> authoritative reference manuals on, say, ANSI C or Fortran90, it is
> much harder to find good documentation for mixed-language programming.

Right, but some particularly useful combinations are exceptions. The
C/Fortran interface is handled rather nicely by the CFORTRAN package
developed at DESY (ftp to zebra.desy.de). And modern high-level
languages (such as Python) are written in C and therefore have a
simple C interface. Together with CFORTRAN that allows using Fortran
subroutines.

C++ can interface to C in a standard way, and there is also a
provision for linking with Fortran code, although I am not sure
if it made it into the draft standard, or if it is implemented in
real-life compilers. It certainly *could* be done if there were
enough interest.

Most other languages can somehow interface to C and from there elsewhere,
but then it becomes compiler dependent.

> (And coding with incomplete or inaccurate information will almost
> certainly fail to yield faster programs.)  Or have I just had bad

Coding with incomplete information is standard practice! I wonder
how many Fortran-loving scientists have read and understood the
Fortran standard! It's at http://www.fortran.com/fortran/stds_docs.html.

> Moreover, I suspect that to make the mixed-language idea pay-off, one
> would really have to learn a great deal about the processor-dependent
> nitty-gritty of numerical computation, information that is even more
> difficult to come by even than that for mixed-language programming.

Not at all, unless your goal is to optimize the use of various
languages.

> As things stand, computational chemists face the unpleasant choice
> between writing relatively slow code in their favorite language, or
> devoting a huge amount of time and effort to mastering the
> computational arcana of the various, rapidly mutating platforms they
> work with, material that is totally unrelated to their science.  As

There may be solutions. 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 plus a set of
standard libraries for common needs and simple interfacing to at least
C, C++, and Fortran on all modern machines. The result should be usable
by scientists who are not expert programmers, but expert programmers
should participate in its design and implementation.

The scientific Python community has essentially started in that
direction, and what is there proves that it can be done. But as a
purely volunteer effort it suffers from manpower restrictions. For
example, work on a Fortran interface stopped when its author left
academia for a "real" job.

> likely 110%, as fast?  Probably not.  Ultimately, most folks are more
> concerned with optimizing their time use than the computer's :-) .

Exactly! But in my opinion, spending weeks analyzing and debugging
ancient Fortran code is not an efficient way of using human time. For
someone starting on a lifelong carreer in computational science, the
time to learn programming properly is most certainly a good
investment.

--------------------------------------------------
Gerald Loeffler:

> Thats
> 	Scientific and Engineering C++ : An Introduction With Advanced
> Techniques and Examples
>         by John J. Barton, Lee R. Nackman
>         Hardcover, 671 pages
>         Published by Addison-Wesley Pub Co
>         Publication date: July 1, 1994
> 
> This on the other hand is a very thoroughly written text on C++ as it
> will more or less emerge from the standardization effort (note: there is
> no ANSI C++ standard yet!).

A very good recommendation for any C++ programmer working on
scientific applications. However, if you want to *learn* C++ from it,
you should be well motivated, otherwise you might easily be
discouraged. My recommendation: get this one plus a "standard" C++
introduction and use them in parallel.

--------------------------------------------------
A J Turner:

> There seems to be one points that no-one has covered, especially when we
> say FORTRAN has run its coarse.  If I am to spend a long time writing a
> piece of code to perform a very complex task - I need to be 100% sure
> that the code will be in a lagnuage that can be used in the future.  There
> is only one language that can really offer that - FORTRAN.

There are a number of languages that are sufficiently established to
be around with near certainty for a long time. In addition to Fortran,
that's C, C++, and COBOL. Probably also Ada, if only due to the
support of the US DOD.

As for interpreted languages like Python, most of them are implemented
in C, and as long as the source code is open (which is true at least
for Python, Perl, and Tcl), no one prevents you from keeping a
personal copy for an indefinite future.

As a somewhat philosophical note on this topic, let me say that in my
opinion the long-time value of code is often grossly overestimated.
What matters is algorithms, not code. Reimplementing a known and
working algorithm is routine work that takes less and less time as
programming tools improve. In fact, 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. Such an approach
might well be more globally efficient than the current
"keep-it-alive-as-long-as-possible" method.

--------------------------------------------------

David E. Bernholdt:

> 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.

Exactly!

> > 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

I couldn't agree more!

> One can DESIGN software based on these principles (OOD) regardless of
> what language the software is to be implemented in.

Right. But implementing an OO design in a non-OO language requires
a lot of experience and discipline - to be expected of a professional
programmer, but not of a programming scientist.

Of course the more basic problem is that scientists tend to skip
the design phase altogether. Which is why big projects ought to
be started in collaboration with software engineering experts.

> I disagree with the person who proposed C++ is "the" langauge for
> future work because it is an OOL.  There are a lot of other
> considerations that (should) factor into the decision of which
> language to use.  However I think that ALL projects should consider
> object-oriented DESIGN regardless of implementation language.

Again I agree completely.

--------------------------------------------------
Lestaw K. Bieniasz:

> If you need a program for individual purpose, use Fortran if you like it.

Of course. However, don't do one of the following:

1) Force your students and postdocs to use Fortran even if they know
   and prefer something else.

2) Teach your students nothing but Fortran.

Unfortunately, both are standard practice today.

--------------------------------------------------

OK, that's it, sorry for the long post, and back to work...
-- 
-------------------------------------------------------------------------------
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
-------------------------------------------------------------------------------

---

From: [email-masked] (Gabriel Berriz)
Date: Mon, 21 Jul 1997 21:38:07 -0400

While we're on the subject of mixed-language programming, does anyone
know of a book (or any other reference) on Fortran for C programmers?
I have read introductory material on Fortran, and written *teeny*
throaway programs, but I still don't have a very good grasp of the
structure of Fortran programs.  The examples of Fortran code I've seen
look like *nothing* else in my experience (mostly C, Perl, and
Python); I'm not sure what's the point of doing things that way.
Hence, any material on the general structure of Fortran programs
(especially Fortran90), and how it contrasts with the "C paradigm"
would be extremely helpful.  (Unfortunately, there seems to be more
demand and supply for guides to C for Fortran programmers than the
other way around... :/ )

Thanks in advance for your suggestions,

Gabriel Berriz
[email-masked]