Chapter 2: Philosophical Context

Overview

More often than not, the first question programmers ask when embarking upon a new development project is, What language will be used for implementation? There is usually no need to ask about method because some variation of a formal structured approach is assumed. This is a very unfortunate situation.

The rising popularity of extreme programming (XP) and agile development makes the method question an open one ”again. I say again because in terms of observable actions, XP and agile approaches are just the latest incarnation of iterative development. Some form of iterative development has been practiced in software since the 1960s and has usually been held to be superior to the structured waterfall approach that is officially practiced. And yet, when XP was proposed about four years ago, management and most practitioners reacted as if it were a radical departure from accepted and acceptable practice. Later in this chapter, we ll look at the philosophical context behind this reaction. But first it s useful to explore how philosophy shapes the development and utility of programming languages.

Whatever the answer to the programming language question, it is almost always given for the wrong reasons. Even worse , it is given for reasons that are never articulated and therefore never subject to reasoned judgment. Common reasons (not necessarily expressed out loud) for adopting a programming language include, in no particular order, the following:

• Loyalty     We are a Microsoft shop; we use Visual Basic (or, today, Visual C#).

• Bandwagon     Everyone is doing Java.

• Economics     Java programmers are a dime a dozen and completely interchangeable ”if we lose one, we can find a replacement easily.

• Culture     You can t do telecom/real-time/embedded applications in anything except C++.

• Resum     All the job ads ask for C# experience, so I had better get some exposure.

• Inertia     I wrote my first program in COBOL and am most familiar with COBOL, so COBOL is the right language for this project. Using COBOL makes it easier for me to manage the project.

Given that all programming languages are ultimately equivalent ” anything you can do, I can do also ”are there any legitimate reasons for selecting one language over another? I would suggest three:

• Pragmatics     Mature libraries, compatibility with external systems (if you want to be a supplier to Wal-Mart, you make your systems compatible with theirs), availability of labor force, or other economic reasons. However, my professional experience suggests that 70 to 80  percent of the pragmatic cases made for a particular language have been rationalizations, not rationales. The pragmatic case has usually been a surrogate for loyalty, bandwagon, and similar reasons.

• Performance     If, and only if, performance mandates cannot be satisfied with effective design, it might be appropriate to select a language that provides more direct access to and control of hardware. Here again, performance is more often than not an excuse and not a reason. It s possible to build hard real-time embedded systems using slow and cumbersome languages such as Smalltalk without paying any performance penalty compared with C or C++ implementations . It takes excellent design and the occasional programming trick (precompiling methods , for example), but performance is rarely a true reason for selecting a particular implementation language.

• Philosophy     Programming languages are created for a reason. Language designers have specific intentions for their language, and those intentions are grounded in and shaped by particular philosophical values and ideas. Developers and development teams should select an implementation language that has been shaped by  philosophical ideas and ideals similar to their own and to their problem space.

The philosophy implicit in the implementation language should be the reason for selection. There are some problems with putting this dictum into practice. Most developers, especially programmers, might be quite surprised that philosophy plays any role, let alone a critical role, in language design because few have had the occasion or opportunity to explore the ideas behind languages. Most object developers are not conversant with the philosophy of objects ”the subject of this book ”and are therefore in a poor position to select an implementation language reflective of object philosophy.

Developers who specialize in software for large-scale switching networks (such as the phone system) should choose a language such as C because the ideas and ideals that shaped that language are the same ones that shape the thinking of developers working in that problem domain. (Even C++ will be seen as an intrusion by those developers.) Scientific or engineering number crunching ? No reason not to use FORTRAN. Business applications? COBOL or Visual Basic is perfectly fine.

Philosophical compatibility will allow you to be more expressive than if you are trying to translate your thoughts into a foreign language because your thoughts will naturally flow into the syntax of the implementation language.

Note  

Every programmer has a first language ”the one she learned first and used most. Most programmers have occasion to learn additional languages during their careers. Languages can be classified into families like procedural (C, COBOL, PASCAL) and declarative (Lisp, Prolog). Learning a new language within a family is relatively easy (Java in 40 hours, if you learned Pascal first; however, learning a language across families is quite difficult (C programmers learning Lisp). Object languages like Smalltalk proved most difficult for expert C programmers and expert database developers precisely because it required them to cross language family lines. Unless the programmer also learns a great deal of idiom and convention (not included in the formal syntax of the language or even in its libraries), she will continue to write (for example) COBOL using Java syntax.

Developers might, initially, be surprised at the significant and often hidden role played by philosophy. Many, if not most, have experienced moments of frustration when a language provided no direct and obvious way to express the ideas they had in their heads. Such moments are frustrating precisely because the true source of friction is hidden ”it s based on unstated philosophic incompatibilities. On the other hand, many programmers have experienced the exhilaration that comes when design thinking and implementation language are compatible and productivity soars. (Users of script languages for Web development are likely to enjoy this type of experience.)

On a macroscopic level, it s impossible to truly understand the acrimony and the bitterness of the debates about object programming languages without looking beyond the languages themselves to the philosophy implicit in those languages. In the case of object language debates, the philosophic problem is twofold: first, very few people have explored the philosophy behind the languages claiming to be object-oriented (even though that history is well documented); second, few have understood object philosophy, making it difficult to match that philosophy with the one behind a given programming language. A short foray into the history of three languages of particular interest to object thinkers ”SIMULA, C++, and Smalltalk ”will illustrate the problem.