Scientific Computing and Software Engineering
C++ Programming Language
Open Source

(see also recommended readings)

Scientific Computing and Software Engineering

Have you ever...

    wasted a lot of time coding the wrong algorithm?
    used a data structure that was much too complicated?
    tested a program but missed an obvious problem?
    spent a day looking for a bug you should have found in five minutes?
    needed to make a program run three times faster and use less memory?
    struggled to move a program from a workstation to a PC or vice versa?
    tried to make a modest change in someone else's program?
    rewritten a program because you couldn't understand it?

Was it fun?
Kernighan and Pike, The Practice of Programming, Preface

Naively, one might expect that scientific applications development and C++ would
be a natural union. C++ provides excellent support for object-oriented
programming, abstraction, and encapsulation. Moreover, scientific computational
modeling-both simulation of physical systems and abstract mathematical
analysis-is replete with structure. Expressing this structure and abstraction in a
language with direct support for the construction of user-defined types that model
the application domain is therefore a powerful attraction for a growing number of
computational scientists. [...]
exciting days for C++. Long dismissed in scientific circles owing to criticisms
ranging from performance consideration to quality-of-implementation issues,
recent developments in compiler technology and programming techniques are
changing the face of scientific C++. The language is now directly competitive with
Fortran in performance metrics, while maintaining far superior support for the full
range of modern programming paradigms: from structured programming
techniques to object-oriented programming, and most recently, generic
Geoffrey Furnish, C++ Report, May 2000

C++ Programming Language

There is nothing profound about this program fragment.
Every line of it bears an obvious relationship to the
problem that it is trying to solve, unlike in the C fragment,
there are no hidden bookkeeping conventions. And that is
exactly the point.
All the bookkeeping can be isolated
in the library, debugged once, and then forgotten. The rest
of the program can concentrate on solving the problem.
Koenig and Moo, Ruminations on C++, p. 17

My C++ programs are so reliable because I can put much more of
my ideas directly into C++ class definitions than into anything
I could have written in C. Once the class definition is right,
I have no choice but to use it in the way I intended when I wrote
it. Thus, I think of C++ as helping me keep my ideas straight
and holding me to my word.
Koenig and Moo, Ruminations on C++, p. 21

Much of C++ is [...] concerned with abstractions and interfaces.
The key behind it all is to be able to break a problem into pieces
that can be pursued independently. Instead of the pieces being
connected by conventions, they are connected by class definitions
and by calls to member and friend functions. Failure to observe
the conventions is met by an immediate diagnostic message from the
compiler, instead of by a program that fails with obscure symptoms.
Koenig and Moo, Ruminations on C++, p. 27

Open Source

The basic idea behind open source is very simple. When
programmers on the Internet can read, redistribute, and modify
the source for a piece of software, it evolves. People improve it,
people adapt it, people fix bugs. And this can happen at a speed
that, if one is used to the slow pace of conventional software
development, seems astonishing.
www.opensource.org, Introduction

Increased reuse of code and design is often cited as a major reason for
adopting a new programming language or design strategy. However, most
organizations reward individuals and groups that choose to re-invent
the wheel. [...]
Reuse is primarily a social phenomenon. I can use someone else's software
provided that:
[1] It works: to be reusable, software must first be usable.
[2] It is comprehensible: program structure, comments, documentation, and
tutorial material are important.
[3] It can coexist with software not specifically written to coexist with it.
[4] It is supported (or I'm willing to support it myself; typically, I'm not).
[5] It is economical (can I share the development and maintenance costs with
other users?).
[6] I can find it.
My experience is that the conditions necessary for reuse will exist only
if someone makes it their business to make such sharing work. In a small group
this typically means that an individual, by design or by accident, becomes the
keeper of common libraries and documentation. In a larger organization, this
means that a group or department is chartered to gather, build, document,
popularize, and maintain software for use by many groups.
The importance of such a ``standard components'' group cannot be overestimated.
Note that as a first approximation, a system reflects the organization that
produced it. If an organization has no mechanism for promoting and rewarding
cooperation and sharing, cooperation and sharing will be rare. A standard
components group must actively promote its components. This implies that good
traditional documentation is essential but insufficient. In addition, the
components group must provide tutorials and other information that allow a
potential user to find a component and understand why it might be of help.
This implies that activities that are traditionally associated with
marketing and education must be undertaken by the components group.
Bjarne Stroustrup, The C++ Programming Language, 23.5.1 Reuse

Last modified: Oct 31 2000