From hinsen@lmspc1.ibs.fr Fri Jul 11 07:11:13 1997 Received: from ibs.ibs.fr for hinsen@lmspc1.ibs.fr by www.ccl.net (8.8.3/950822.1) id GAA05957; Fri, 11 Jul 1997 06:25:16 -0400 (EDT) Received: from lmspc1.ibs.fr (hinsen@lmspc1.ibs.fr [192.134.36.141]) by ibs.ibs.fr (8.6.12/8.6.12) with ESMTP id MAA06337; Fri, 11 Jul 1997 12:26:28 +0200 Received: (from hinsen@localhost) by lmspc1.ibs.fr (8.8.5/8.8.5) id MAA21755; Fri, 11 Jul 1997 12:25:14 +0200 Date: Fri, 11 Jul 1997 12:25:14 +0200 Message-Id: <199707111025.MAA21755@lmspc1.ibs.fr> From: Konrad Hinsen To: online@mactech.com CC: chemistry@www.ccl.net In-reply-to: (online@mactech.com) Subject: Re: CCL:Object-oriented means for computational chemistry programming > But, in a completely undefensible statement of preference: today, new > code should be built in C/C++ (IMHO). I respect the fact that a huge I don't disagree in principle, but a few clarifications can't hurt (which are of course largely my personal opinion!): - C is no more OO than Fortran, but it doesn't have most of Fortran's most severe problems. But Fortran-90 is no worse than C, and in some respects better. - The main advantage of C is support: there is a C compiler for every imaginable machine, and there are plenty of high-quality libraries. But there is little support for numerical work, and indeed many C compilers are rather bad at optimizing standard numerical code. - C++ is an exceedingly complicated language, largely due to its compatibility to C. It may seem simple at first, but the more you get into the details the more surprises you will find. Worse, there is a frightening number of "undefined" situations, meaning that the meaning of certain pieces of code is compiler dependent. Writing solid and portable C++ code requires a lot of experience. The payoff may be worth it for professional programmers, but most scientists are not professional programmers. The bottom line: no single language is perfect. I think scientists should get used to the idea of mixed-language programming. For a small number-crunching subroutine the best choice may well be Fortran, but for the majority of a non-trivial program it certainly isn't. But all modern operating systems have provisions to link code in different languages together. Scientists should also have a closer look at high-level languages. They make development and testing substantially easier by taking care of much detail automatically. Of course that comes at a price in terms of speed, but the majority of a typical scientific program is *not* time-critical. The CPU intensive parts are specific subroutines that can still be implemented in a low-level language. My personal recommendation for a high-level language is Python. It is sufficiently simple, has a clear syntax, and a very convenient interface to low-level languages. For C code, a Python interface can even be generated automatically with a tool called SWIG. More on Python at http://www.python.org, and on my "Python for Science" page at http://starship.skyport.net/crew/hinsen/. Finally, for those who don't mind a trip to San Jose, the 6th International Python Conference from 14-17 October in San Jose will have tutorials, presentations, and discussions on scientific applications of Python. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@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 -------------------------------------------------------------------------------