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

 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: hinsen at.at ibs.ibs.fr
 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
 -------------------------------------------------------------------------------