Smalltalk (828/sma009) |
 |
Software Concepts Group, Xerox PARC, led by Alan Kay, early 70's. Took the concepts of class and message from Simula-67 and made them all-pervasive, the quintessential object-oriented language. Innovations included the bitmap display, windowing system and use of mouse.
the pioneering OOP system developed by the Software Concepts Group, led by Alan Kay, at Xerox PARC. It includes a language (usually interpreted), a programming environment, and an extensive object library. SMALLTALK took the concepts of class and message from SIMULA 67 and made them all pervasive. The syntax is very simple. The fundamental construction is to send a message to an object. Innovations include the bitmap display, windowing system, and the use of the mouse. Does not have multiple inheritance so each class can have at most one superclass. According to the Webopedia, "Although it never achieved the commercial success of other languages like C++ and JAVA, many consider it to be the only true OOPL, and the one by which all others must be measured.
People:
Structures:
Related languages
| CDL | => | Smalltalk | Influence | |
| FLEX | => | Smalltalk | Evolution of | |
| Smalltalk | => | Actalk | Dialect of | |
| Smalltalk | => | Alltalk | Extension of | |
| Smalltalk | => | BrouHaHa | Implementation | |
| Smalltalk | => | CST | Extension of | |
| Smalltalk | => | Deltatalk | Simplification of | |
| Smalltalk | => | Distributed Smalltalk | Augmentation of | |
| Smalltalk | => | Dylan | Influence | |
| Smalltalk | => | Eiffel | Influence | |
| Smalltalk | => | Ellie | Influence | |
| Smalltalk | => | Frost | Evolution of | |
| Smalltalk | => | GJ | Influence | |
| Smalltalk | => | HERAKLIT | Incorporated some features of | |
| Smalltalk | => | LOOPS | Influence | |
| Smalltalk | => | MOPS | Derivation of | |
| Smalltalk | => | OLABL | Influence | |
| Smalltalk | => | OPAL | Extension of | |
| Smalltalk | => | O'Small | Implementation | |
| Smalltalk | => | Pygmalion | Written using | |
| Smalltalk | => | Ruby | Influence | |
| Smalltalk | => | School | Influence | |
| Smalltalk | => | ScriptX | Influence | |
| Smalltalk | => | Self | Influence | |
| Smalltalk | => | SHAZAM | Extension of | |
| Smalltalk | => | Smalltalk Agents | Augmentation of | |
| Smalltalk | => | Smalltalk/X | Augmentation of | |
| Smalltalk | => | Smalltalk-72 | Evolution of | |
| Smalltalk | => | SOUL | Extension of | |
| Smalltalk | => | SPicolla | Target language for | |
| Smalltalk | => | Strongtalk | Extension of | |
| Smalltalk | => | Views | Extension of |
References:
in [ACM SIGACT-SIGPLAN] Proceedings of the 5th ACM SIGACT-SIGPLAN symposium on Principles of programming languages 1978 , Tucson, Arizona view details
in [ACM SIGACT-SIGPLAN] Proceedings of the 5th ACM SIGACT-SIGPLAN symposium on Principles of programming languages 1978 , Tucson, Arizona view details
in SIGPLAN Notices 14(04) April 1979 including The first ACM SIGPLAN conference on History of programming languages (HOPL) Los Angeles, CA, June 1-3, 1978 view details
in [ACM SIGAPL] APL Quote Quad 12(1) September 1981, Proceedings of the international conference on APL 1981, San Francisco, California, United States view details
After introductory remarks, Jean Sammet, the Conference and Program Committee Chairman, introduces the keynote speaker and "the third programmer of the first large scale digital computer, Mark I," Capt. Grace Hopper of the US Navy. Capt. Hopper describes the very early history -- combining personal recollections and technical observations. It is an excellent historical talk, precisely establishing the milieu existing in the 1940s and early 50s, when the concept of using a computer to create programs was just emerging.
The FORTRAN presentation by John Backus emphasizes the importance of object efficiency for FORTRAN acceptance. He states that language design was never considered a problem; the real problem was to consistently produce object programs as efficient as hand-coded ones. The presentation captures the clear and unwavering focus of Backus's original team on that goal: a focus and dedication which characterized the direction of one of the most significant software projects in the history of computers.
The controversies in the committee designing ALGOL 60 are re-enacted in miniature on these tapes. Alan Perlis describes the American contributions, concluding that ALGOL has Influenced all languages since that time. "It's the mother's milk of us all." Peter Naur describes the European contributions and the origins of recursion in the language. A lively floor discussion involving John McCarthy, John Backus, and Fritz Bauer ensues. The Algol 60 committee got involved in "academic log rolling" according to McCarthy who also points out that the committee decision not to consider implementation led to a language which was not implementable as a whole. It was assumed that "everyone was a gentleman and none would propose something he didn't know how to implement. However there was no guarantee the combination was implementable."
The excerpt on the LISP lecture by John McCarthy emphasizes the features of the language and is an excellent description of its intellectual sources. Jean Sammet in presenting COBOL also clearly defines the influences on the language and how and why the choices were made in a series of committee meetings. These choices were very much colored by the decision to take "a short range composite approach good for at least a year or two."
The tapes show how differently some of these important languages developed. According to Douglas Ross, APT evolved out of application requirements; by contrast, the major features of JOVIAL were developed in a few minutes, relates Jules Schwartz, its sole designer. Geoffrey Gordon tells how GPSS also grew from feedback from application users. SIMULA, developed by Kristen Nygaard and Ole-Johan Dahl, didn't even start as a programming language. Charles Baker discusses the development of JOSS, and Thomas Kurtz, BASIC -- intended to make learning to program analogous to learning to drive a car: by doing it.
PL/I was the largest language represented at the conference. According to presenter, George Radin, much of the complexity and size is due to the necessity of defining the result of all operations on mixed types and to implicit typing. The excerpts of the presentations on SNOBOL by Ralph Griswold and APL by Kenneth Iverson establish the specific motivations for those languages: in both cases conserving human resources was considered very important.
The conference banquet tapes contain anecdotes by the conference speakers and by master of ceremonies Bernard Galler. These entertaining historical asides and footnotes sometimes give more insight into the how and why things happened than the more scholarly analyses. For example, George Radin's story about the PL/I committee's ordering pizza -- the pizza had everything anyone wanted -- says a great deal about how the committee functioned when designing the language.
These tapes constitute an important historical record. Unfortunately, the quality of the tapes is less than desired. They were not professionally produced and the picture quality is often quite poor. Still-photos by Robert McClure and Richard Wexelblat are used where the videotape is inadequate. However, the excerpts have been well selected by J.A.N. Lee, Jean Sammet, and Henry Tropp.
In his summary Fred Brooks says that "the best thing about this conference is the character set." He also points out that the presentations on the languages designed by a committee emphasized the process, whereas the presentations on single-author languages emphasized technical issues. These tapes capture the factors that have made the history: the personalities, the process, and the technology. They are interesting now and will be invaluable to future historians of the pioneering period of language development.
in ACM Computing Reviews March 1982 view details
What is object oriented programming? My guess is that object oriented programming will be in the 1980's what structured programming was in the 1970's. Everyone will be in favor of it. Every manufacturer will promote his products as supporting it. Every manager will pay lip service to it. Every programmer will practice it (differently). And no one will know just what it is.
Surely there's a better way. I hope this paper will clarify object oriented programming by characterizing its more important aspects. These characterizations, while not a definition per se, should at least provide a better understanding, and ideally a commonly held one. Thus I hope we can avoid the deplorable and confusing situation just described. DOI Extract: History
History
The immediate ancestor of object oriented programming is the programming language Simula. The Smalltalk programming system carried the object oriented paradigm to a smoother model. Although other systems have definitely shown some object oriented tendencies, the explicit awareness of the idea - including the term ~'object oriented" - came from the Smalltalk effort. Furthermore, Smalltalk is still the strongest representative of object oriented programming in the sense of being the most unified under a single (object oriented) paradigm. Comments on some related efforts will be given in a later section. For now it is enough to note that object oriented programming arose when Smalltalk was developed and therefore the history of Smalltalk serves as the history of object oriented programming.
Smalltalk is the software half of an ambitious project known as the Dynabook. The Dynabook is a sort of computer holy grail, with the goal of being a truly personal computer. The Dynabook ultimately is expected to handle with equal facility any and all kinds of information management, and to be all (computer type) things to all people. Accordingly Smalltalk has to carry quite a burden of expressiveness and convenience.
Alan Kay is the man chiefly responsible for the vision of the Dynabook. In the late 1960's he did work on a preliminary version, known in that incarnation as the Flex machine. Then in the early 1970's he went to the Xerox Palo Alto Research Center and there formed the Learning Research Group. Alan's goal was still a truly useful personal computer, with the Xerox Alto being the interim hardware for the Dynabook, and with LRG doing Smalltalk as the software.
Smalltalk drew heavily from Flex, which in turn was an "Eulerized" version of Simula. While a LISP influence is clearly evidenced in the deeper structure of Smalltalk, the class notion from Simula dominated the design. The language became completely based on the notion of a class as the sole structural unit, with instances of classes, or objects, being the concrete units which inhabit the world of the Smalltalk system. Smalltalk did not completely give up its LISP heritage; rather that heritage is felt more as a flavor of the system than as specific ideas of the programming language.
Extract: Relationship of Smalltalk to Object Oriented Programming
Relationship of Smalltalk to Object Oriented Programming
More than a programming language, Smalltalk is a complete programming environment, all of which reflects the object oriented philosophy. Object oriented programming is so much a part of Smalltalk that it is difficult to tell where one leaves off and the other begins. While the entire Smalltalk system is worthy of investigation in its own right, we are now concerned only with object oriented programming, which is just a part of the Smalltalk system. A brief discussion will make clear the distinction and remove confusion about which term means what.
Note: this paper is not a tutorial on the Smalltalk language. I will discuss the internals and specifics of Smalltalk only insofar as they relate to the topic at hand. Readers unfamiliar with Smalltalk may wish to read the references first, although I have tried to make this unnecessary. I suggest to the confused reader that he finish reading this paper, then consult the references to clear up any confusion, then (optionally) read this paper again.
Smalltalk may be thought of as comprised of four pieces, viz., a programming language kernel, a programming paradigm, a programming system, and a user interface model. These pieces are fuzzily defined and not explicit within the actual Smalltalk system. They are basically hierarchical, though there is overlap and some convolution. Thus the user interface is built on the programming system, which is built following the programming paradigm and using the programming language kernel.
The programming language kernel is the syntax and semantics as determined by the Smalltalk compiler. The programming paradigm is the style of use of the kernel, a sort of world view or "meaning" attached to the entities in the kernel. The programming system is the set of system objects and classes that provides the framework for exercising the programming paradigm and language kernel, the things necessary to make programming possible and convenient. The user interface model is the use and usage of the systems building materials in order to present the system to the user - in other words, the given user interface plus the user interface "flavor." The combination of these four pieces is the Smalltalk system.
Although I have represented the pieces as separate and independent, they are not, really. In fact they are inseparable and very interdependent. Not only could each piece itself not exist in a vacuum, the design for each piece influenced the design for all the other pieces, i.e., each design could not exist in a vacuum. A more faithful representation would be as interrelated aspects of the Smalltalk system. Following the note, however, I shall continue to consider them as "pieces" rather than "aspects."
Using this view of the Smalltalk world, imagine a line drawn within the programming system piece such that the objects and classes relating to the user interface model are on one side and the objects and classes relating to the programming paradigm and language kernel are on the other. We now find Smalltalk divided naturally into two parts: a user interface part, and another part. This other part is the object oriented programming aspect of Smalltalk. With the understanding that by "Smalltalk" I mean only as much of Smalltalk as is below the line of the user interface part, I shall henceforth use the terms "Smalltalk" and "object oriented programming" interchangeably. Extract: Characterizing Object Oriented Systems
Characterizing Object Oriented Systems
Object oriented programming is not programming using a Simula-like class concept, just as structured programming is not GOTO-less programming. Most of the definitions of structured programming fail to impart any real understanding of the term. We can do better by characterizing object oriented programming rather than giving a formal definition.
No explanation of object oriented programming could get off the ground without a discussion of objects. In characterizing such systems we are interested not in what an object is but in how an object appears. In what follows an object is always viewed from outside (the characterization of objects), not from inside (what objects "are").
It is no accident that in explaining object oriented programming objects are viewed from outside. The shift of viewpoint from inside to outside is itself an essential part of object oriented programming. In my experience this shift occurs as a quantum leap, the "aha!" that accompanies a flash of insight. In spite of this, I am convinced that the view from outside is the natural one - only my years of training and experience as a programmer conditioned me to "normally" view objects from inside.
Probably due to the influence of formal mathematics, programmatic behavior was originally thought of as extrinsic. For understanding complex systems, however, intrinsic behavior provides a better metaphor, because people think that way (for example, children learn Smalltalk very quickly.) As Dijkstra cautions, we must be careful not to think something is convenient just because it is conventional. The first principle of object oriented programming might be called intelligence encapsulation: view objects from outside to provide a natural metaphor of intrinsic behavior.
Extract: Objects
Objects
The Smalltalk world is populated by items seen uniformly to be "objects." These "objects" are the sole inhabitants of an otherwise empty universe. This is not just a trick of nomenclature; the items are uniform in a number of ways, that uniformity producing the items' "objectivity." In what ways are objects uniform?
Objects are uniform in that all items are objects. An item found floating in the void of Smalltalk's universe is certain to be an amorphous blob. The blob has the properties of objectness: inherent processing ability, message communication, and uniformity of appearance, status, and reference. The item being amorphous means that no other properties are evident. The object may possess properties outside objectness, but these are made available by the whim of the object - any such properties are not visible to an outside observer.
Objects are uniform in that all objects are equally objectlike. What this means is that all objects communicate using the same metaphor, namely message passing. Objects send messages to communicate with objects. (Message sending is discussed later in the paper.)
Objects are uniform in that no object is given any particular status. Thus, "primitive" objects, such as integers, are objects just like any other. Also, "system" objects, such as class Class, are objects just like any other. Finally, user defined objects are objects just like any other. There are no "second class citizens."
Not only are objects themselves uniform, the means of referring to objects is uniform. An object is always dealt with as a whole, by using its (system internal) name; a given name may name any object, since all objects have the same kind of names. It follows that there is no way of opening up an object and looking at its insides, or updating ("smashing") its state. What is more important is that the concept of opening up an object does not exist in the language. (This is like trying to imagine that something is true that can't be thought of in the first place.)
Of course it is possible for the object itself to act as if it could be opened up. With suitable methods an object can choose to provide behavior that duplicates, say, a Pascal record. Pascal records can certainly have their insides looked at, or their state updated (or smashed). The distinction is that the object itself has chosen to provide this behavior - it is not part of the language. Furthermore, most objects do not normally provide such behavior. In a true object oriented system, this is as true of the system philosophy as of the actual mechanisms.
Extract: Processing, Communication, and Message Sending
Processing, Communication, and Message Sending
For a processing system to be a useful one, processing activity must take place. In Smalltalk, the processing activity takes place inside objects. An object, far from being inert matter, is an active, alive, intelligent entity, and is responsible for providing its own computational behavior. Thus processing capability is not only inside the object, it is everpresent within and inseparable from the object.
The other property essential to a programming system is communication. An object in process may at times be entirely self sufficient, but when it is not it must have some way of interacting with objects outside of itself. Also, the user wants processing done to bring about his wishes. Both of these are needs of communication, and both are served by the mechanism of message passing.
Objects process and send messages to effect the user's desires as well as their own. A user asks an object to carry out some processing activity by sending to the object a message. The object may in turn ask other objects for information, or for some computational work to be done, by sending them messages, and so on.
Message sending serves as the uniform metaphor for communication in the same way that objects serve as the uniform metaphor for processing capability and synthesis. This uniformity is an important part of Smalltalk. In what ways is message sending uniform?
Message sending is uniform in that all processing is accomplished by message sending. The same mechanism serves to do addition, compute arctanh, request the most complicated file service operation, or provide whatever behavior is available from a user defined object. No other mechanism - such as "operating on data" - is available.
Message sending is uniform in that one message is just like another. By this I do not mean that all messages are identical, or that all messages have the same format, but that messages are sent the same way irrespective of the recipient. An example should clarify this: the message "+" to an integer, denoting addition, is sent the same way as the message "+" to a dictionary, (possibly) denoting adding an entry.
The distinction between communicating and accomplishing processing is a fine one in Smalltalk. Objects react to messages sent to accomplish processing by sending messages to accomplish processing. The buck has to stop somewhere (and indeed it does), but it seems as if it could be passed on indefinitely. A corollary of messages all being sent the same way is that each object potentially can respond to any message by sending other messages in turn. The principle as it applies to object oriented programming is: any object can accomplish processing requested by any message by directing message flow to other objects. Extract: Messages
Messages
As the sending of a message is the only way of communicating, the message itself must be the information to be communicated. Conceptually a message is the text of the message-request. Additionally a message may be parameterized by sending along with the text one or more object names. The object name parameters are part of the language of discourse and are different from the text in that the text is constant whereas the parameters may vary. An object responds to a message with a reply, which is an object name.
A message serves to initiate processing and request information. The text of the message informs the object what is requested. The parameters supply any additional necessary information or computational ability. The reply confirms activity completed and returns the information requested. There is a subtle but important distinction between a conventional procedure call, which denotes an action, and sending a message, which makes a request. In a typical procedural programming language it is hard to give up the notion that the caller of a procedure is somehow "in control." The caller and callee share a language, a set of procedural interfaces, by which the caller directs the callee to perform actions. In Smalltalk, on the other hand, a message is a request of what the sender wants with no hint or concern as to what the receiver should do to accomodate the sender's wishes. The sender, presuming all objects to be quite intelligent, trusts the receiver to do "the right thing" without worrying about exactly what the right thing is. Thus assured, the sender relinquishes control philosophically as well as actually, so that the interpretation of the message is left entirely up to its recipient. This notion, a sort of call-by-desire, is central to the object oriented philosophy. Extract: Sharing
Sharing
In order to meet the goals of the Dynabook project, Smalltalk must do more than provide computational activity in situ. A successful personal computer system will be understandable, usable, modifiable, and adaptable. All of these requirements can be met by a facility for sharing.
Sharing allows understanding because it is a good match to the way people think. For example, the earth and a basketball are different, yet each has the property round. There isn't one "round" that belongs to the earth and another that belongs to the basketball; the common attribute round is shared. People model the universe by collecting together archetypal attributes and allowing them to be shared by the things to which they are common.
Sharing makes for a usable system by facilitating factoring, the property of one thing being in only one place. Successful factoring produces brevity, clarity, modularity, concinnity, and synchronicity, which in turn provide manageability in complex systems. In a project as ambitious as the Dynabook, manageability is essential to usability.
Sharing increases the ease of making modifications. This may sound paradoxical, since changing shared parts increases the chance of producing unforeseen consequences. The paradox disappears on realizing that sharing is not a binary decision but a spectrum from totally shared to totally individual. One can choose an appropriate place for a modification by moving around in the sharing spectrum, whereupon consequently the level of detail is neither too great nor too trivial. To put this another way, you can concentrate on what must be changed, not what must be left alone. This is made possible by an explicit framework providing a spectrum of sharing.
Sharing provides for adaptation by being variable along another dimension, the dimension of individuality. What this means is that attributes can be shared by a group while allowing for individuals within the group to reinterpret some "shared" behavior as it applies to the individuals themselves. The previous sharing spectrum varies as to which objects share which collections of attributes; the dimension of individuality determines to what extent individuals within a given collection actually share the "common" attributes. The result of allowing individual variability is that, given something close to what you want, it is easy to produce exactly what you want by overriding shared behavior with individual behavior - to adapt. This situation of"I want something just like that, except..." invariably arises in real use. Adaptation is supported by sharing in this form and is referred to as differential programming.
Smalltalk meets the goals of sharing by providing a framework of classing, subclassing, and superclassing, collectively referred to as inheritance. [n relation to object oriented programming what is important is not the mechanism of classing and sub-superclassing but the provision for the merits of sharing Inheritance is also an excellent paradigm - probably any particular framework would be - for elucidation, providing as it does a sort of road map for the system universe. The conclusion: object oriented systems provide an explicit framework for sharing so as to accrue the attendant advantages.
Extract: Notes on Related Systems
Notes on Related Systems
Smalltalk remains the model object oriented system. But no programming language is an island, and a mention of other systems is clearly called for. Following is a capsule summary of relevant systems. The point here is to view the work as it relates to object oriented programming, not to appraise the merits of the various systems.
A group of installations with Burroughs B220's used a clever scheme to insure portability of files from one installation to another, in order to get around the difficulty of not having operating systems. A file was arranged as a transfer vector with relative pointers, followed by actual B220 code, followed by data. Although the code and representation of data varied from installation to installation, the desired effect could be obtained by reading the file into a standard memory location and branching indirectly through the appropriate location in the transfer vector. This idea was later carried over into the operating system of the B5000. Indeed, the entire architectural concept of the B5000 pointed in this direction, offering the first hardware implementation of what are now known as capabilities. Unfortunately, the B5000 is almost legendary for being ahead of its time, unappreciated, and misunderstood, and so the impact of the earliest object oriented ideas was hardly felt.
The Sketchpad system of the early 1960's is an object oriented system that apparently was programmed using an object oriented style. But Sketchpad is a graphical interaction system, not a programming system. While Sketchpad was one of the earliest object oriented systems, its application to programming systems was not widely appreciated, perhaps because the object oriented philosophy was not explicit enough.
The programming language Simula is an ALGOL based simulation language which first introduced the class concept. Simula certainly can be used with a style which is highly object oriented. But old ideas die hard, and Simula's extensions over ALGOL were used in support of simulation features with traditional ALGOL style programming taking up the slack. In practice, Simula falls short of realizing object oriented programming for several reasons. One, primitive data types, system data types, and user data types do not all have equal status. Two, the extensions to ALGOL, while including the class concept, also included many "features" such as INSPECI" and IN, which are contrary to the object oriented philosophy. Three, the object oriented metaphor has not
really caught on in the Simula community, due to the roots of the language in ALGOL. Four, the typing mechanism in Simula often makes it difficult to realize the free-spiritedness of object oriented programming. If Sketchpad is an object oriented system without the language, Simula is an object oriented language which is rarely used in an object oriented fashion.
The LISP-AI notion of frames captures well the idea that behavior rides along with the thing whose behavior is being described. Also, the resemblance of the commorffdefault mechanism of frames to the inheritance mechanism of Smalltalk is striking. I think of frames as an object oriented extension to LISP. Similar to Simula, however, the problem with frames is that the LISP notion very strongly remains, so that the inclination towards the object oriented philosophy is not nearly so strong, nor as clearly defined, as in a completely object oriented system.
The programming language Alphard is related but still in a rather uncertain state. After more use the character of Alphard will be clearer, but generally speaking Alphard centers on abstraction, which is roughly evenly divided between data encapsulation and abstract data types. If anything Alphard leans to the abstract data types side, though not so far as, for example, algebraic axiomatic specification. One clear oversight is that Alphard does not use inheritance in any strong fashion. The programming language ADA, though still in the implementation stages, is clearly centered and focused on data encapsulation. The sense of operating on data is very strong in ADA, from syntax to operator overloading to separation of types from modules. Generic procedures capture some, but not nearly all, of the polymorphism inherent in object oriented programming, and ADA's facility for inheritance is weak at best. ADA has followed traditional (i.e., ALGOL style) language design principles so that the issues of implementation and usage would be clear at the outset. ADA is one of the few languages that was designed with extensive, specific requirements definitely given a priori; none of these requirements mentions object oriented programming.
The programming language CLU makes a serious effort in the object oriented direction. The sense of unification of reference mode is very strong in CLU, narrowing the distinction between different object categories. CLU falls a little short on the syntax side, which is still a conventional functional (i.e., data oriented) format. Also, the typing mechanism of CLU doesn't give a sense of freedom to the "receiver" of a message, since the particular response mechanism is specified by the type, which is known and explicit in the source at the call site. This restriction shifts the sense of control from the receiver (object oriented) to the sender (data oriented). Furthermore, CLU resembles Alphard and ADA in lacking a good inheritance mechanism. As with Alphard, CLU tries to balance abstract data types with data encapsulation by centering on abstraction, but CLU leans to the data encapsulation side more than Alphard does. Even so, CLU remains as the strongest "traditional" contender for supporting object oriented programming.
Extract: Conclusions
Conclusions
It is usual to understand new ideas in terms of familiar ones. Object oriented programming might be (and probably already has been) likened to abstract data types, data encapsulation, information hiding, and modularization. This may be more palatable to some audiences, but it ducks the issue.
These comparisons neither do justice to, nor capture the essence of, the object oriented methodology.
To quote Alan Kay:
"Though Smalltalk's structure allows the techniques now known as data abstraction to be easily (and more generally) employed, the entire thrust of its design has been to supercede the concept of data and procedures entirely; to replace these with the more generally useful notions of activity, communication, and inheritance."
Object oriented programming holds great promise, but is not yet widely understood. In spite of object oriented programming just now becoming popular, the term of its use is already in danger of being overworked and misunderstood. My goal has been to argue for an understanding of object oriented programming, not just a dogmatic definition. Let us hope that we have learned our lesson from structured programming and find out what the term means before we start using it.
in SIGPLAN Notices 17(09) September 1982 view details
Introduction
While it is not yet clear whether Ada, BLISS, Mary/2, Modula-2, Mesa, C, CLU, Edison, Concurrent Euclid, Icon, Newton, PLAIN, PLUS, Praxis, Smalltalk, SQURL, Y, or some other language is "best" for systems programming, each language represents an advance towards the goal of supporting an understandable and efficient organization of the many details and relationships inherent in systems programming.
Unfortunately, no one language has yet achieved the delicate balance between simplicity and power that would distinguish it as ideal, but it appears that Modula-2 comes quite close. Modula-2 represents a step forward in language design, both because it incorporates existing features instead of inventing its own, and because of its evident concern for simplicity.
Modula-2 offers the following valuable language features:
Simplicity.
Few primitive datatypes are defined, few control constructs are supported (there is no "go to"), and input-output operations are not provided as part of the language (they can be provided via extensions written in Modula-2). This simplicity allows for easier standardization and better portability than can be achieved with most other languages.
Modules
A module is a named collection of variables and procedures, similar to an Ada package. It controls the interfacing and encapsulation of the conceptual parts making up large software systems. Modules provide a more flexible solution to the problem of partitioning the name space of a large program than does the more familiar hierarchical nesting of procedures. They are so valuable they are even being force-fitted onto existing languages.
Separate Compilation.
Modules may be compiled separately, providing good management for large programsr and definition modules allow for specifying interfaces without giving implementation details.
Flexible Datatypes.
Strong datatypes are enforced, but this can be relaxed when necessary in systems programming to just declaring a parameter to be a word, an address, or an array of words.
Machine Access.
Access to specific memory addresses and other characteristics of the underlying machine is supported.
Tasking.
Flexible and efficient tasking is provided by coroutine management routines.
in SIGPLAN Notices 17(08) August 1982 view details
It is a difficult book to review adequately. One must ask if it conveys the same message to that vast majority of information processing specialists who were not in the business at the time of the events recounted as it does to those of us who played an active role in some of the developments as they happened. Judicious inquiry of younger readers of the book suggests that rather more of the informal flavor comes through than one might suspect at first. In that sense the book "tells it like it was," although some of the text makes it quite clear that programming language designers have the same kind of selective and prismatic memories that other people have.
The plan of the book is straightforward. Thirteen specific languages were selected by the conference organizers, and the book contains, for each language: a formal paper; a transcript of the presentation; a transcript of remarks by a designated discussant; a transcript of a subsequent question and answer session; the full text of all questions submitted; a biography of the authors. In addition there is the full text of the Keynote Address presented by Captain Grace Murray Hopper, itself required reading, and a series of appendices, including summaries of each language.
As stated in the introductory material on the organization of the conference, the criteria for selection of the languages to be included were: "that the languages 1) were created and in use by 1967; 2) remain in use in 1977; and 3) have had considerable influence on the field of computing." The 1967 cutoff was to insure at least ten years perspective. The result of applying these criteria was:
ALGOL 60
APL
APT
BASIC
COBOL
FORTRAN
GPSS
JOSS
JOVIAL
LISP
PL/I
SIMULA
SNOBOL
This general review cannot pursue the specific language chapters; that is a task for individual reviews elsewhere in CR. Some overall comments are in order, however. The formal papers are not simply personal recollections of the authors. An organized procedure was established to guide each author in preparing an account according to established historical practice, thus maximizing the archival value of the papers. It appears to have worked, for the authors systematically -- and in some cases, apparently, painfully -- searched for old records, letters, and memoranda. The vignettes that surface therefrom are fascinating.
No one should be surprised that the accounts of the camel (designed by committee) languages, ALGOL 60 and COBOL, have a somewhat different flavor from the others. There is a gold mine for students of decision making processes in this book. The conference organizers are to be commended for providing two accounts of ALGOL 60, one from the American and one from the European point of view. The contrasting perceptions and the almost recursive discussion are both intriguing and delightful.
This reviewer's one regret is that it was impossible to capture and document the conversations that occurred over the coffee cups and in the corridors. In summary, this is a superb book, a must for all computer professionals. It is also one of the very few records of a conference of any sort where the reader gets a feeling for what it was like to actually be there. This reviewer was there and reading this book almost four years after the conference brought back delightful memories with preternatural clarity.
in ACM Computing Reviews March 1982 view details
The particular interests of the authors show in the variety of organization and emphasis found in the papers. John Backus describes the background of the FORTRAN project, some of the design decisions, the documentation and implementation. Alan Perlis emphasizes the many people involved in the ALGOL design, from before 1958, through the Zurich and Paris meetings, culminating in ALGOL 60. Peter Naur concentrates on the design decisions made between the Zurich and Paris meetings. The disagreements which surface in appendices to his paper make for fascinating reading. Kristen Nygaard describes the many changes which the design of SIMULA went through from 1961 through 1971, from SIMULA I to SIMULA 67.
The book is not a dry history -- many statements seem particularly surprising in hindsight. John Backus says of FORTRAN, "As far as we were aware, we simply made up the language as we went along. We did not regard language design as a difficult problem, merely a simple prelude to the real work of designing a compiler which could produce efficient programs." Jean Sammet stresses with regard to COBOL, "We were going to recommend a short range composite approach good for at least the next year or two."
The history of the technical decisions is particularly well researched and presented. Many ideas were taken directly from other languages, such as the separation of the data description and executable statements in COBOL, deriving from FLOW-MATIC. Some seemed to occur almost casually, such as Thomas Kurtz commenting on the design of BASIC, "Around 1960 or 1961, after a visit to the PDP-1 time-shared computer at MIT, I can clearly recall John McCarthy saying, 'Why don't you guys do time sharing?' Shortly afterward I said to Kemeny, 'I think we ought to do time sharing.' Kemeny responded, 'OK.' And that was that!" Other decisions stemmed from deadlocks, as Alan Perlis described, when a European member of the ALGOL committee declared "No! I will never use a period for a decimal point." The proposal from Joseph Wegstein for three levels of language calmed the situation. The ALGOL paper and appendices by Peter Naur present different views of the same experience. Even a project consisting of only two people can produce its share of excitement. Kristen Nygaard describes the shock of a switchboard operator at overhearing a violent argument between two men in a hallway. She was reassured that it was just Dahl and Nygaard discussing SIMULA.
One thing which emerges from many of the papers is the deep involvement which a language design can elicit from its designers. John Backus and Jean Sammet both describe many late, long hours.
But this book is not just a series of papers by knowledgeable authors. It is itself a history of the History of Programming Languages Conference held in Los Angeles in 1978. Jean Sammet, the General Chairman, describes how the conference was put together. There are many valuable ideas here for potential conference organizers. The Conference Historian, Henry Tropp, provides a historical perspective and suggests archiving of design papers. The keynote address is by Grace Hopper. Its transcript captures the qualities of innovation and humor which make her talks such an experience. The author talks are based on the papers, so there is much redundancy of material. The main value to be gained by the duplication is the opportunity to discover the human side of the authors, which comes out in the more informal relation to the audience. Jean Sammet brings down the house with her lament that students are not given more than a passing exposure to COBOL before they receive their degrees in computer science.
The question and answer sessions were often as interesting as the talks. The book gives John Backus's answer to the question why the letters I through N were chosen to designate integers. The readability of these sections attest to the effort which Richard Wexelblat put into the editing of this volume. The History of Languages represents a tremendous amount of effort from a great many people, and is a book which programmers as well as language designers will find both instructive and enjoyable.
in ACM Computing Reviews March 1982 view details
in ACM Computing Reviews March 1982 view details
in SIGPLAN Notices 20(07) July 1985 (Proceedings of the ACM SIGPLAN 85 symposium on Language issues in programming environments) view details
in SIGPLAN Notices 22(12) December 1987 (OOPSLA '87) view details
in SIGPLAN Notices 22(12) December 1987 (OOPSLA '87) view details
Introduction
The Smalltalk-80 language is the best example of Object-Oriented Programming (OOP) languages. One important characteristic of Smalltalk-80 we will focus on in this paper is its sequentiality. The text of a method body is a sequence of expressions, which are evaluated sequentially. The Smalltalk-80 computation model is based on a single thread of activity which is passed among objects in a call/return fashion when sending messages. The introduction of processes into the language allows multiple activities but objects remain passive by nature. The process level is also unfortunately orthogonal with the object level. As a consequence combination of these two styles is uneasy as well as unsafe. If inside two distinct processes two messages are sent to a same object, there is no guarantee in the composition of the messages. If there is some state change (assignment of variables) in the bodies of the methods activated, this could lead to chaos. Semaphores are provided in Smalltalk-80 as tools for synchronization. But semaphores are very low level tools. The nature of processes and semaphores, used to synchronize processes and their accesses to shared data, remain totally orthogonal to the nature of objects.
There have been attempts to modify Smalltalk-80 in order to unify objects and processes. The main proposals are Actra [Thomas and Lalonde 85] [Lalonde et al. 86] and ConcurrentSmalltalk [Yokote and Tokoro 86] [Yokote and Tokoro 87]. These proposals model multiple activities of objects. A receiver may resume its computation after replying to the caller, allowing the sender and the receiver to resume their respective computations simultaneously. These models remain based on synchronous communication. They will be summarized in section 10 on related work. Meanwhile we may already remark that these models did some change into the Smalltalk-80 model of computation and virtual machine. This quotation from [Yokote and Tokoro 87] explains why ConcurrentSmalltalk evolved from a first version compatible with Smalltalk-80 [Yokote and Tokoro 86] towards a second version in order to alleviate some primitive problems.
"Through experience gained from writing programs in ConcurrentSmalltalk, we have become aware of some disadvantages, such as the treatment of: an object shared by more than two processes and the behavior of a block context. These disadvantages originate from the concurrency control that had been designed to maintain compatibility with Smalltalk-80."
Our approach is somewhat different because we don't intend to do any change to the Smalltalk- 80 model and virtual machine but we want to propose a minimal extension needed to introduce and study concurrency (i.e. potential parallelism as opposed to physical parallelism) into Smalltalk-80. This approach of studying concurrency models and constructs as an extension of Smalltalk-80 is also advocated by [B'ezivin 88]. But in contrast, our approach is specifically related to our concern with the actor paradigm for Object-Oriented (or Object-Based) Concurrent Programming [OOCP 87]. Smalltalk-80 appears to be a wonderful language to explain and discuss the actor languages, with some impressive economy of tools.
This choice of introducing actors into Smalltalk-80 raises the question of their cohabitation with standard Smalltalk-80 objects, and by going further, their complete combination within the current Smalltalk-80 environment and methodology. This issue of combining passive objects with active objects is one of the fundamental issue of OOCP, as pointed out by [B'ezivin 87, page 404]. In order to ensure safety of combination of our actor kernel and Smalltalk-80 we will sketch some methodological rules.
It is time now to summarize our goals:
1. preservation, there should be no change made to Smalltalk-80. The system consists in a small extension (a set of classes and methods) to the current image, named Actalk.
2. minimality, this extension should be minimal, in order to be easily understood and ported. All what is non strictly necessary or uneasily implemented has been rejected.
3. extensibility, this minimal kernel will be easily extended in order to model actors able to replace their behaviors as stated in the Actor model of computation [Agha 86], synchronous and eager types of message passing, as proposed by the ABCL/1 model [Yonezawa et al. 87], distributed computation, and further constructs or models.
4. synergy, the current model of objects and the extended set of actors should be compatible and able to cooperate. Some rules are edicted in order to keep a safe mixin.
5. pedagogy, we are personaly involved in the actor family of OOCP languages [OOCP 87].
We intend to use this extension in graduate courses to introduce actor-based programming to usual OOP programmers. Extract: Review of the Smalltalk80 Computation Model
Review of the Smalltalk-80 Computation Model
Before introducing our model, we will start with a review of the basic principles of the current Smalltalk-80 computation model.
2.1 Sequential and Synchronous Message Passing
2.1.1 Control of Computation
The Smalltalk-80 model of computation is based on procedural activation. There is is only one conceptual thread of activity which is passed along objects when messages are sent. The sender of the message transfers the activity to the receiver which will compute the message. (The receiver could in turn send a message to another object.) The sender is waiting for the reply from the receiver and remains blocked until this moment. When the receiver finishes its computation of the message it sends back a value (or by default itself) as the reply to the sender. Then the activity ends in the receiver and resumes back in the sender.
In summary only one object is active at a time, and when sending a message the activity is moved to another object before going back to the caller which then resumes its computation.
2.1.2 Environment of Computation
This model of activity is very close to procedural or function calls of procedural or functional languages like Lisp. One main difference is that there are no free variables to consider, except the global variables. Only three environments are considered when an object is activated by a message: the environment of the object (made of the bindings of its instance variables, and its class or pool variables which are inherited through its class), the environment of the message (made of the bindings of the parameters of the message) and the global environment (a dictionnary self-referenced through one of its global variable named Smalltalk which contains the bindings of all global variables inside the system). The environment of the sender object is irrelevant and hidden to the receiver. Information exchange between objects should be made explicit through the initial message by passing some arguments, or by explicit messages sent to obtain access to the sender. If we compare with Lisp we note that the environment of an object has to be explicitly and extensionally defined. Objects don't rely on some implicit closure mechanism. Only the global environment could be shared implicitly.
2.1.3 Blocks
There is however one exception to this model: blocks. Blocks in Smalltalk-80 are equivalent to Lisp lambdas, i.e. anonymous functions. They introduce delayed evaluation and abstraction into Smalltalk-80. Blocks are mainly used for control structures [Deutsch 81] (note that there is no macro mechanism in Smalltalk-80), and processes. A block (instance of the class BlockContext, or BlockClosure depending on the version) closures the context of its definition. It has already been argued that blocks are not perfectly coherent within the object-oriented philosophy proposed by Smalltalk-80, because objects and blocks have been designed separately [Borning and O'Shea 87] [Ungar and Smith 87] and that they may lead to tricky programming and errors in a concurrent environment. For instance, if an object returns a block as the value of some method invocation, the object is now shared by the block. Thus if the object or the block is shared by a process, this could lead to conflicts as pointed out in [Yokote and Tokoro 87].
2.2 Multiple Activities
2.2.1 From Blocks to Processes
In order to bring multiple activities into the language, processes have been introduced into the Smalltalk-80 system, for instance to run controllers which are waiting for interaction associated to a view on the screen. They could also be created and controlled by the user. The virtual machine schedules the running processes in a pseudo-parallel fashion bringing multiple and simultaneous threads of activities into the language. The problem for the user is the orthogonality between processes and objects. As pointed out in [Yokote and Tokoro 87], this leads to difficulties for the programmer to specify one concept into two different entities: object and process, of different levels of abstraction. The existence of a third concept: block leads to even more complication.
2.2.2 Concurrent Accesses to a Shared Object
Because one single object may be shared by several processes, there is a need to protect its internal state from undeterministic effects if there are state changes. This could lead to bugs, known as timing errors, very hard to detect. The relative schedulings of processes accessing to some single data may produce unpredictable results. Smalltalk-80 provides low level tools for synchronization: semaphores. Semaphores allow to control the execution of processes, specially when synchronizing accesses to some shared data.
2.2.3 Synchronization Techniques
Most usual problem is to ensure mutual exclusion of processes, i.e. only one of them may execute the critical section where there is some mutation of the object, i.e. change in its data structure. But state changes are specified in the bodies of methods at the object (or rather class) level whereas synchronization should be done at the data level. This dissociation of expressing the changes and synchronizing them makes it difficult to program. Most of the encapsulation gained from OOP is lost. It is not always obvious for the programmer to figure out which data of which object needs to be protected (and which needs not), and to introduce the semaphore signal and wait messages at the right place into the right methods.
An example of how to protect a shared object with the use of semaphore objects is presented in a progressive way in [Goldberg and Robson 83, pages 258--263]. The class SharedQueue, which belongs to the standard image, implements a FIFO (First In First Out) data structure whoze size is unbound (except the size of the image!). The queue is protected against timing errors in case of concurrent accesses, and synchronizes the dequeueing requests onto the enqueueing requests if the queue is empty.
in SIGPLAN Notices 22(12) December 1987 (OOPSLA '87) view details
in Computer Language Magazine 7(4) view details
in Computer Language Magazine 7(4) view details
in IEEE Transactions on Computers July 19, 1991 view details
in IEEE Transactions on Computers July 19, 1991 view details
in IEEE Transactions on Computers July 19, 1991 view details
Resources
- Logo of Smalltalk