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. [...] PROMOTING THE REUSABILITY OF SCIENTIFIC C++ These are 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 programming. |
Geoffrey Furnish, C++ Report, May 2000 |
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 |
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 |