The Origins of Object Orientation

Related Sites

This is a widely held misconception. If you read the history of Smalltalk by Alan Kay you will find that he coined the term "object oriented programming" by applying it to his language, Smalltalk, in the early 1970s.

Alan Kay, in his history in the ACM HOPL II proceedings, explains what he means by object-oriented programming. He does base it on the concept of a cell that has a wall. Information passes through the cell wall, but what is on the inside is hidden from what is on the outside. That is the extent of his metaphor.

In the 1960s he observed several software systems that had "cell-like" behavior in the sense that they had encapsulated data and data-independent information moving through the boundary of the encapsulation. These systems he observed included the Sketchpad graphics system, the Simula simulation system, and a Burroughs operating system.

Contrary to popular belief, Simula was not the first object-oriented programming language, and it was not intended to model "the way the world really works". Although as I wrote, it did influence the first OOPL. It was intended to be a simulation programming language. The developers evolved an encapsulation/message like mechanism because it helped them write complex simulations, not because it helped them imitate. They subsequently found that Simula served as a good general purpose programming language because all programs benefit from managing complexity.

Alan Kay did not call OO a model of the real world. Historically, that aspect of OOP came later. Examining the ancient manuscripts will reveal the chronology as opposed to the doctrine.

[...]

Here in Scandinavia we usually describe this as the schism between the Scandinavian (or perhaps European?) approach to object-orientation and the American approach. I'm not sure whether this terminology is used outside Scandinavia, but to me it really seems to describe some deep differences between two `subcultures' of OO which seem to be distributed unevenly across the world map.. :-)

In the so-called Scandinavian approach (originating in Simula), the main point is that programs expressed in an object-oriented manner will be more understandable and manageable for human beings. This is because they build upon the hundreds of generations of human experience embedded in the basic devices of human thinking and abstraction (formation of concepts to describe classes of similar phenomena, organization of concepts in generalization/specialization hierarchies, and specification of part-whole relations and other associations). These devices directly motivate classes, inheritance, polymorphism, and attributes (features/methods/fields/members/..). An important point is that programs should not only work, they should also make sense.

In the so-called American approach there is a stronger emphasis on pragmatic aspects. Reuse by means of inheritance and other mechanisms is emphasized as a central benefit, and encapsulation of state and implementation is advocated because it makes it easier to develop parts of a system without affecting other parts, and because it reduces the complexity that a programmer has to deal with when using an encapsulated entity. On the other hand, it would not necessarily be bad to let `person' inherit from `address' if it happens to do the right thing.

The two philosophies may arrive at overlapping conclusions, e.g., when the "American" tells us not to inherit `person' from `address' because it may limit the potential for reuse, and the "Scandinavian" tells us that encapsulation is a natural requirement for those attributes of a class which are non-representative (i.e., which do not play a role in the modeling relation but are needed in the implementation).

Nevertheless, I still think it makes a fundamental difference whether

- we human beings and our modes of understanding are being considered a crucial premise for programming language design and program design,

- programs are considered in isolation from human beings, as artifacts whose quality should only be measured in purely structural properties, such as the level of reuse and the degree of encapsulation.

Thomas Bergin and Richard Gibson (editors),
History of Programming Languages-II

Jan Rune Holmevik,
The History of Simula

Daniel H. H. Ingalls,
Design Principles Behind Smalltalk