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

From: "W. R. Smith" <[email-masked]>
Date: Fri, 11 Jul 1997 09:37:27 -0400

Hello again,

At 12:25 PM 7/11/97 +0200, Konrad Hinsen wrote:
>>   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.

i.e. Fortran can be OO too.

A quote by a distinguished scientist that I recall from a scientific
meeting about 10 years ago:

"I don't know what type of programming language scientists will be using in
the next millenium, but it will be CALLED Fortran"

i.e. Fortran will evolve over time to incorporate newly desired features 

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

Note also that Microsoft seems to have dropped Fortran support - passed it
on to DEC, it would appear.

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

e.g. a Visual Basic front-end with Fortran or C .DLL's

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

No slight against Python, but we all remember the following historical
sequence:

Algol  vs Fortran (1960's)
PL1    vs Fortran (1970's)
Pascal vs Fortran (1980's)

and now, it's

C      vs Fortran  

On the left-hand side, it has usually been CS (computer-science) types.  On
the RH side, it has usually been scientists/engineers.

>
>-------This is added Automatically by the Software--------
>-- Original Sender Envelope Address: [email-masked]
>-- Original Sender From: Address: [email-masked]
>[email-masked]: Everybody | [email-masked]: Coordinator
>[email-masked]: HELP CHEMISTRY or HELP SEARCH | Gopher: www.ccl.net 73
>Anon. ftp: www.ccl.net   | [email-masked] -- archive search
>             Web: http://www.ccl.net/chemistry.html 
>
>
>
-- W. R. Smith, PhD, P. Eng., Senior Scientist, Mathtrek Systems --
3-304 Stone Road West, Suite 165, Guelph, Ontario CANADA N1G 4W4
EMail: [email-masked]       Tel:519-763-1356,FAX:519-763-4525
--------------------- http://www.mathtrek.com ---------------------
-Mathtrek Systems - Home of EQS4WIN Chemical Equilibrium Software -

---

From: "nick.c" <[email-masked]>
Date: Fri, 11 Jul 1997 09:22:18 -0800

>>>     code should be built in C/C++ (IMHO).  I respect the fact that a huge

      ("undefensible"... I gotta stop posting articles after midnight... :-)

>i.e. Fortran can be OO too.

   I respectfully disagree.  I'm no language theory expert, but my
     understanding is Fortran isn't OOP (for reasons I've already
     posted).  For that matter neither is C (I believe Konrad
     said exactly this).

   The only reason I mentioned C in the first place, was by way of
     a disclaimer.  Each job is unique, and sometimes C++ is
     not the best way to solve the problem at hand.  Frequently
     I find a procedural solution is sufficient or preferable.
     For that matter, in many cases Fortran is probably the way
     to go on a specific project.  Issues of what compilers are
     available for a platform, what programming languages your
     team is comfortable with, what legacy code you have available,
     who you're going to turn the code over to for maintenance,
     how fast your dev cycle is, what your budget looks like,
     does your customer have a preference, which way the wind
     is blowing, and others end up deciding how a project is
     going to get coded.  That said, C++ offers tremendous benefits
     for managing large projects.  C++ has unique and powerful
     resources for easily reusing and improving on old code--
     even that piece of code that you had no idea you were going
     to ever need to reuse, and so would not have made modular
     if you were using C or Fortran.  It's the industry standard:
     there's a C++ compiler for every platform, there are huge
     commercial libraries of classes, there is a wealth of
     books, formatting tools, class browsers, visual development
     tools, and other neat toys for the C++ set.

   Anyway, I'm not going to convince anyone here that C++ is the
     "next-great-thing" (I think Java might have that title by
     now anyway :-), but I would strongly encourage anyone starting
     a new project to at least weigh the benefits of the C++ language
     against the speed of recycling Fortran legacy.  That code is
     going to wear out sometime, the only question is: do you want
     to rewrite it in C++ now, or two years from now when it's
     that much larger?

>the next millenium, but it will be CALLED Fortran"

    Hm... Algol 60 was influenced by Fortran.  C derived from BCPL, which
      came from CPL, which is Algol 60 based.  C with Classes and C++
      are OOP implementations of C.  One could argue that C++ is just
      a new flavor of Fortran, and who knows--maybe when 2000 rolls
      around and we'll all be calling it Fortran00 (or maybe FortranOO :-)

>the RH side, it has usually been scientists/engineers.

    Maybe.  Still I think the distinction between "computer-science types"
      and "scientist/engineer" types is getting increasingly slight.  I also
      think you're bumping into a whole new generation of scientists, many of
      whom learned C before they found out what a d orbital was.  It's not
      a matter of learning a programming language to solve a problem in science
      (and thus being influenced by the language choice of your advisor or
      the legacy code lying around the lab, like in 60's and 70's).  Many
      new college students already know how to program--and frankly most
      grade schools, high schools and JC's are pushing C/C++, not Fortran.
      Add to that the portion of your faculty who graduated in '85 and
      are hard core C++ fanatics (Pascal wasn't the only thing pushing on
      Fortran in the 80's :-).  Explaining the value of Fortran to new
      college students these days is a lot like trying to explain why
      TVs didn't always have remote controls.  I tip my hat to Fortran, I
      tipped my hat to Ali, but it was pretty clear when Ali stepped into
      the ring for the last time, that it was the last time.  It looks
      like Fortran has run it's course as well.  Dunno what the next great
      thing will be: Objective C, Java, C++.  Dunno.  But if you like,
      you *can* still call it Fortran :-)

____Nicholas C. DeMello, Ph.D.________________________________________
   Online at MacTech Magazine, the Journal of Macintosh Programming
     http://www.MacTech.com/
                                       _/   _/  _/  _/_/_/   _/   _/
  Chemistry: [email-masked]       _/_/ _/  _/  _/   _/  _/_/_/
    MacTech: [email-masked]      _/ _/_/  _/  _/       _/ _/
       http://www.chem.ucla.edu/~nick/   _/  _/   _/_/_/  _/   _/