Philosophy Made Manifest - Dueling Languages

Philosophy Made Manifest ”Dueling Languages

Computers ”actually the engineering behind the construction of various hardware devices ”and mathematics are the binary stars around which the world of computer science has revolved for more than fifty years . Programming once was a matter of rewiring . It was a decade before machine-level problems were solved to the extent that we could turn our attention to larger issues of program design. Another decade elapsed before we worked on analysis of applications and systems employing computers and programs. Significant attention is now being paid to the soft issues of usability, human/machine interaction, and even culture.

Despite these advances, whenever a new idea is introduced in computer science, it receives little attention until it has been made concrete and explicit ”frequently as a new programming language ^[1] . Debates about ideas are then transformed into debates of the relative merits of the artifact languages. Arguments about design, analysis, method, and process inevitably follow, but those discussions are more often grounded in the programming language artifacts than in the original ideas. In this process, the original ideas become secondary if they are not lost entirely.

This has certainly been true in the case of the object idea and the programming languages that lay claim to that idea. The most vituperative debates in the object community have tended to center on questions of programming language. The overt focus of those debates has been on programming language features and technical benchmarks. But it is the emotions induced by covert (not consciously hidden, merely assumed and unspoken ) philosophical positions that have accounted for the intensity and the hostility evident in those debates.

Until the appearance of Java and C#, Smalltalk and C++ were the prime contenders for the hearts and minds of object developers. The intensity of argument between advocates of each language is legendary. Both sides tended to see Java as an interloper and tended to criticize those aspects of Java that reflected their more traditional nemesis. Disagreement between Smalltalkers and C++ers gains added interest from the fact that both claim to be the direct heirs of another, older, language, SIMULA.

Behind the Quotes ”Alan Kay, Kristen Nygaard, and Bjarne Stroustrup

Each of these individuals is known for designing and promoting a particular programming language (which we will be discussing shortly). Each individual is also known for many other contributions to the world of software development and computer science.

Alan Kay designed, and Dan Ingalls implemented, the Smalltalk programming language while working at Xerox PARC. After leaving Xerox PARC, they both worked at Apple Computer, where they reinvented Smalltalk and called it Squeak. Squeak underwent further development when both men moved to The Walt Disney Corporation. Today they are independent developers focused on educational applications of the Squeak language and its multimedia capabilities.

Dr. Kay, who received his Ph.D. in computer science from the University of Utah, developed the idea of a Dynabook ” a network-enabled laptop computer with the Smalltalk environment ”also while at Xerox PARC. Arguably, the Pad Computer version of the Microsoft Windows operating system would be ”if coupled with Smalltalk/Squeak ”a pretty close approximation of his ideas.

Kay s biggest contribution was changing the way industry and users think of computers. Before Kay, computers were impersonal tyrants that required you to speak their language and limited their interaction to text-based communications. Kay personalized the machine: he expanded the means of interaction to include graphics, point-and-click, and multimedia using a language designed for humans rather than machines. The PC on your desktop reflects more of Kay s ideas than most people realize.

Kristen Nygaard developed, with Ole Johan-Dahl, the SIMULA programming language, introducing the concepts upon which all later object-oriented programming languages are built: objects, classes, inheritance, virtual quantities , and multithreaded program execution. He was also a social activist greatly concerned with the use of information technology and spent a good part of his career concerned with the social impact of computer technology. His work became the foundation of what today is called the Scandinavian school of system development, closely linked to the field of participatory design.

Nygaard has received the Norbert Weiner prize from Computer Professionals for Social Responsibility (CPSR) for responsibility in social and professional work; the Rosing Prize, awarded by the Norwegian Data Association for exceptional professional achievements; the John von Neumann Medal, awarded by the Institute of Electrical and Electronics Engineers (IEEE); and the A. M. Turing Award, issued by the Association of Computing Machinery (ACM) for 2001. In August 2000, he was made Commander of the Order of Saint Olav by the King of Norway.

Bjarne Stroustrup designed and implemented C++. He pioneered the use of object-oriented and generic programming techniques in application areas where efficiency is at a premium ”for example, switching systems, simulation, graphics, embedded systems, and scientific computation. The C++ Programming Language (Addison-Wesley, 1985, 1991, 1997, and special edition in 2000) has been translated into 14 languages. In addition to his five books, Stroustrup has published more than 60 academic and more popular papers.

Dr. Stroustrup (Ph.D. in computer science from Cambridge University) is an ACM Fellow and has received that society s Grace Murray Hopper award for his work in C++. He is an ATT Bell Labs Research Fellow and an ATT Fellow and currently holds the position of professor at Texas A&M University.

 

SIMULA

SIMULA did not start as a programming language, and during all of its development stages, reasoning outside traditional programming played an important part in its design.

From the very outset SIMULA was regarded as a system description language.... [emphasis Nygaard s]

SIMULA 67, however, was a general-purpose programming language. Was the original purpose abandoned , or did SIMULA have a dual personality ? The latter option is correct. This will be important when we examine what Smalltalk and C++ chose to borrow from SIMULA.

The concept of SIMULA began with an analysis of operations research and the kind of complex systems being modeled and analyzed in that domain. The first goal was to develop a useful and consistent set of concepts for modeling the structure and interaction of elements in complex systems. The initial objectives for the language were as follows :

1. The language should be built around a general mathematical structure with few basic concepts. This structure should furnish the operations research worker with a standardized approach in his description so that he can easily define and describe the various components of the system in terms of these concepts.

2. It should be unifying, pointing out similarities and differences among various kinds of network systems.

3. It should be directing, and it should force the operations research worker to consider all aspects of the network.

4. It should be general and allow the description of very wide classes of network systems and other systems that can be analyzed by simulation, and it should for this purpose contain a general algebraic dynamic language, such as ALGOL or FORTRAN.

5. It should be easy to read and to print, and it should be suitable for communication among scientists studying networks.

6. It should be problem oriented and not computer oriented, even if this implies an appreciable increase in the amount of work that has to be done by the computer.

Perhaps the most dramatic of these objectives was number 6, which is at odds with typical objectives for programming languages: efficiency, speed of execution, smallest possible executable footprint, and more intuitive and useful representations for computer primitives (memory addresses, operation codes, and so forth). Subsequent statements of objectives for SIMULA significantly modified this original goal.

One reason for the change was market driven: The success of SIMULA would, regardless of our insistence on the importance of problem orientation, to a large extent depend on its compile and run-time efficiency as a programming language (Wexelblat, p. 447). The other reason for the change was a perceived lack of conflict between problem orientation and computer orientation. SIMULA s developers discovered that good system description capabilities seem to result in a more simple and logical implementation, thereby reducing the load on the computer s capabilities.

The focus on problem description ”and the resulting simplification of the implementation ”promoted by SIMULA s developers is paralleled in a paper called On Decomposition, by David Parnas. Parnas s paper examined two conceptual abstractions for decomposing complex systems for the purposes of developing software. One was top-down functional decomposition, the approach that was gaining widespread acceptance under the label structured design. Functional decomposition is based on an attempt to model the performance of the computer and software and to translate the requirements of the domain problem into those computer-based constructs.

Parnas offered an alternative approach called design decision hiding, in which the problem or problem domain is modeled and decomposed without consideration of how the component parts of that domain or problem would be implemented. He was able to show that his alternative led to simpler, easier to read, easier to maintain, and more composable software modules than functional decomposition. Unfortunately, his advice was essentially ignored as the juggernaut of structured development came to dominate, at least officially, the manner in which software was conceived and implemented.

Both Parnas and the SIMULA team point to an important principle. Decomposition into subunits is necessary before we can understand, model, and build software components. If that decomposition is based on a natural partitioning of the domain, the resultant models and software components will be significantly simpler to implement and will, almost as a side effect, promote other objectives such as operational efficiency and communication elegance . If, instead, decomposition is based on artificial, or computer-derived, abstractions such as memory structures, operations, or functions (as a package of operations), the opposite results will accrue.

Remember the minor reason for selecting a programming language noted earlier: only if performance mandates cannot be satisfied with effective design is it appropriate to consider selecting a language based on whether it provides more direct access to and control of hardware. Nygaard s and Parnas s observations are consistent with that assertion. Object thinking leads to better designs that reduce the demand placed on the machine, so raw efficiency and speed are far less critical than presumed by most developers.

As the SIMULA team expanded their understanding of the simulation problem domain and of the kinds of systems to be simulated, they identified needs for more generalized and interrelated components. These components had to be implemented, and implementation required adding sophistication to the language, resulting in the ideas of objects, classes of objects, data and implementation hiding, virtual procedures, and inheritance.

The legacy of SIMULA is twofold. First and most important from the perspective of object thinking, it provided an orientation (a philosophy) of giving primary importance to understanding and modeling the problem domain. This philosophy suggested the need for an elegant and powerful language that would allow direct mapping of components in a domain to the modules employed in the computer. Second, a number of original concepts, with appropriate vocabulary (object, class, inheritance), and some important implementation tricks (such as abstract data types and compiler-generated structures) were invented or advanced as the language developed. What use did the inheritors of SIMULA make of this legacy?

C++

Bjarne Stroustrup was motivated by the desire to create a better C. The C programming language is noted for its power and conformity to machine architecture, which ensures that C programs are maximally efficient in terms of machine resources. This same power, however, made its misuse almost inevitable. Bugs were easy to create and difficult to track down. Too many C programmers lacked the discipline necessary to properly use the language. In SIMULA, Stroustrup saw a model for introducing discipline into the C language:

C++ was designed to provide SIMULA s facilities for program organization together with C s efficiency and flexibility for systems programming.... While a modest amount of innovation did emerge over the years, efficiency and flexibility have been maintained without compromise.

Stroustrup was concerned with creating a suitable tool for projects such as the writing of a significant simulator, an operating system, and similar systems programming tasks . His focus was on the machine ”system-level programming ”and on the program. Even though he found SIMULA to be an excellent tool for describing systems and directly mapping application concepts into language constructs, he seemed to be more concerned with performance features of SIMULA than its descriptive capabilities.

SIMULA s class-based type system was a huge plus, but its run-time performance was hopeless:

The poor runtime characteristics were a function of the language and its implementation.... The overhead problems were fundamental to SIMULA and could not be remedied. The cost arose from several language features and their interactions: run-time type checking, guaranteed initialization of variables , concurrency support, and garbage collection....

SIMULA was conceived to make it easier to describe natural systems and simulate them in software, even if that meant the computer had to do more work. The inefficiencies noted by Stroustrup were indeed intrinsic to the language and the paradigm created by SIMULA. Stroustrup essentially rejected the SIMULA philosophy because his problem domain was the computer itself and performance was the primary goal:

C with Classes [ precursor to C++] was explicitly designed to allow better organization of programs; computation was considered a problem solved by C. I was very concerned that improved program structure was not achieved at the expense of  run-time overhead compared to C. The explicit aim was to match C in terms of run time, code compactness, and data compactness. To wit: someone once demonstrated a three percent systematic decrease in overall run-time efficiency compared with C. This was considered unacceptable and the overhead was promptly removed.

C++ maintained the goal of adding program structure without a loss of performance. The constant measure of the language was the machine, either the physical computer platform or the virtual machine ”the program. This constant focus on performance limited what could be borrowed from SIMULA ”most important, SIMULA s goal of being a general systems description language.

Although the claim is made that C++ is a general-purpose programming language, that assertion should be modified. C++ is a general-purpose language for describing and efficiently implementing programs that model software implementation constructs (for example, control structures, data structures, and algorithms), virtual machines, or hardware elements.

The focus on the machine is C++ s greatest strength and its greatest weakness. Stroustrup explicitly rejected the philosophy and values behind SIMULA and merely borrowed some of its implementation tricks, thereby creating a language that inhibits the direct expression of application designs in any domain except that of the computer itself. The simple and logical implementations observed by Nygaard and advocated by Parnas of noncomputer problem domain designs cannot be expressed in C++ without some degree of compromise with those principles upon which the language is predicated.

Smalltalk

Philosophically, Smalltalk s objects have much in common with the monads of Leibniz and the notions of 20th century physics and biology. Its way of making objects is quite Platonic in that some of them act as idealizations of concepts ”Ideas ”from which manifestations can be created. That the Ideas are themselves manifestations (of the Idea-Idea) and that the Idea-Idea is a-kind-of Manifestation-Idea ”which is a kind-of -itself, so that the system is completely self-describing ”would have been appreciated by Plato as an extremely practical joke.

Alan Kay describes Smalltalk as a crystallization of style language, one that is an expression of the insight that everything we can describe can be represented by a single kind of behavioral building block ”in essence, an object. From the outset, Kay is characterizing Smalltalk as deriving from the same goals that motivated SIMULA ”a desire to have a simple and expressive language for describing and representing (simulating) naturally occurring complex systems.

Object-oriented design is a successful attempt to qualitatively improve the efficiency of modeling the ever more complex dynamic systems and user relationships made possible by the silicon explosion.

Note the absence of any reference to computer or program efficiency or organization. When Kay first encountered SIMULA and its objects and object manipulation constructs, he experienced a kind of epiphany, as ideas from mathematics, philosophy, and biology came together.

Bob Barton had said... The basic principle of recursive design is to make the parts have the same power as the whole. For the first time I thought of the whole as the entire computer and wondered why anyone would want to divide it up into weaker things called data structures and procedures. Why not divide it  up into little computers. ... I recalled the monads of Leibniz, the dividing nature at its joints discourse of Plato, and other  attempts to parse complexity. ... It is not too much of an exaggeration to say that most of my ideas from then on took their roots from SIMULA ”but not as an attempt to improve it. It  was the promise of an entirely new way to structure computations that struck my fancy.

Another major stream of influences that shaped the development of Smalltalk was education and cognitive theories ”ideas about how people (often children) think or can be encouraged to develop thinking skills. The computer, for Kay, promised a potential vehicle for supporting and promoting thinking, the foundation for an alternative advocated by Marvin Minsky.

It was clear that education and learning had to be rethought in  the light of 20th century cognitive psychology and how good thinkers really think. Computing enters as a new representation system with new and useful metaphors for dealing with complexity, especially of systems.

Although Kay s account of the origins of Smalltalk addresses issues of machine efficiency (almost always in the context of making performance conform to human user expectations for dialog) and compactness (an overriding goal was to create a Dynabook or at least a notebook computer), the goals of machine efficiency and compactness are overwhelmed by other goals. Expressiveness in describing complex systems, support for education and dialogic interaction between children and machines, and even a search for beauty in programming languages are important examples.

One part of the perceived beauty of mathematics has to do with  a wondrous synergy between parsimony, generality, enlightenment, and finesse. ... When we turn to the various languages for specifying computations, we find many to be general and few to be parsimonious. For example, we can define universal machine languages in just a few instructions that can specify anything that can be computed. But most of those we would not call beautiful, in part because the amount and kind of code that has to be written to do anything interesting is so contrived and turgid. ...

A fertilized egg that can transform itself into the myriad of specializations needed to make sure a complex organism has  parsimony, generality, enlightenment, and finesse ”in short, beauty. ... Nature is wonderful at both elegance and practicality ”the cell membrane is partly there to allow evolutionary kludges to do their necessary work and still be able  to act as components by presenting a uniform interface to  the world.

Alan Kay clearly was not interested so much in what went on inside the machine as in how the existence of the machine redefined the act of communication between person and machine. He saw the personal computer as a potentially liberating and creative device, but its potential impact was inhibited by the mode of communication. He saw that a better language , not programming language, was required.

We should derive two lessons and one assertion from this brief historical retrospective:

• Lesson     The true differences among programming languages are those that reflect philosophical ideals and values. Those values and ideals, in turn, determine the degree to which a language naturally and simply expresses design concepts without resorting to contrived and turgid code.

• Lesson     If you think about design using an implementation language ”as programmers and especially extreme programmers are wont to do ”your designing will be enhanced or severely restricted by that language.

• Assertion     If your development project involves modeling, designing, and solving problems in the domain defined by the boundaries of the computer itself (for example, operating systems, device drivers, network infrastructure), you will best be served by languages such as C++, C#, and Java. If, like the vast majority of software developers, you are interested in modeling, designing, and solving problems in an application space, you will be far better served by languages such as Smalltalk, Lisp, FORTRAN, COBOL, and Visual Basic (with Smalltalk and Visual Basic being generally applicable to a wider variety of application domains).

Of course, choice of language is not the only implementation decision that affects design in a particular way. The decision to employ a relational database is an implementation decision with the same kind of implications as selecting a language. Consider the following example. A customer in the real world might use many different addresses for different reasons. A domain-reflective object model might have the partial diagrammatic representation in Figure 2-1. Address is a collection ”a recurring field ”and therefore, according to the dictates of relational database design, cannot be an attribute of Customer . In fact, we have to create two entities with a relationship between them, as shown in Figure 2-2.

Figure 2-1: Domain-reflective customer model (partial).

Figure 2-2: Relational customer model (partial).

In a store I might ask a customer, Where would you like your purchase delivered? The customer would think a bit and give me back an address. But in the relational example, I cannot ask the customer this question because the customer does not know the answer. Instead, I have to ask the customer for his customer number and then ask the collection of addresses in the Address relation, Which of you belongs to customer custNo and also has the type value delivery ? The implementation code gets even more contrived and turgid when I attempt to account for the fact that the customer might want to use different delivery addresses at different times or for different situations. Analogous design problems occur when you use strongly typed languages ”the real world is pretty fuzzy when it comes to classification ”or other constructs that effectively represent the computer but not the application domain.

Programming languages are concrete manifestations of a set of values, ideals, and goals, which in turn reflect a more inclusive worldview or philosophical context. Sometimes the language designer makes explicit philosophic decisions, as did the three language developers just discussed. At other times, the philosophy that shapes the programming language is invisible even to the designer. Designers are humans and participate in a human culture. Most humans are oblivious to their own culture: as the saying goes, as blind to their own culture as a fish is to the water in which it swims. It would be expected, therefore, that the general culture in which language designers live and work also plays a role in shaping the design of the language. And programming languages are not the only artifact shaped by a prevailing culture. So too are methods , processes, and even models.

Note  

The philosophy behind Smalltalk (and object thinking) does not make the problem of selecting a correct address trivial, nor does it solve problems with classification, but it does lead you in the direction of simpler-to-implement and easier-to-modify solutions. For example, we ask a human customer, Where would you like this shipped? Object thinking suggests we create a customer object that can respond to essentially the same message: shipTo . We assume that the customer has a  collection of possible addresses in mind and a rule that they employ to  decide which address to use. We probably assume that the rule is context sensitive in some way, evaluating to different addresses at different times. If we simulate all three of these objects ” Customer , addressCollection , and selectionRule ” and distribute the problem of which address? across the three, the solution is far simpler than what would be necessary using a relational schema and an SQL query. The classification problem is finessed, in a way, rather than solved by object thinking and Smalltalk philosophy, which suggests that the real world is fuzzy and any kind of hard-and-fast classification should be avoided unless absolutely necessary. (Protecting programmers from making errors is not an absolute necessity.) And when making classifications, use set criteria that are intrinsic (such as DNA) instead of extrinsic (such as presence of hair, warm blood, and lays eggs).

We now return to an issue raised at the very beginning of this chapter: why is XP perceived as a radical departure from accepted practice, and why does it evoke such strong reactions ”both positive and negative ”from software development practitioners and theorists? The answer to this question lies in the philosophical context within which software development emerged.

Given that most of computing and software development emerged in the Western world, ^[2] a common worldview or philosophical context might be assumed. If this were true, all programming languages, methods, approaches, tools, and processes would share a common, albeit deeply hidden, philosophical foundation.

This is clearly not the case. Every culture contains variations, or subcultures, which exist at various levels of scale. In the next section, we ll explore two competing philosophical themes that have long been present in Western culture.

^[1] All of the quotations regarding SIMULA, Smalltalk, and C++ languages are taken from the respective chapters in ACM History of Programming Languages , ACM Press, 1978, Richard Wexelblat (ed.), or History of Programming Languages II, Addison-Wesley, 1996, Thomas J. Bergin Jr. (ed.).

^[2] This is a historical observation, not an expression of ethnocentrism or an attempt to claim computing for Europe and the United States. As will be seen in the rest of the discussion, this is more of an indictment of the history of computing than a boast. Clearly the roots of computing and many of the most important contributions to our understanding of computing come from many different places and cultures. The argument will be made in the next few pages that most of computing, however, is firmly grounded in a philosophical tradition that arose in Europe and formed the foundation of the Age of Reason.