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

From: "nick.c" <[email-masked]>
Date: Thu, 10 Jul 1997 21:18:21 -0800

>        Who says FORTRAN cannot be "object-oriented"?  How about Windows
>FORTRAN .DLL's, or other types of FORTRAN libraries?  Please enlighten me
>if I'm off-base, but it seems to me that the entire "object-oriented thing"
>is simply a modern version of what we used to call a "subroutine" in
>FORTRAN.  The only difference is that one must adopt an accepted convention
>to define the ways in which the "object" \equiv "subroutine" communicates
>with the outside world.

   My understanding is that (despite popular opinion) "object-oriented"
     does mean more than information hiding.  Specifically, a language
     is object-oriented if and only if it supports three features of the
     object-oriented paradigm: objects, classes, and inheritance.

   If you have a copy of Cline and Lomow's C++ FAQ's (ISBN 0-201-58958-3),
     check out FAQ #11 on page 7 he talks about what OOP is and what
     each of these features are.  An object is definitely more than
     a subroutine (although I guess it is fair to compare it with
     a code module in C, Fortran, or any other programming construct
     which contains both data storage and functions for manipulating
     that data).  Hmm... those of you who don't have the book handy can
     check out Marshall Brain's _Understanding C++_ pages:
         <http://www.iftech.com/oltc/cpp/cpp1.stm>  Marshall writes:

__quote on__

C++ is an "object oriented" language. Object oriented programming is a
reaction to programming problems that were first seen in large
programs being developed in the 70s. All object oriented languages try
to accomplish three things as a way of thwarting the problems inherent
in large projects:

        1.  Object oriented languages all implement "data
            abstraction" in a clean way using a concept called
            "classes". We will look at data abstraction in much more
            detail later because it is a central concept in C++.
            Briefly, data abstraction is a way of combining data
            with the functions used to manipulate the data so that
            implementation details are hidden from the programmer.
            Data abstraction makes programs much easier to maintain
            and upgrade.

        2.  All object oriented languages try to make parts of
            programs easily reusable and extensible. This is where
            the word "object" comes from. Programs are broken down
            into reusable objects. These objects can then be grouped
            together in different ways to form new programs.
            Existing objects can also be extended. By giving
            programmers a very clean way to reuse code, and by
            virtually forcing programmers to write code this way, it
            is much easier to write new programs by assembling
            existing pieces.

        3.  Object oriented languages try to make existing code
            easily modifiable without actually changing the code.
            This is a unique and very powerful concept, because it
            does not at first seem possible to change something
            without changing it. Using two new concepts however
            --inheritance and polymorphism-- it is possible to do
            just that. The existing object stays the same, and any
            changes are layered on top of it. The programmer's
            ability to maintain and adjust code in a bug-free way is
            drastically improved using this approach.

__quote off__

  Bottom line: Fortran ain't OOP.  That doesn't mean it's not a great
    language... heh... :-)  Well, I'm not going to go there.

  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
    body of legacy code for comp chem exists in FORTRAN, but I tend to
    agree with Taisung.  The OOP paradigm developed in response to
    specific demands of the industry.  The expectations of users have
    incresed--will increase--exponentially, the ambitions of programmers
    have accelerated even faster, and I (JMO) honestly don't think
    FORTRAN is cabable of continuing to support the increasinly complex
    and expansive programs that folks want to weave.  Just my opinion.

____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/   _/  _/   _/_/_/  _/   _/

---

From: Konrad Hinsen <[email-masked]>
Date: Fri, 11 Jul 1997 11:59:56 +0200

> is simply a modern version of what we used to call a "subroutine" in

No, not at all. Object-oriented design/programming refers to a
technique of program design that structures non-trivial code around
the data, not around the control flow, as in traditional
procedure-oriented programming.

Object-oriented languages are those which actively support
object-oriented programming. (Note that merely enabling it is not
sufficient; you can implement object-oriented designs in C, but that
doesn't make C object-oriented). That definitely excludes Fortran-77.

The classification of Fortran-90 is less clear, since it allows the
definition of data types to some extent. However, most definitions
of "proper" OO languages postulate support for several fundamental
techniques (like inheritance), and by that definition Fortran-90
isn't OO either.

> to define the ways in which the "object" \equiv "subroutine" communicates

Objects are pieces of data, so the closest analog in Fortran are
arrays (since there are no other data structures).

Objects are defined by the operations allowed on them. For example,
a "matrix" object is defined by the mathematical operations addition,
product, inversion, element access, etc. In the actual implementation,
the operations resemble classical subroutines. But there are lots
of important differences in detail.
-- 
-------------------------------------------------------------------------------
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: Konrad Hinsen <[email-masked]>
Date: Fri, 11 Jul 1997 12:25:14 +0200

>     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: [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: Fri, 11 Jul 1997 10:40:17 -0400

Date: Fri, 11 Jul 1997 12:25:14 +0200
   From: Konrad Hinsen <[email-masked]>

   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.
(And coding with incomplete or inaccurate information will almost
certainly fail to yield faster programs.)  Or have I just had bad
luck?

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.

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
you said, most scientists are not professional programmers, and they
are naturally more interested in their science, so they will settle
for the slower code.  Besides, as one colleague of mine puts it, is it
really worth it to spend about half one's time keeping one's skills as
a computational ace well honed, and writing more complicated, but
highly optimized code, so that one's programs run at most twice, more
likely 110%, as fast?  Probably not.  Ultimately, most folks are more
concerned with optimizing their time use than the computer's :-) .

Regarding C++, and independent of its flaws and virtues, judging by
the ratio (about 9:1) of C++ books to C books at my local bookstore, I
expect C++ will displace C as the "standard" programming language in a
few years (if it hasn't already).  Sad but true.

G. Berriz
[email-masked]

---

From: Mike Kotelyanskii <[email-masked]>
Date: Fri, 11 Jul 1997 11:18:09 -0400 (EDT)

Well, there is a difference. If you ever saw a description of Pascal with 
OOP or C++ you would have noticed, that object is hot just a subroutine.
It is a way to encapsulate data AND functions together. It is very useful
for code development for large projects. If the set of objects is wisely
designed it would take a minimal amount of work to introduce changes.

But, of course whatever can be done with OOP can also be done
without it. It just a matter of programming style and discipline.
OOP sort of does it for you. And I think performance is what you pay for 
it.

Mike

-------------------------------------------------------------------------------
Michael J. Kotelyanskii				Phone (814) 863 43 81
Polymer Science Program				FAX   (814) 865 29 17
Department of Materials Science and
Engineering                                     [email-masked]
Pennsylvania State University
University Park, PA 16802, USA
--------------------------------------------------------------------------------

On Thu, 10 Jul 1997, W. R. Smith wrote:

> Hello,
> At 11:10 AM 7/10/97 +0200, Konrad Hinsen wrote:
> >> FORTRAN still remains the main programming language of computational
> >> chemistry. But 
> >> I wonder if anybody knew about the programs where methods computational
> >> chemistry and, in particular quantum mechanical (ab initio or
> >> semiempirical), MM or QM/MM force field methods are developed by means of
> >> object-oriented languages (C++ preferably). I know Hyperchem is announced
> >
> 
> -- 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 -
> 
> 
> -------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 
> 
>