The Impact of Software Engineering Research on Modern Progamming

The Impact of Software EngineeringResearch on Modern ProgammingLanguages

BARBARA G. RYDERRutgers UniversityMARY LOU SOFFAUniversity of VirginiaandMARGARET BURNETTOregon State University

Software engineering research and programming language design have enjoyed a symbiotic rela-tionship, with traceable impacts since the 1970s, when these areas were first distinguished fromone another. This report documents this relationship by focusing on several major features of cur-rent programming languages: data and procedural abstraction, types, concurrency, exceptions, andvisual programming mechanisms. The influences are determined by tracing references in publi-cations in both fields, obtaining oral histories from language designers delineating influences onthem, and tracking cotemporal research trends and ideas as demonstrated by workshop topics,special issue publications, and invited talks in the two fields. In some cases there is conclusive

This article has been developed under the auspices of the Impact Project. The aim of the projectis to provide a scholarly study of the impact that software engineering research—both academicand industrial—has had upon practice. The principal output of the project is a series of individualpapers covering the impact upon practice of research in several selected major areas of softwareengineering. Each of these papers is being published in ACM TOSEM. Additional information aboutthe project can be found at http://www.acm.org/sigsoft/impact/.This article is based upon work supported by the U.S. National Science Foundation (NSF) underaward number CCF-0137766, the Association of Computing Machinery Special Interest Groupon Software Engineering (ACM SIGSOFT), the Institution of Electrical Engineers (IEE), and theJapan Electronics and Information Technology Association (JEITA). Any opinions, findings andconclusions or recommendations, expressed in this publication are those of the authors and do notnecessarily reflect, of the NSF, ACM SIGSOFT, the IEE, or JEITA.Authors’ addresses: B. G. Ryder, Division of Computer and Information Sciences, Rutgers Uni-versity, 110 Frelinghuysen Road, Piscataway, NJ 08854-8019; email: [email protected]; M. L.Soffa, Department of Computer Science, School of Engineering and Applied Science, Univer-sity of Virginia, 151 Engineer’s Way, P.O. Box 400740, Charlottesville, VA 22904-4740; email:[email protected]; M. Burnett, School of Electrical Engineering and Computer Science, OregonState University, Corvallis, OR 97331-5501; email: [email protected] to make digital or hard copies of part or all of this work for personal or classroom use isgranted without fee provided that copies are not made or distributed for profit or direct commercialadvantage and that copies show this notice on the first page or initial screen of a display alongwith the full citation. Copyrights for components of this work owned by others than ACM must behonored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers,to redistribute to lists, or to use any component of this work in other works requires prior specificpermission and/or a fee. Permissions may be requested from Publications Dept., ACM, Inc., 1515Broadway, New York, NY 10036 USA, fax: +1 (212) 869-0481, or [email protected]© 2005 ACM 1049-331X/05/1000-0431 $5.00

ACM Transactions on Software Engineering and Methodology, Vol. 14, No. 4, October 2005, Pages 431–477.

432 • B. G. Ryder et al.

data supporting influence. In other cases, there are circumstantial arguments (i.e., cotemporalideas) that indicate influence. Using this approach, this study provides evidence of the impact ofsoftware engineering research on modern programming language design and documents the closerelationship between these two fields.

Categories and Subject Descriptors: D.2.0 [Software Engineering]: General; D.3.0 [Program-ming Languages]: General; D.3.3 [Programming Languages]: Language Constructs and Fea-tures; D.1.5 [Programming Techniques]: Object-oriented Programming; D.1.7 [ProgrammingTechniques]: Visual Programming

General Terms: Design, Languages, Reliability, Security

Additional Key Words and Phrases: Software Engineering, Programming Languages

1. INTRODUCTION

This article is part of the larger NSF-sponsored Impact project that is docu-menting the influence of software engineering research on software practice.In this article, we focus on the impact of software engineering research on thedesign of programming languages from a historical perspective. That is, thearticle is not a survey of software engineering accomplishments, but insteadfocuses on documenting software engineering research that has influenced thedesign of programming languages. The influence was determined by examiningpublications, oral reports, and the time sequence between significant advancesin software engineering and programming language design.

The production of software requires software engineering techniques, suchas specification, design, implementation, testing, and maintenance. Essentialto performing the last three phases of software development is the selection ofa programming language(s) as an implementation vehicle. The programminglanguage(s) chosen needs to offer the application programmer the power tonaturally express the task at hand in a disciplined manner. The requirementsof expressiveness and software engineering methodology, evolving over time,clearly impact the design of programming language features.

Thousands of programming languages have been designed to address theunique demands of application areas. Many have been developed purely for re-search exploration, while others have been targeted for production use. Some ofthe languages are general purpose while others were developed for particulardomains. To name a few programming languages used in practice today, C++,Java, Ada,1 Perl, Visual Basic, and COBOL all are widely-used across manyapplication domains. Software engineering and the design of programming lan-guages enjoy a synergistic relationship, each influencing the other. This rela-tionship holds with regard to both research and practice in these two fields.

The main goal of this report is to document how fundamental research insoftware engineering has been a resource for programming language featurescommonly used today. To achieve our goal, it is necessary to trace the ongoinginterrelations between software engineering research and programming lan-guage design. In examining these interrelationships, we have found symbiotic

1We use the term Ada to refer to Ada 83 in this article; we will use Ada 95 to refer to the laterversion of the language.

ACM Transactions on Software Engineering and Methodology, Vol. 14, No. 4, October 2005.

The Impact of Software Engineering Research • 433

interactions between these two fields that have both influenced and strength-ened each other. Thus, in this report we track research both in programminglanguages and software engineering.

In accomplishing this goal, there are a number of challenges that must be ad-dressed. The synergy between software engineering research and programminglanguage design renders attribution of some specific contributions difficult. Ini-tially, there was no distinction between the software engineering and program-ming languages research communities. Research in programming languagesdesign, specification, programming methodology, and software engineering wasbeing done by members of a single amorphous field. This field had the same con-ference publication venues until the late 1970s (e.g., IFIP Working Group 2.3formed in 1969, NATO Software Engineering Conferences 1968, 1969). Initialresearch contributions in both fields were essentially shared contributions tothis original, single software field. In the middle of the 1970s, this communitybegan to split into the fields of software engineering and programming lan-guages. The first in the series of the ACM SIGACT/SIGPLAN Symposia onPrinciples of Programming Languages (POPL) was held in 1973, while the firstIEEE/TCSE ACM/SIGSOFT International Conference on Software Engineer-ing (ICSE) was held in 1975. These two conferences mark the beginning of thedifferentiation between the two communities. As the fields began to evolve intodistinct communities, researchers who had published in the same conferencesand journals now began to publish in both software engineering and program-ming languages conferences, and thus, the classification of them as either asoftware engineering or a programming languages researcher is difficult. In-terestingly, these two communities have continued to grow further apart.

Another challenge is differentiating between the contributions of softwareengineering research and software engineering practice, since both have influ-enced the design of programming languages. Questions to be considered includethe following: Was a feature of a programming language changed due to a newresearch idea or due to the experiences of practicing software engineers? Whatinfluenced the wide acceptance of object-oriented programming that current lan-guages support? Does this show the influence of practitioners’ experiences or theadoption of a new paradigm explored by researchers or both? Because of theinterrelatedness of languages, software engineering practice and software en-gineering research, these questions are difficult to answer.

Finding primary sources to document the influence of software engineeringresearch presents an additional challenge. Research publications are needed todetermine this impact; examination of the topics of meetings and workshopsheld at specific times also yields some information as to software engineeringconcerns. The oral and written history of how a programming language evolvedis also needed to complete this study. Often the communities feel that certainconcepts were in the air [Gabriel personal communication] in that everyoneagreed these were important ideas, but no one really knew where they origi-nated, or who was instrumental in developing them.

Clearly, studying the evolution of the concepts and features of all program-ming languages that have been developed presents an intractable problem.The challenge here is to select specific languages to study and their significant



features, to render the problem feasible. The existence of software process, lan-guage tools, and environments adds more complexity to the study because theyalso have had influence on research and practice in both software engineeringand programming languages. Thus, we focused only on the software engineeringconcepts that made their way into programming languages; we did not addresssoftware process, tools, and environments.

The final challenge is the determination of an effective research methodologyfor this study. One possible approach is to examine this question from a historyof science perspective; that is, focusing on practice at a given time and place,asking why and how ideas originated and evolved. Our approach has been toexamine results of research as evidenced in published works and to infer influ-ence from these results. We also have conducted interviews with programminglanguage designers that explore what they were thinking and how they werebeing influenced at the time of accomplishing their designs.

This article discusses the impact of software engineering research on a se-lected set of widely used languages: Java, C++, Ada, and Visual Basic, andsome of their significant concepts. Concepts considered include abstractions,visibility, reuse, exception handling, types, concurrency, and visual program-ming features. The research methodology used to study the historical interac-tions between software engineering research and programming language de-sign takes into account the iterative evolution of programming languages andthe influence of software engineering research on this evolution.

The research methodology is described in Section 2. Section 3 traces the de-velopment of individual programming concepts. Section 4 recounts the devel-opment of visual programming and its relationship to Visual Basic and to soft-ware engineering research. Section 5 summarizes interviews conducted withprogramming language designers, in which they were questioned about whatinfluenced their designs. Finally, Section 6 summarizes the findings.

2. RESEARCH METHODOLOGY

Given the focus of this study, several languages, selected because of their im-portance to current programming practice, were examined for the constructsand the concepts they expressed.

Based on the constructs found in many languages, a number of languageswere considered as possible choices for the focus of this study. Neither COBOLnor FORTRAN was selected because, although they remain in wide use today,they are not used as general purpose programming languages. COBOL is, andhas been, used for business applications; FORTRAN is the language of choice forscientific computation. Likewise, C is used mainly as a systems programminglanguage.

Ada, C++, and Java are widely used for general purpose applications. VisualBasic is a language widely used for fast prototyping, relying primarily on Basicplus graphical interfaces to leverage programmer productivity. We includedVisual Basic in its own section of the report as a representative of visual pro-gramming in practice and because of its widespread use. Thus, the focus of thisstudy centers on general purpose languages: Ada, C++, Java, and Visual Basic.



This language selection is not an attempt to be definitive about current prac-tice, nor does it represent a value judgment about the importance of languagesin specific application areas. These language choices have many of the featuresexpected in today’s general purpose languages and also enable the tracing ofhistorical software engineering influences.

2.1 Software Maturation Models

In 1985, Redwine and Riddle [1985] presented a maturation model of softwaretechnology, which discusses the steps for transition from a research conceptto practice. The goal of the work was to discover the process, principles, andtechniques useful in transitioning modern software to widespread use. Theyidentified six major phases.

—Basic research: investigate ideas and concepts that eventually evolve intofundamentals and identify the critical problems and subproblems.

—Concept formulation: key idea or problem is identified and the ideas areinformally circulated, convergence of a set of ideas, and publications start toappear that suggest solutions to subproblems.

—Development and extension: present a clear definition of a solution ineither a seminal paper or a demonstration; preliminary use of the technology;generalize the approach.

—Internal enhancement and exploration: extend approach to anotherdomain, use technology to solve real problems; stabilize and port technology;development of training materials.

—External enhancement and exploration: similar to previous phase butperformed by a broader group, including outside the development group.

—Popularization: show substantial evidence of value and applicability; de-velop production-quality version, commercialize and market.

In a keynote address at ICSE 2001, Shaw [2001] used this model to describethe coming of age of software architecture. The first phase, the basic researchphase, involved the exploration of the advantages of specialized software struc-ture for software process. This phase also cataloged systems to identify commonsoftware architectural styles, leading to models for explaining architecturalstyles. In the concept formulation phase, architecture description languageswere developed and architectures were classified. In the development and ex-tension phase, languages were extended and new languages developed, as theconcepts were refined. Meetings, journals and conferences that were devotedsolely to software architecture were seen. In the next phase, formal analysisof real systems was performed. In the external enhancement and explorationphase, Unified Modeling LanguageTM (UML) was developed, as an example.Finally, in the popularization phase, standards were developed, demonstratingthat software architecture is accepted and used in software engineering.

We developed a similar maturation model for programming language designand software engineering and used this model to determine the interactions ofprogramming languages and software engineering. Our model has five phases



followed by iterative refinement using the last two phases. They are:

—Basic research: identify a software engineering problem and explore basicideas and concepts.

—Concept formulation: circulate ideas informally to develop a research com-munity and publish solutions to the problem or subproblems.

—Introduce into a programming language: frame a solution to the problemin a programming language, which is used for a period of time.

—Refinement: as a result of using the language feature as well as exploringother facets of the problem, solutions are refined and extended.

—Extend the programming language or develop a new one: based on therefinements, an existing language is either changed or a new one is developed.

The last two phases are repeated until software engineers and programminglanguage designers find an acceptable solution.

2.2 Methodology and Resources Used

To provide focus, we used the model to explore concepts in object-orientedand imperative languages that are commonly used; that is, we examined mod-ern programming languages and identified a set of core features, as was donein Shaw et al. [1978]. We used these core features to demonstrate the relationbetween software engineering research and programming languages.

An extensive survey was performed in both the software engineering andprogramming language research literature to find references to the constructsand concepts. Historical papers describing the evolution of particular program-ming languages were also examined. Key to the approach was, for each concept,performing a reverse chronological search through the materials gathered tolook for interactions, both cited and implied,2 between software engineeringresearch and programming language design. Of greatest interest were the ori-gin, development, and evolution of these concepts to their current form. Thepapers found through this search were then read for evidence of influence onprogramming language design. We used time lines to help determine the inter-relationships between the fields and their potential impact on one another. Inmany cases, we used the date that an article was published as an indication ofpossible influence.

We also conducted interviews with language designers to acquire firsthandhistorical information. With the help of Mike Mahoney, History of Science Pro-fessor at Princeton University, we developed a set of five questions and emailedthe questions to the language designers. We gave them the option of answeringthe questions by email or by phone. In some cases, we had further contact. Asection summarizing the responses appears in this article in Section 5. The lan-guage designers participating in the interviews were Professor Niklaus Wirth(Pascal, Modula), Professor Boris Magnusson (Simula), Dr. Bjarne Stroustrup

2As an example of an implied interaction, we may infer a relation between the temporal precedenceof a published software engineering result and the subsequent appearance of a seemingly relatedprogramming language construct.



(C++), Dr. Jean Ichbiah (Ada), Tucker Taft (Ada 95), Tim Lindholm (Java) andDennis Canady (Visual Basic).

The resources used included both journal and conference papers in soft-ware engineering and programming languages. These written documents wereacquired through the usual digital and hard copy library sources as well asthrough personal communication. In addition, we used first person interviewsthat were published in various venues. With the development of later languagescame rationales about why language features and their forms were included;these provided another resource. Last, because many of the ideas that impactedsoftware engineering and programming languages were in the air, we used theresults of the interviews that we conducted for insight and further references.We also used the existence of workshops and conferences in different time pe-riods to indicate significant issues being considered by researchers.

In the next section, we apply this technique to several language features asthey evolved to their usage in Java, C++, and Ada. These include control anddata abstractions, inheritance, types, exception handling, and concurrency.

3. LANGUAGE FEATURES

In tracing the interaction between software engineering and programming lan-guages, we begin with the design of abstractions, including control, procedural,and data, which demonstrate a clear symbiotic relationship between researchin the programming language design and software engineering communities,to the benefit of software practice.

3.1 Abstraction

With the development of increasingly more complex applications, abstractionhas become a critical mechanism to control complexity in software. Thus, itis a major part of programming language design and software engineeringmethodology, necessitating interaction between the two communities. Modernprogramming languages support abstraction by enabling the user to expresswhat is significant and suppress what is not [Shaw 1984]. There are basicallythree types of abstractions used when constructing software, namely, data, con-trol, and procedural abstractions. Most widely used programming languagestoday include a number of different constructs to support these various formsof abstractions. The abstraction mechanisms in languages have been affectedby past experiences in software engineering research and practice.

3.1.1 Control Abstraction. Control abstraction describes a well definedoperation that expresses the execution sequence of statements (actions) in aprogram and includes intraprocedural control structures such as if-then-else,while, and switch statements. Typically all languages have built-in control ab-straction. During the 1960s, indiscriminate transfer of control was believed tocause difficulties and errors in writing and understanding programs. In the late1960s and early 1970s, two important software design methodologies emergedthat stressed the importance of properly organizing and structuring programs.One method, called stepwise refinement or top-down design, initially created an



abstraction of the program without details about the data structures or opera-tions [Wirth 1971a]. With each step, the program is successively refined untilthe final code is constructed. Thus there is a separation between the abstractdefinition of structures, and procedures and their implementation.

About that same time, there was a debate about the harmful effects of go tostatements [Dijkstra 1968b; Rubin 1987]. Intertwined with the discussion ofgo tos was the structured programming movement [Dijkstra 1969; Dahl et al.1972]. Consequently, the languages developed after the 1970s had structuredcontrol constructs and deemphasized or eliminated go to statements. However,there were a few cases where escaping from statements was felt to be neces-sary [Hopkins 1972], and languages have either included a go to or put in otherconstructs that enabled a break out of a statement, including breaking out ofloops and case statements.

Both top-down design and structured programming are mechanisms to makesoftware simpler, more understandable, and easier to modify. They enable ab-stractions to be specified and then implemented. Control flow patterns in aprogram are instrumental in developing and understanding a program. Fromthe software engineering research on structured programming and top-downdesign, control structures with a single entry point and a single exit pointmade programs more understandable. This led to a set of accepted intrapro-cedural control constructs [Shaw 1984]. All commonly used languages featurethe single-entry, single-exit (almost) design in their control structures.

Another example of programming methodology influencing programminglanguage design comes from generators in Alphard which became instantiatedas iterators in CLU. These structures expressed the concept of iterating througha set of elements or objects [Shaw et al. 1977; Liskov et al. 1977]. The idea wasto separate the abstraction of the concept of iteration from the implementa-tion. This idea is found in object-oriented languages, which have the concept ofiterating through a collection of objects.

Thus, the research of the early combined software community on developing,understanding, and modifying programs influenced the design of structuredprogramming language constructs.

3.1.2 Procedural Abstraction. Procedural abstraction deals with organiz-ing and decomposing a program into modules that typically have specific pur-poses. Procedural abstraction involves the definition of an interface and an im-plementation of the unit. Units were composed of local data and code that wasable to access nonlocal data as well as local data. FORTRAN introduced pro-cedural abstraction through its subroutine and function program units. Thesecould be developed independently of the programs that call them and could beseparately compiled. Simula 67 also had procedural abstraction through theclass structure with functions. Neither FORTRAN or Simula 67 had any sep-aration between the interface and the implementation, nor were the types inthe interface checked when used.

In 1971, Parnas wrote a most influential paper that formally introduced theimportance of modularity. The paper describes a method and need for decom-posing a program into modules [Parnas 1971, 1972]. The idea of information



hiding was also introduced in this paper by showing that the main benefit ofhiding implementation was to allow changes to the implementation to be con-fined to its module. Parnas characterized a module by its knowledge of a designdecision, which is hidden from all other modules. For example, in the paper asymbol table implementation was visible to its module but invisible to the restof the system. The publication of this seminal paper represented a transitionfrom software engineering research to concept formulation to programming lan-guage design. The module structures that were eventually developed by othersdiffered in how the interface and implementation were managed, whether theinterfaces were type checked, and the visibility rules for accessing the entitiesof a module.

A module enables more structure than a procedure. Modules allow pro-grammers to group related items together, including types, data, and routines.Modula-2 was one of the first languages that allowed the separation of the in-terface from the body of a module [Wirth 1977]. In Modula-2, the interface andbody can be separate in the same file or even appear in different source files.

In the mid-eighties, modules were refined to software components to enablereuse. Software reuse was seen as possibly “increasing software productivityby an order of magnitude or more” by Horowitz and Munson [1984]. Theirnotion of software reusability was broad, including not only code reuse, butalso the reuse of software design. In their discussion of reusable code, theycite McIlroy’s article from the 1968 NATO conference that described factoriesfor building software components [McIlroy 1976]. At the time, this idea wasconsidered impossible to achieve because of a lack of tools to create, index,search and compose components efficiently; also, the ability to describe the se-mantics of a component to a user so that the user could assess its utility tothe task at hand was limited. After reviewing several approaches that offeredsoftware reuse through high-level systems that produce programs from speci-fications and user-supplied parameters, Horowitz and Munson praised Ada asa language with features to support software reuse, including the Ada package(i.e., an abstract data type) and the generic procedure [Horowitz and Munson1984]. Thus, Horowitz and Munson believed that the programming languagedesign community was providing tools to accomplish the software engineeringresearch goal of software reuse. The designs of Ada and the research languageCLU, both demonstrated an emphasis on modularity and the ability to reusecode. CLU was intended for programming in the large, emphasizing programreadability and understandability over ease of writing [Liskov 1993]. Liskovbelieved that it was possible to develop a programming methodology throughdesigning a programming language so that problem solutions were similar toprograms in that language. This principle guided the design of CLU, whichemphasized data abstraction and encapsulation as well as reliability using ex-ceptions. Liskov stated that a driving force behind her language design wasthe desire to write correct programs, using language constructs to either helpavoid errors or help find them automatically. She described many design deci-sions in terms of a goal of program safety, including the decision on compile-time type checking within a module (and bounds type checking for arrays)[Liskov 1993].



Ada was one of the first widely used languages to feature separation of spec-ification and implementation as part of the language design, which enabledseparate compilation of modules, and still provided checking of the interfaces.Ada was designed specifically “to support development of large programs com-posed of reusable software components” [Wegner 1984]. Ada separated the in-terface and implementation through its package module [DOD 1980]. An Adapackage can contain procedures, functions, types and variables. The specifica-tion of a package is through its interface, which is declared separately from itsimplementation.

An important component of the module concept is the visibility rules forthe interface and implementation. The early languages (e.g., Pascal, Algol 60)used textual scope to define the interfaces between modules (e.g., subroutines,procedures). Wulf and Shaw detailed the problems with using scope for inter-faces. They enumerated some desirable properties of an interface, including(1) the scope of a name should not automatically be extended to inner blocks,(2) access rights to a structure and its substructures should be decoupled, and(3) it should be possible to distinguish different types of access [Wulf and Shaw1973]. As mentioned previously, Modula-2 [Wirth 1971a] contains the idea ofseparating the interface and implementation; the implementation is not vis-ible to users. However, there is no way to hide entities in the interface. Thepackage specification in Ada does enable parts of the interface to be hidden,as well as the implementation. Ada packages also allow information to be leftout of the declaration and provided in a separate file not visible to users of theabstraction [DOD 1980]. However, Ada allows the header of a package to bedivided into public and private parts. In Ada, data types expose the type nameand operations allowed on the type. The data structures used and the imple-mentation of operators are not visible to users. Thus, the ideas of informationhiding were eventually implemented in programming languages by controllingaccess through the interface, including the introduction of access rights suchas private, public, and protected. The access rights grew out of data abstractionresearch, which is discussed in the following section.

3.1.3 Data Abstraction. The concept of data abstraction, or abstract datatype, has had a profound influence on both software development and program-ming language design. The major thrust of programming languages and soft-ware engineering research activity in the 1970s was to explore issues relatedto data abstraction and visibility control [Ghezzi and Jazayeri 1998].

Abstract data types give programmers the capability of safely defining theirown types. Modern day concepts of abstract data types include (1) encapsulatingor enclosing data and the related operations on the data, (2) naming the datatype, (3) placing restrictions on the use of the operators, (4) having rules thatspecify the visibility of the data, and (5) separating the specification from theimplementation.

The notion of data abstraction was first introduced in the Simula 67 languageby associating abstract operations with the entities for which they were defined[Dahl and Nygaard 1967; Birtwistle 1973]. The entities and operations wereencapsulated in a class structure. However, accessing the data entities in a class



was not restricted to the class operations. It should be noted that the creators ofSimula 67 did not think about restricting the use of class entities [Rowe 1980].The idea of a class in Simula 67 paved the way for the later development of dataabstraction, classes and object-oriented programming. For various reasons, in-cluding, (1) the price of the compiler, (2) the perception that Simula 67 was asimulation language, and (3) the lack of resources to publicize it [Nygaard andDahl 1978], Simula 67 did not receive the attention it rightly deserved untilmuch later. Finally, in 2001, Ole-Johan Dahl and Kristen Nygaard, the devel-opers of Simula 67, received the Turing award for ideas fundamental to theemergence of object-oriented programming, through their design of Simula 67.Unfortunately, they both died in the same year and were not able to personallyreceive the award.

The idea of using abstract data types as an abstraction technique for reliablesoftware design was presented by Liskov [1972]. In this paper, Liskov describesvarious types of abstractions that provide the infrastructure to produce reliablesoftware that is easier to prove and/or test. One of the ideas presented was todevelop an abstraction based on the use and structure of data and limitingthe visibility of functions in the abstraction to what they need to know. Thusinformation hiding was also included as part of abstraction concept. The datafor the functions constituted the resources of the abstraction.

In the 1970s, the software engineering community recognized the need toorganize programs into modules by localizing implementation details as muchas possible. This led to the development of language support for abstract datatypes. The first research to incorporate data abstraction into a language wasCLU, through its cluster data type [Liskov and Zilles 1974].

About that time, a paper by Gannon and Horning [1975] presented languagedesign issues to improve the reliability of programs. One concept that had animpact on the design of languages was the idea of an explicit interface, andproviding rights to the creator of objects and the users of objects. The encap-sulation mechanisms of Simula 67 were refined in the 1970s by the developersof CLU [Liskov and Zilles 1975; Liskov et al. 1977] and Alphard [Wulf et al.1976; Shaw 1981]. CLU and Alphard both provided a data abstraction constructthat enforced protection of the data entities, allowing access only to the opera-tions defined for them. The design of CLU [Liskov et al. 1977] was very muchdriven by the desire to support software engineering methodology developedby means of program decomposition, similar to step-wise and structured pro-gramming [Wirth 1971a; Dijkstra 1969]. A goal for Alphard was to reduce thecost and increase the quality of software by developing a program methodologybased on abstraction and verification [Shaw 1981].

Besides CLU and Alphard, Euclid [Popek et al. 1977] also introduced con-cepts of information hiding. In both CLU and Euclid, the declaration and defini-tions of a data abstraction always appear together with the header that stateswhich of the module’s names are to be exported. In CLU, a module (called a clus-ter) implements a single abstract type [Liskov et al. 1977]. It has an interfacespecification, which is the code to create instances and definitions of operators.Alphard also has the concept of operations to be performed on objects of thecluster type. Assignment and equality are default operations on “forms.” The



language has explicit rules about accessing a variable of a cluster in the imme-diately enclosing procedure. The environment, or outer scope, was visible onlyby a direct request.

A set of visibility rules for data abstractions was also an important compo-nent of research in the early 1980s. C++, developed by Bjarne Stroustrup, hadas one of its primary goals the support of data abstraction and object-orientedprogramming [Stroustrup 1987]. Not only did it provide the encapsulation butalso limited the use of data entities. It used the model of private/public to limitthe access of entities in classes. The access right protected was introduced forinheritance in object-oriented languages.

Cardelli and Wegner defined object-oriented languages by three necessarycharacteristics: (i) they contain objects that are data abstractions with a definedinterface and hidden state, (ii) objects have types, and (iii) attributes can beinherited from super-types [Cardelli and Wegner 1985]. This definition clearlyshows the influence of data abstraction and modularity (i.e., defined interface)on this programming language paradigm. They cite Smalltalk as an exampleof object-orientation with inheritance, and described the standard Smalltalkhierarchy as an example of reuse that imposes a coherent structure on thetypes in the system. C++ and Java added visibility control to the notions ofinheritance and attributes (i.e., fields) already included in Smalltalk.

The abstract data type research results entered mainstream programminglanguages in combination with research results on inheritance in object-oriented software design and implementation. The goal of classes and inheri-tance is to enable reuse as well as code and data sharing. Inheritance allowsnew abstractions to be defined as refinements or extensions to existing ones.Dynamic binding allows a new version of an abstraction to display dynamicallydefined behavior.

Data abstraction plus inheritance and dynamic binding define importantcharacteristics of classes and object-oriented design. All three fundamentalconcepts of object-oriented programming—encapsulation, inheritance and dy-namic binding—have their roots in Simula 67.

The Simula 67 designers observed from their simulation applications thatprocesses often share a number of properties, including both data and actions[Nygaard and Dahl 1978]. These processes were structurally different in somerespects and therefore needed their own declarations—parameterization couldnot provide the flexibility needed. They then came up with the idea of subclass-ing, another name for inheritance. The term inheritance was defined later.3 Inthe Simula 67 language, subclassing was done by prefixing. The conceptualview of prefixing is concatenation of the parent’s class declarations with thechild’s. Thus, if class A is a prefix of class B, B’s objects would include A’s formalparameters, specification of the formal parameters, class body declarations, andthe class body as well as its own declarations. Thus, not only were the data and

3Collins and Quillian defined is-a relationships, introducing them in semantic hierarchies in1969 [Collins and Quillian 1969]. In Smalltalk-76 [Ingalls 1978] subclasses are described as auseful mechanism to accomplish code inheritance and allow code reuse and specialization throughoverriding.



functions of the class inherited but so was the body of the class, which containedstatements that were executed when the class was created.

Simula 67 also had dynamic binding through its virtual concept. Thus, themethod actually used depended on the object’s subclass. Smalltalk also incorpo-rated the notion of object orientation with binding [Ghezzi and Jazayeri 1998;Goldberg and Robinson 1983] at run time. In the Smalltalk message-basedprogramming model, each object carries a type at run time.

With the introduction of inheritance, object-oriented languages needed tosupplement the scope rules of objects. Ada, C++, and Java all have rules forvisibility of inherited attributes. Visibility issues included the visibility of pri-vate and public members to derived classes.

The issue of multiple or single inheritance has been addressed in both pro-gramming language design and software engineering. Subclassing in Simula 67was designed to be single inheritance; that is, an object of a class can only haveone base class. C++ initially had single inheritance because this was sufficientin a large majority of cases [Stroustrup 1987]; however, Stroustrup indicatedthat there were important concepts for which multiple inheritance is required.These concepts required a directed acyclic graph to represent their relation-ships rather than a tree, the single inheritance structure [Stroustrup 1987].Thus, C++ introduced multiple inheritance, in which a class can inherit froma number of base classes. However the controversy of single versus multipleinheritance did not end. Cargill [1993] argued against multiple inheritance byindicating that is it complicated to learn, write and read. He demonstrated,using examples of programs with multiple inheritance in the literature, thatmultiple inheritance is either improperly used or not used at all. Waldo [1991],in the same journal, makes a case for multiple inheritance by describing differ-ent forms of multiple inheritance and presenting examples where it is useful.When Java was developed, it used single inheritance with the extra facility ofinterfaces, which can be viewed as a form of multiple inheritance. This type ofinheritance is called mix-in inheritance [Scott 2000].

A time line graph of the interactions among abstractions and programminglanguages is given in Figure 1. The time line indicates when a particular ab-straction concept first appeared in the literature or in a programming language,subsequent interactions with other software engineering concepts, and its finalincorporation into object-oriented programming languages.

3.2 Types, Polymorphism, and Generics

Strong typing is currently accepted as a fundamental feature of modern pro-gramming languages, regardless of whether validated by compile-time check-ing, type inference or run-time checking. According to Cardelli and Wegner[1985], in a strongly typed programming language “all expressions are guaran-teed to be type consistent although the type itself may be statically unknown.”In other words, a program in a strongly typed programming language is guar-anteed, through a combination of compile-time and/or run-time type checks, tobe type safe; this means that the program is free from type errors during exe-cution. Strong typing ensures the reliability of code and provides an additional



Fig. 1. Time line for data abstraction.

layer of semantic checking of a program. Development of strong typing inprogramming languages happened cotemporally with software engineering re-search on reliability and later, software reuse. It seems clear that the conceptsof strong typing and software reliability reinforced each other, especially sincethe early pioneers in imperative language design were also active in softwareengineering research. Further, as type systems for programming languages de-veloped notions of genericity and polymorphism, these were directly related toissues of software reuse.

The main imperative languages designed in the 1960s and 1970s—Algol 60,Pascal, and PL/I—were designed at a time when the software engineering com-munity was worried about the reliability of code. In the mid-1970s, Barry Boehmdefined software engineering to be “the practical application of scientific knowl-edge in the design and construction of computer programs and the associateddocumentation required to develop, operate and maintain them” [Boehm 1976].Peter Wegner [1984] talked of the 1950s as a time of stand-alone programsand the 1960s as a time of development of operating systems and databases.He stated that the 1970s saw the birth of software engineering, referring tosimilarities in the construction of large software systems and large physicalstructures such as bridges. The 1980s, in Wegner’s view, saw the developmentof interface technologies and the personal computer revolution. The 1990s wasa time of knowledge engineering, the use of intelligent components to build sys-tems (e.g., adaptation). In this temporal framework, the 1970s—the era of Algol60 and Pascal—was a key time for software engineering, so that the design ofstrongly typed languages, which were type safe, coincided with the beginningof the discipline of engineering software.

C.A.R. Hoare, a member of the IFIP Working Group in Algol (WG 2.1) activein the original design of Algol 68 [Bergin and Gibson 1996], was the keynote



speaker at the first Principles of Programming Languages (POPL) conferencein Boston in 1973. In that talk he spoke of types as “eliminating low-level pro-gramming errors when checked by compiler” [Hoare 1974a; van Wijngaardenet al. 1968]. Furthermore he claimed that types are essential to program designand documentation. He stated that denoting a declared name and structure orrange of values for every variable is the “most important aspect of clear pro-gramming” [Hoare 1974a].

In 1977, John Gannon performed an interesting experiment showing thatdeclared types and type checking could increase the fraction of programmingerrors caught before production of the final program [Gannon 1977]. In addition,the programmers he studied who were the least experienced, benefited the mostfrom compile-time typing. In an earlier paper, Gannon and Horning [1975] hadexplored issues of language design for reliability through experiments withstudents. They stated that declared types provided useful “redundancy” thatcaused errors to transform valid programs into invalid programs; they alsonoted that type checking caught logical errors, not syntactic errors.

The first widely used programming language to feature explicitly typed vari-ables was Algol 60. In designing Pascal, which was based on Algol 60, N. Wirthintended the programming language “to make available a language suitableto teach programming as a systematic discipline” and “to develop implementa-tions of the language that were both reliable and efficient on presently avail-able computers” [Wirth 1971b]. It was the first language to introduce user-defined types, including records and subranges. However, Pascal’s subrangetypes caused some problems in its type system, since operations on subrangescould not be checked fully at compile time. In addition, Pascal extended thedata structure constructs in Algol 60 (e.g., arrays) by introducing record struc-tures with heterogeneously typed fields. Pascal allowed variants of records inwhich the value of a tag field determined the current type of the variant; how-ever, most Pascal compilers offered no run-time type check of these tags, so theuse of variant records was type unsafe. Pascal also introduced the use of heapstorage with pointer-valued variables that had heap addresses as their values.

Habermann [1973] criticized the subrange construct because there can beexpressions whose operands are subrange type values, but whose result has notype! Habermann also argued that structures are not types, primarily becauseoperations on structures are actually operations on their constituent elements,not on the structure itself; therefore, a characteristic property of a type, that is,being a value as well as operations on that value, is not fulfilled [Habermann1973]. These critiques of types in Pascal can been seen as addressing issuesof program understandability and readability as well as good programminglanguage design.

The unsatisfying lack of orthogonality in design was clearly addressed byAlgol 68 [Tanenbaum 1976; van Wijngaarden et al. 1968], which offered a richsystem of user-defined types. The fact that all types could be used in all con-texts rendered Algol 68 easier to learn, although some argued that Algol 68programs were difficult to understand. The designers of Algol 68 achieved theirgoal of being able to validate type safety of programs fully at compile-time, evenwhile allowing constrained type unions, which safely offered the functionality



of the variant records in Pascal. Unfortunately, Algol 68, although novel, neverattained popularity or general usage outside of the research world.

Cardelli and Wegner [1985] stressed that a type “protects an underlyinguntyped representation from arbitrary or unintended use.” They differentiatedthe goal of static typing (i.e., complete type checking at compile-time) used by theearly programming languages from the goal of strong typing combining compile-time and run-time type checking to achieve type safety. They characterizedthese early programming languages with declared types in terms of their abilityto achieve the goal of strong typing. Some of the problems with array types andvariant records in Pascal have been mentioned previously; in addition, Pascalfailed to require the complete type of procedures passed as parameters to bespecified.

During the late 1960s and 1970s, the emphasis on data abstraction in lan-guages such as Simula 67 and Modula-2, enabled richer notions of types includ-ing inheritance (in Simula 67, already discussed in Section 3.1.3), modules withopaque types at the interfaces to facilitate information hiding (in Modula-2),and parametric polymorphism (in ML) [Cardelli and Wegner 1985]. During thissame period, the influential International Conference on Reliable Software washeld in 19754 and discussions on types were prevalent.

In 1980, there was a workshop on Data Abstraction, Databases, and Concep-tual Modeling attended by researchers from software engineering, databases,and artificial intelligence [Rowe et al. 1980]. The transcript of a panel consider-ing the topic What is a type? from the viewpoint of each of these research com-munities, features wide-ranging discussions of this question. A central themewas the value and practical viability of abstract data types, as a construct withseparate specification and implementation, and with encapsulation of values.Panelist Mary Shaw’s remarks emphasized the needs for types to convey infor-mation about constraints on values and how they can be used. Ira Goldstein,another panelist, explained the concept of a class with methods from Smalltalk,(in which he was programming at the time), a world of hierarchical types. TedCodd, a panelist, associated a notion of type with ideas in relational databases.All of these researchers agreed that a notion of type adds structure and defini-tion to the use of values in their respective subfields of computer science.

The emphasis on building software from components in the software en-gineering community during the 1970s, was reflected in programming lan-guage research in data abstraction, object-oriented programming and modu-larity [Wegner 1984].

At this same time, the designers of Smalltalk were providing a practicaldemonstration of how abstract data types with encapsulation might be inte-grated into a programming language. Smalltalk uses run-time type checking(type by use). Some research projects defined compile-time checkable types forSmalltalk [Graver and Johnson 1990]. This goal could be accomplished onlyby separating subclassing from subtyping rather than considering them asequivalent and thereby restricting inheritance. These research results were

4The conference was subsequently held annually from 1976–1979, demonstrating the emphasis onreliability in the research community at that time.



not incorporated in the definition of Smalltalk, but may have affected the def-inition of inheritance in C++ and Java, and the addition of strong typing tothese programming languages.

Ada used strong typing to check consistency of definition and usage of pa-rameters in packages. However, Ada components (or packages) had some weak-nesses as well. Wegner [1984] describes how Ada components can communicatenot only through interfaces, but also through global variables and pointers intothe heap. In addition, packages and processes in Ada did not integrate well; forexample, Ada packages were not protected against concurrent access by tasks.These aspects of Ada hinder it as a basis for software component technology,according to Wegner. He discussed software reuse in terms of how it relatesto software productivity; most significant are reuse of software components indifferent applications and reuse of components in different versions of a givenprogram [Wegner 1984].

Both Ada and CLU offered generic templates for data abstractions, param-eterized by the type of the data. These embodied the notion of generating spe-cific software components of the sort needed for the application, while onlymaintaining one copy of the code. These languages offered parametric polymor-phism in that an explicit type parameter was used to instantiate the functionargument; this kind of polymorphism was described by Cardelli and Wegner[1985] as “macro-expansion driven by the type of the arguments.” Wegner re-marked that the emphasis on reuse embodied in Ada packages, also impliedan emphasis on portability (i.e., reuse of software across machines), modular-ity (i.e., reuse of software across programs), and maintainability (i.e., reuse ofunchanged portions of code after other portions are changed) [Wegner 1984].Frankel [1993] discussed how Ada generics “encourage and assist the imple-mentation of reusable software.” He cited Ada’s strong typing and separationof package specification from implementation as language features supportingabstraction, and necessary for reuse to be accomplished in an efficient manner.Frankel emphasized that building a generic version of code isolates the reusableportion from the part that is unique to each user. Both of the kinds of reusabilityhe discussed—as-is and with-modification—can be realized with generics.

Research in the programming language design community at this time ex-amined the relation between subtyping and subclassing, and their influenceon possible choices for object-oriented programming language design [Madsenet al. 1990]. Madsen et al. contrasted the two uses of subclassing, for establish-ing a type system through specialization and for code sharing. They discusseda type system as a “means for detecting certain program errors, type errors”and considered combinations of compile-time and run-time type checking toachieve type safety, also including the checking needs of parameterized types.They expected a type system to allow desirable “early error reporting” whencompile-time checking is possible. This paper is an example of many researchpapers in the programming language design community of the time, concernedwith building type systems that would enhance program reliability in the newlanguage paradigm.

The emergence of object-oriented programming languages in the 1980s and1990s was cotemporal with increasing concern in the software engineering



community about how to design and build large, modular systems from pieceswith clearly defined interfaces using teams of programmers. The ability to en-sure software reliability was questioned and more emphasis was placed onreuse of tested or provably correct software.

Designed in the mid-1980s, C++ was the first widely used object-orientedlanguage for commercial software. C++ offered the creator of a new type (orclass) the ability to define implicit type conversions between that type and an-other; these are used by the compiler for resolving types in uses where coercionis necessary. Murray [1988] discussed problems with this language feature thatcan occur when too many conversions are defined, leading to ambiguities thatrequire casting to fix. In addition, this feature may make it possible for newdeclarations to break existing code. This discussion was in the context of C++libraries, whose usage was growing at the time. Translating these concerns tosoftware engineering terms, as a programming language expert Murray wasworrying about effective software reuse, support for program understanding,and code extensibility.

Wegner [1984] viewed inheritance in classes as structuring components sothat they are easily reused. He compared libraries in Ada, which are flat instructure, with libraries in Smalltalk, which have a tree structure. He sug-gested the idea that object-oriented language mechanisms can embody seman-tic knowledge that can aid in software reuse.

Reuse research in the late 1980s focused on libraries, reusable components,and reusable support environments [Prieto-Diaz 1993]. There are many differ-ent types of reuse considered—ideas, artifacts, processes—but the connectionwith programming language design is best viewed from the perspective of adhoc and compositional reuse. Ad hoc reuse involves reuse of libraries with user-friendly retrieval mechanisms; compositional reuse refers to composing existingcomponents to furnish parts of new systems. Both of these involve reuse of code,with (black box), or without (white box), modification [Prieto-Diaz 1993].

The standardized interfaces of the C++ STL and the Java JDK can be seen asproviding tools for these sorts of reuse. Stroustrup stated that C++ templateswere intended to be added to the language when their design and implemen-tation issues were fully explored. The need for standardized libraries in C++was clear in 1988 [Stroustrup 1993] when he first presented templates at theUSENIX C++ conference. He chose to use generics because they provided statictype checking and cited the provision of good libraries as desirable, and almostnecessary, for acceptance of an object-oriented programming language. Lookingat Dr. Dobb’s Journal and the C/C++ Users Journal from the 1990s, we findseveral articles about programming with the standard template library (STL),evidence of language design responding to reuse issues [Plauger 1995; Keffer1995]. The addition of generics to Java 1.5 and the strong interest expressedin the generics offered by C++ are further evidence that a concern with reuseissues affected programming language design.

Strong typing was added to programming languages to enhance software re-liability, at a time when this was a focus of the software engineering researchcommunity. The development of user-defined packages and generics were di-rect responses to concerns about software reuse. The time line graph showing



Fig. 2. Time line for Types and Exceptions. The arrows in the diagram on the right show relationsbetween programming language and software engineering concepts, and the times of their firstappearance. The programming languages listed to the left of the time line are shown at theirinception year. Some of the concepts on the right appear in some of the programming languages onthe left.

the interactions between types in programming languages and the softwareengineering research related to types is given in Figure 2.

3.3 Exceptions

Exceptions are features that were added to programming languages to providethe programmer the capability to specify what should happen when unusualexecution conditions occur, albeit infrequently. Originally in programming lan-guages, such atypical conditions resulted in control being relinquished to theoperating system that then aborted the execution of the program in a forcedtermination. But when such conditions, however infrequent, can be anticipated,the programmer can write code to react to them and to gracefully handle them.Exceptions and exception handler codes are the mechanism provided by modernprogramming languages to address this problem.

The historic introduction and development of exception mechanisms in pro-gramming languages is intertwined with considerations of software reliabilityand fault-finding in software engineering. The first precursor of an exception-like construct is found in Lisp 1.5, a language designed by John McCarthy inthe mid-1950s [Gabriel personal communication; McCarthy et al. 1965]. Thislanguage featured a function named errset that allowed the Lisp interpreterand compiler to gracefully exit from an error when one occurred. This func-tion used a mechanism for counting the number of cons operations performedwithin a loop in order to stop an unbounded computation. The errset construct



allowed suppression of error statements and a program restart under certainconditions after an error occurred [McCarthy et al. 1965].

PL/I, a programming language developed by IBM and representatives of itsuser community (i.e., SHARE [Radin 1981]) concurrently with System 360 inthe mid-1960s [Radin 1981], included some facilities for dealing with controlflow that were atypical for a high-level language. Previous languages had hadfew facilities for dealing with exceptional conditions during execution, suchas end of file, overflow, bad data, and so forth. The PL/I language designerswanted to give programmers the ability to write reliable and safe programstotally in their language [Radin 1981]. The ON condition feature was introducedinto PL/I to allow specification of the actions to be taken when one of a setof 23 unusual, but anticipatable situations occurred during execution. User-defined ON conditions were also allowed. There were several problems with thismechanism: (i) an ON unit was dynamically associated with its invocation byan exceptional condition occurrence, rather than being associated lexically withthe excepting statement or operation, and (ii) global variables were often usedto communicate data to the ON unit code [Library 1970; MacLaren 1977; Liskovand Snyder 1979].5 The construct proved difficult to use, in part because the fix-up actions were to take place in the state that pertained when the ON statementwas executed. Nevertheless, the philosophy of programming language designfor reliability demanded that this facility (or something like it) be included inthe programming language definition.

By the mid-1970s, software reliability was a strong concern in both the soft-ware engineering and programming languages communities. In March 1977,SIGPLAN, SIGOPS and SIGSOFT cosponsored the Conference on LanguageDesign for Reliable Software in Raleigh, NC. The Communications of the ACMfeatured a special issue on language design for reliable software in August 1977.

The exception mechanisms in today’s languages were influenced by researchin software engineering. In the Communications of the ACM in December 1975,John B. Goodenough discussed issues in exception handling, classifying thetypes of exception usages as (i) dealing with domain or range failure of an op-eration (ii) indicating the significance of a result, or (iii) permitting monitoringof an operation. When range failure is indicated, the operation may need tobe aborted, retried, or terminated, yielding partial results. A domain failurerequires modification of the input or an abort of the operation. Exception type(ii) is not a range failure, but requires that additional information be passedback to the user about the operation. Exception type (iii) is usually resumedafter the user examines the information about the operation passed back by theexception. Not all of these are error conditions; Goodenough [1975a] describedthem “as a means of conveniently interleaving actions belonging to different lev-els of abstraction.” After reviewing some existing exception mechanisms of thetime, Goodenough discussed requirements for good exception handling, whichshould “help prevent and detect programmer errors” according to Gannon and

5Note: no parameters were allowed in ON conditions; standard condition built-in functions wereprovided to query information such as the name of the procedure in which the condition was experi-enced [Library 1970]. See also http://www.kednos.com/pli/docs/USERS GUIDE/6292pro 023.html.



Horning [1975]. He argued the effectiveness of lexical (or static) associationof handlers with operations that may throw exceptions. These included bothlanguage-defined and user-defined (subroutines) operations, with explicit dec-laration of those exceptions that may be thrown as the result of a call. Headvocated compile-time checking of the completeness of exception handling.His model of exception handling included the possibility of resuming executionas well as termination, and allowed the use of default exception handlers.

Goodenough’s [1975a] paper codified the ideas presented in his earlier pa-per [Goodenough 1975b] at the second Symposium on Principles of Program-ming Languages (POPL) (January 1975), the major programming languages re-search conference at that time. This is an example of how software engineeringresearchers, concerned about issues of software reliability, directly contributedto programming language design.

In addition to Goodenough’s contributions to exception handing, during thissame year Brian Randell described his own construct for error detection andrecovery [Randell 1975] in a paper delivered at the International Conference onReliable Software. He defined a structured mechanism called recovery blockswhich were to be used when an unanticipated fault occurred. Horning describedexception handlers as “useful” and “intended to cope with particular antici-pated, but unusual, situations” [Horning 1979]. Horning suggested that recov-ery blocks and exceptions could coexist in the same code as what he termed “anattractive compromise.”

During the period of these software engineering discussions on how program-ming languages should be designed to facilitate the handling of faults, a newprogramming language, CLU [Liskov and Zilles 1975; Liskov et al. 1977; Liskov1993] was designed based on the ideas of abstraction and specification. CLUwas designed to enable good program construction of moderate-sized (by mod-ern standards) codes, emphasizing the use of software engineering techniquessuch as data abstraction and program verification, as well as programminglanguage theory in terms of formal (algebraic) specifications. In the chapteron exceptions, Liskov and Guttag [1986] described the need to “program defen-sively,” that is to write each procedure “to defend itself against errors.” A “robustprogram” is “one that continues to behave reasonably even in the presence oferrors” [Liskov and Guttag 1986]. This is a strong emphasis on this aspect ofprogramming language design being motivated by software engineering con-siderations; this fits well with Goodenough’s [1975a] emphases.

Liskov and Snyder [1979] discussed the design of the exception handlingmechanism in CLU and gave credit to Goodenough specifically for influenc-ing them through his paper [Goodenough 1975a]. They discussed their designwith regard to other previous approaches, as well. For example, the CLU modelexpects that exceptions not handled locally where they are raised, will be han-dled by the immediate caller of a procedure. (Of course, the handler code canrethrow an exception to pass it upwards through the call chain, one link at atime.) Liskov and Snyder pointed out that this is consistent with Goodenough’smodel, but not with the definition of exception handling in PL/I or Mesa. Theirdiscussion of the resumption versus termination model of exception handling,explicitly referenced Goodenough’s model in his 1975 paper [Liskov and Snyder



1979]. Thus, it is clear that for CLU, programming language design was di-rectly influenced by software engineering research, although the researcher(Goodenough) presented his ideas to both communities [Goodenough 1975a,1975b].

The Ada programming language was defined in the late 1970s according tospecifications set by the US Department of Defense, as a modern programminglanguage that was to be the universal software lingua franca for their projects.The Rationale for the Design of the Ada Programming Language [Ichbiah et al.1979] described the evolution of the Green candidate language written aspart of the process of defining what was to become standardized as Ada. TheRationale was written to record design decisions and influences on the Ada lan-guage. The chapter on exception handling in the Rationale references the ear-lier Goodenough article [Goodenough 1975a] in two ways. It uses Goodenough’sclassification of exceptions as either allowing program execution terminationor resumption after handling, but rejects the resumption model of handling infavor of always terminating execution.

The Rationale also references a technical memo by Bron et al. [1975] thatdiscussed desirable properties of an error-handling mechanism to provide forprogram termination under exceptional conditions. These desirable propertieswere formulated so that operational semantics could be defined for those pro-grams requiring this construct. The suggested programmer-controlled termina-tion mechanism was associated with a block of operations; it allowed programsto be written with the usual input assertions, with the handling of bad input notaffecting program structure, and resulting in a cost only to those blocks whereit might be used. These ideas influenced the design of Ada exception handling.

The Rationale also refers to the Bliss language [Wulf et al. 1971] developedat DEC in the mid-1970s as influential in the definition of Ada exceptions. TheRationale emphasizes that the designers wanted to being able to prove thecorrectness of programs [Luckham and Polak 1980] and to optimize programswith exceptions. These properties led to the rejection of the resumption model,which renders both of these difficult.

Perry in his ICSE’89 award-winning paper entitled The Inscape Environmentdiscussed the specification and design of exception handling as an integral partof system development when large systems are built by many developers. Hismodel for specifying exceptions is based on an extension of Hoare’s input/outputpredicates [Hoare 1969; Perry 1989]. Perry examined the Larch specificationlanguage [Guttag et al. 1985], but preferred a nonalgebraic approach. It is clearfrom his paper that Perry was influenced by programming language technol-ogy in his choice of how to specify exceptions and their handling in Inscape,whose goal was to provide an integrated software development environmentfor large groups of developers building large software systems. He describeda design in which module interface specifications include descriptions of bothexceptions to be handled and handling strategies. His program constructiontool checked that exceptions are handled as specified in the constructed code.Changes in exception handling are considered by the change evolution man-ager component of his system. The Inscape environment shows that the treat-ment of exceptions in programming languages in the late 1980s influenced



software engineering research on the design of programming developmentenvironments.

The subject of exception handling and how it should be added to C++ wasa major topic of debate at the 1990 USENIX C++ Conference. Koenig andStroustrup [1993] argued for their model of exceptions as objects (which waseventually incorporated in C++) in their 1990 USENIX C++ Conference pa-per. They also referred to the termination model of PL/I, CLU and Modula-3[Harbison 1992] as preferable to any resumption model. Essentially, C++ ex-ception handling seems an outgrowth of the techniques defined in CLU andModula-3. Statements are executed within a try block, which has associatedcatch blocks (typed exception handlers) that are handlers for some of the excep-tions that can be thrown from within the try block. This design was influencedby the work on fault-tolerant systems by B. Randall [Ellis and Stroustrup 1990].Again we see programming language design being influenced by software en-gineering research. Exceptions are handled locally or by walking up the callchain to find the first appropriately typed handler. The set of exceptions pos-sibly thrown by a function (directly or indirectly) can be listed as part of thefunction declaration. Violations of this exception specification are dealt withat run-time, not compile time as in Java. This decision to avoid compile-timechecking was in part due to the ability to link to C, functions that have noexplicit exception constructs. When a function with an exception-specificationthrows an exception not on its list, then the function void unexpected() iscalled and execution is usually halted.

More recently, aspect-oriented programming describes how crosscutting con-cerns in an object-oriented program can be addressed by new compositionalmechanisms in addition to inheritance. At ICSE 2000, this new paradigm wasused by having aspects [Kiczales et al. 1997] express the detection and han-dling of exceptions [Lippert and Lopes 2000]. The main idea was to reduce theamount of redundant handling code in a program. The specific language used,AspectJ, allowed abstract crosscuts (i.e., templates) that can be instantiatedin many different locations where exception handling required the same ac-tions. In their case study using a large Java application containing 750 classes(including 150 test classes), the authors reduced the size of the exception han-dling code from 10.9% of the total lines of code to 2.9% lines of code on average.This represented a significant reduction in catch statements over the originalprogram. This research paper is indicative of the strong interaction betweensoftware engineering and programming language research and researchers. Inthis case, a paper describing how to code exceptions (a programming languagemechanism) to ensure program reliability (a software engineering desiderata)through the use of aspects (a programming language mechanism) was pre-sented at the premier annual software engineering conference.

As another example of the close tie between the disciplines, Robillard andMurphy [2000] discussed in their paper why the design of exception handlingin an application is so difficult. The focus is software design, namely how toregularize the exceptions that are passed between components of a softwaresystem, but intertwined in the discussion is the essential character of exceptionsand their handling in Java. The technique applied is software compartmenting,



first described by Litke [1990] at the TRI-Ada 1990 Conference. This techniquedivides software into compartments, defines precise and complete exceptioninterfaces for each compartment, and automatically verifies the conformanceof the actual program to compartment specification [Robillard and Murphy2000]. The paper described a case study of software compartmenting using theauthors’ own Java tool as data. The authors also developed guidelines for Javaexception usage. In their discussion, they referred to exception handling bothin CLU and C++. This is another software engineering research project thatbuilds on programming language design and research.

Figure 2 provides a time line for concepts related to types and exceptions.

3.4 Concurrency

The theoretical foundation of the concurrency that is expressed in program-ming languages today was laid in the 1960s and early 1970s. Initially, the needfor concurrency in programming languages was driven by applications, suchas simulation in Simula 67 [Dahl and Nygaard 1967]. The initial concurrentconstruct that appeared in Simula 67 was a coroutine, which allowed a quasi-parallel execution of the program. In 1965, Dijkstra published an importantpaper in which he described how to use concurrency to express the solutionto the problem of sharing data among concurrent processes. In 1968, Dijkstra[1968a] showed how to use semaphores to solve a variety of synchronizationproblems and introduced the famous dining philosophers problem.

At the same time, Algol 68 [van Wijngaarden et al. 1968] was the first pro-gramming language to allow expression of true concurrency by the programmerthrough the parbegin-end construct. Later, [Courtois et al. 1971] introduced thereaders/writers problem and formulated solutions to it using semaphores.

During the 1970s, most concurrency was expressed at the operating sys-tem level, through time-sharing operating systems with multiprogramming.In his HOPL-II article on Concurrent Pascal, Brinch Hansen relates how “theidea of monitors evolved through discussions and communications among E. J.Dijkstra, C.A.R. Hoare, and me (Brinch Hansen) during the summer and fall of1971” [Hansen 1996]. Influenced by the work of Dahl in Simula 67, the concur-rency model of Concurrent Pascal, developed in the mid-1970s, refined the def-inition of monitors into a key language construct [Hansen 1972, 1975]. BrinchHansen describes a monitor as “a set of shared procedures which can delay andactivate individual processes and perform operations on shared data” [Hansen1996]. Conceptually, monitors can be viewed as an extension of the idea of anabstract data type to a concurrency setting.

C.A.R. Hoare later described his implementation of monitors [Hoare 1974b]built with semaphores, for shared memory concurrency models in operatingsystems. According to Brinch Hansen, Hoare’s ideas were available in publicpresentations in 1972 and 1973. Thus, these two researchers codeveloped themonitor concept. Later, in his seminal paper in 1978, Hoare described notationaltools for programming languages to express concurrency, that is, communicat-ing sequential processes (CSP) for message-passing concurrency models [Hoare1978]. Clearly, there was close interaction between programming language



Fig. 3. Time line for Concurrency. The arrows in the diagram on the right show relations betweenconstructs related to concurrency, with the times of their first appearance. The programming lan-guages listed to the left of the time line are shown at their inception year. Not all the programminglanguages shown contain concurrency constructs.

designers and software engineering researchers in these early days when thetwo disciplines were beginning to distinguish themselves from one another.

Ada [DOD 1980], also designed in the mid-1970s, was the first widely usedprogramming language designed with language constructs for concurrency,based on Hoare’s message-passing CSP. Java [Gosling et al. 1996], introducedin the mid-1990s, advanced the monitor concept by encapsulating access toshared data by synchronized methods and code blocks.

As is evidenced by this historical narrative, the early unified software en-gineering and programming language community heavily influenced the con-cepts and the notation used to express concurrency in programming languages.There is also evidence that the more recent software engineering research hasfocused on building tools and techniques for managing and analyzing concur-rent programs. This includes work in program analysis, testing, anomaly detec-tion, replay and debugging of concurrent programs. Surprisingly, except for theearly research in the 1960–1970s, there has been little influence as evidencedthrough published works of software engineering research on the design of con-current constructs in programming languages, although language constructsfor concurrency continue to be developed [IEEESW 1989].

The time line for concurrent constructs is given in Figure 3.



4. VISUAL PROGRAMMING: FROM RESEARCH TO PRACTICAL USE

This report thus far has focused on the impact of software engineering researchon programming languages that have textual syntax, but visual syntaxes forprogramming have also become important in recent years, as the popularityof Visual Basic helps to demonstrate. Although software engineering researchgenerally aims to improve the quality of software and the processes, languages,and tools used to create this software, most of this work focuses only indirectlyon the human programmers who create the software. In contrast to this ma-jority, research on visual programming aims directly at the human aspects ofprogramming. Therefore, in this section, we focus on the evolution of visualprogramming properties that are becoming mainstream, as they relate to thecognitive problem-solving needs of human programmers.

Visual programming refers to any system that allows a program to be spec-ified using two- (or more) dimensional expressions, such as diagrams, icons,color coding, multi-dimensional annotations, and/or even graphical actionsthemselves [Burnett and McIntyre 1995]. When multi-dimensional expres-sions, called visual expressions, are the syntax of a new programming language,the system is called a visual programming language. For example, Prograph[Cox et al. 1989] was a research (and later, commercial) object-flow visual pro-gramming language in which components of the classes were specified by plac-ing icons, and whose method syntax consisted of dataflow diagrams. Anotherexample is Peridot [Myers 1990], a research visual programming language forprogramming user interfaces, part of whose syntax was the demonstration ofactions on data objects. When the visual expressions are used to provide asupporting environment for a preexisting textual programming language, thesystem is a visual programming environment. For example, Pecan [Reiss 1984]was a research visual programming environment for Pascal. Snapshots of vi-sual programming approaches of the 1980s, when many of these approachesemerged, are shown in Figure 4.

In general, the aim of visual programming is to reduce the cognitive bur-den on human programmers, through devices that reduce the mental effortrequired to access and make sense of the available information. Although vi-sual programming research spans multiple subdisciplines of computer science,a large portion of it has taken place within the software engineering community.

The impact of visual programming research upon modern programming lan-guages lies in two areas. The first area of impact is the use of visual com-munication devices to illustrate programs and their behavior in software de-velopment environments for professional programmers. Today visual devicesthat descended from early visual programming research can be found in manymodern software development environments. The second area of impact is thedesign of visual programming languages that are viable for audiences who arenot expert programmers in traditional programming languages. Visual Basic,which is of great practical importance given its wide usage, demonstrates bothof these impact areas.

In other sections of this article, we have discussed software engineering re-search culminating in programming language constructs that enable language



Fig. 4. Snapshots of 1980s era visual programming systems: Clockwise from left: Prograph pro-gramming was done by drawing dataflow diagrams (left; figure re-created from Cox et al. [1989]),and Prograph objects arriving at the ports on the dataflow diagram could be inspected by double-clicking to reveal the object structure and values shown (top; figure is from TGS Systems [1990]).PECAN (right) featured a variety of graphical and textual views of Pascal programs, and visuallyhighlighted the portion of the code being executed in both of the views shown (figure is from Reiss[1984]). Peridot allowed programmers to specify user interfaces by directly placing the GUI objectsas desired and demonstrating the objects’ responses to GUI events (bottom; figure is from Myers[1990]).

processing systems to automatically detect or prevent certain reliability issuesin a program. For example, abstraction constructs allow some inappropriatedata accesses to be prevented by the system, and type checking allows thesystem to detect type errors. However, the primary influence of the visual pro-gramming work was less on new language constructs per se, and more on lan-guage properties that are realizable by visual programming mechanisms. Fur-ther, these properties are tied to enabling human programmers, rather thanlanguage processing systems, to detect or avoid certain reliability issues in aprogram. We begin by considering four properties that emerged from the vi-sual programming research done in the software engineering community priorto 1991: concreteness, directness, explicitness, and immediate visual feedback.We then show examples of how these properties have been instantiated in Vi-sual Basic, which emerged in 1991.



4.1 Emergence of Visual Programming Properties

Although there were a few pioneering works in visual programming in the1960s and 1970s (e.g., Sutherland [1963, 1966]; Smith [1977]), in the 1980svisual programming gathered momentum as a research area in the program-ming language and software engineering communities, initially following twoapproaches. One concentrated on mapping each traditional programming con-struct one-to-one to an icon (e.g., Glinert and Tanimoto [1984]). The other con-centrated on new visual approaches to programming that deviated significantlyfrom the traditional methods, such as programming by wiring together con-straints (e.g., Borning [1981]) or by demonstrating desired behaviors on thescreen (e.g., Rubin et al. [1985]). Many of these systems had advantages thatseemed exciting and intuitive when demonstrated with toy programs, but raninto difficult problems when attempts were made to extend them to more real-istically sized programs. These problems led to an early disenchantment withvisual programming, causing some to believe that visual programming wasinherently unsuited to real work.

To address these problems, visual programming research moved in two di-rections. The first direction involved the incorporation of visual expressionsinto integrated programming language environments, for those specific partsof software development in which visual expressions demonstrated obvious ad-vantages for human programmers. The second direction, involving the develop-ment of domain-specific languages, increased not only the kinds of applicationssuitable for visual programming from start to finish, but also broadened the setof people who could program.

4.1.1 Visual Programming via Programming Environments. Startingin the early 1980s, integrated programming environments such asSmalltalk [Goldberg 1984], the Cornell Program Synthesizer [Teitelbaumand Reps 1981], Cedar [Teitelman 1984], Pecan [Reiss 1984], and Gandalf[Habermann and Notkin 1986] began incorporating visual expressions. (Fora history of the increasing use of visual expressions during the evolution oflanguage environments, see Ambler and Burnett [1989].) The synergy of visuallanguage research with language environment research led to the advent ofpractical visual programming environments for traditional languages. The vi-sual expressions were used for selected aspects of software development (e.g.,for GUI programming), for explicitly depicting relationships and flow, and forvisually combining textually-programmed units to build new programs (e.g.,Hirakawa et al. [1990]). Eventually, this merging combined syntax-directedediting and grammars for both textual and visual expressions (e.g., Chang et al.[1989], Crimi et al. [1990], and Helm et al. [1991]), which further increased theviability of incorporating visual expressions into programming environments.

The successes and failures from these early approaches led to investigationinto more general properties of visual programming, and how these propertieswere linked with supporting human programmers’ software development ef-forts. For example, one critical reason for the success of incorporating visualexpressions into programming environments was that doing so promoted theproperty known as directness or closeness of mapping [Green and Petre 1996]:



allowing the programmer to express solutions to a subproblem (e.g., GUI lay-out) using a notation similar to the problem itself (e.g., by drawing the desiredlayout). Directness is important because it avoids the cognitive burden and as-sociated error potential of translating from one way of describing ideas to adifferent way.

Other properties supporting human problem-solving are explicitness, con-creteness, and immediate visual feedback. Explicitness in depicting relation-ships and dependencies, such as via dataflow diagrams, eliminates the error-prone work of tracking down these relationships manually. The property ofconcreteness denotes working with concrete data values to express or exploreprogram logic. Consider a function or procedure definition, which is abstractin the sense that it does not include any actual data from a specific instanceof invocation. When writing such a function, programmers have to model (intheir heads or on paper) the actual data that will be present when the functionis invoked. This modeling process is an additional attention cost that concretesample values can help to eliminate. A system’s ability to provide immediatevisual feedback about program semantics, such as immediately showing thecalculated result on values, is facilitated by concreteness. This feedback fea-ture has been shown to be heavily used in problem-solving by both novice andexpert programmers [Green and Petre 1996]. As visual programming researchmatured, it became evident that the support visual expressions can lend toproperties such as those described above, not the use of visual expressions perse, is the aspect of visual programming important to human productivity inproblem solving and programming.

4.1.2 Domain-Specific Visual Programming Languages. The other direc-tion followed by visual programming researchers was to increase the kindsof applications suitable for visual programming from start to finish, throughthe development of domain-specific languages. These researchers incorporatedthe previously discussed properties. In addition, because many domain-specificlanguages are aimed at specific types of audiences as well as specific types ofapplications, these researchers began to focus more carefully on the audiencesfor whom their languages were intended. Thus, visual programming becamean enabling mechanism for a phenomenon known as end-user programming,in which people not trained as programmers develop their own applications.

Designing a visual language for use in a specific problem domain by a specificaudience is an example of language research that aims at supporting the di-rectness property. It allows people to program directly in their domain-specificnotations using visual expressions (e.g., icons and diagrams) reflecting the par-ticular abstractions, diagramming traditions, and vocabulary specific to thatdomain, instead of requiring people to translate their vocabularies to tradi-tional programming language terminology. This approach produced a numberof successes, first in research and then in the marketplace. For example, todaysuch audiences include teachers creating educational simulation programs bydemonstration (e.g., Roschelle et al. [1999]) and laboratory scientists, who cangraphically wire measurement data through icons representing summariza-tion and visualization tools using LabView, a commercial visual programming



Fig. 5. Visual Basic. The center window shows Visual Basic’s direct placement of GUIobjects in the desired GUI layout. The StrikeThrough subobject has been selected, caus-ing its type to be displayed along with its “properties” (lower right of the screen shot),i.e., the object’s data members’ names and values.

language for the domain of laboratory measurement [Baroth and Hartsough1995].

4.2 Visual Basic’s Instantiations of Visual Programming Properties

The properties described in the previous section can be seen in three of Vi-sual Basic’s features: its support for GUI programming, its use of visual pro-gramming in its integrated language environment, and its programming-by-demonstration features (found in the language subset known as Visual Basicfor Applications or VBA).

The precursor to Visual Basic first took shape during 1988–1990 as a visualprogramming language for Windows shell programming not associated withBasic [Arnson et al. 1992; Cooper 1996]. Microsoft purchased the concept, mar-ried it to Basic, and Visual Basic made its debut in 1991. In the 1980s and early1990s, the visual programming properties discussed previously had not yet be-come widely recognized as such; rather, researchers were still experimentingwith specific features instantiating those properties. Thus, it is not surprisingthat Visual Basic’s instantiations of these properties correspond to the specificfeatures of the pioneering systems such as those in Figure 4.

For example, the directness property figures prominently in one of the bestknown features of Visual Basic, namely the ability to specify a GUI layout bydirectly manipulating the visual properties of GUI objects (e.g., their placementand size). The version of this feature in Visual Basic is shown in Figure 5. Thecenter window shows the support for programmers to be able to directly placeobjects in a GUI as desired. This feature was pioneered in the Peridot visuallanguage [Myers 1990], as can be seen by comparing this window with Peridot’sversion (bottom of Figure 4).



An instantiation of the immediate visual feedback property can also be seenvia the GUI objects in Figures 4 and 5. As these figures show, in Visual Basic(as well as Peridot), moving and resizing the source code (i.e., elements of thedrawing on the screen) is immediately reflected in how the GUI appears, sincethe representation of the source drawing and its ultimate result are one andthe same.

The immediate visual feedback property is due in part to the use of concrete-ness in Visual Basic in the same manner as in Peridot. As Figure 5 shows in itscenter window, programming is done via specific instances, not just abstractvariables, in performing manipulations of GUI objects. Also, the StrikeThroughsubobject has been selected, causing its properties to be displayed in the prop-erties pane (lower right of Figure 5), which lists the object’s attributes/datamembers in a column on the left along with their values in the right column. Theprogrammer can access and manipulate these properties, a capability reminis-cent of the Values window of Prograph (top of Figure 4). In Prograph, as later inVisual Basic, any value (object) can be opened via direct manipulation, causingthe object’s type to be shown (highlighted top left of Value window), along withits attributes’/data members’ names (below the icons) and values (above theicons).

The VBA subset of Visual Basic is embedded in several Microsoft products,including Excel, PowerPoint, and Word. VBA has been the language to supportend users in the construction and editing of macros. Although the user cancreate these macros by typing in VBA directly, the more usual approach isto begin by demonstrating the desired logic via example (as in Peridot). Forexample, in Excel a user can demonstrate a macro by recording the actionsthey perform on Excel objects (cells, formulas, spreadsheets, etc.). VBA’s supportfor programming-by-demonstration is another instantiation of the directnessproperty.

The explicitness property can also be seen in VBA. In VBA, when a userchooses to step through execution one line at a time, the editor highlights thelines being executed, a feature found in other modern visual environments aswell. This feature dates back to the Pecan visual programming environmentof 1984-1985 [Reiss 1984], which graphically highlighted the portions of codebeing executed, as shown at the right side of Figure 4. This is an instantiationof the explicitness property, since the system is explicitly depicting control flowas the system executes.

Visual Basic has, of course, also incorporated numerous language featuresthat are not related to visual programming. For example by 1992, Visual Basicincluded the concept of objects, which eventually led to incorporation of a formof classes in 1996.

4.3 Software Engineering Trends in Modern Visual Programming Research

Three recent software engineering trends have emerged in visual program-ming research. First, software engineering research regarding language fea-tures such as abstraction, exception handling, and types, discussed in Section 3,has begun to have significant impacts on visual programming language features



in the last few years. In order for visual programming languages to scale to in-creasingly large software projects, researchers have worked to devise ways toincorporate more powerful language features without loss of the properties thatassist human problem solving. Burnett et al. [1995] surveys the beginnings ofvisual programming research in these directions.

Second, with the advent of end-user programming, emerging projects havebegun to consider the concept of end-user software engineering [Burnett et al.2003]. This research draws from results of software engineering research intohow to support phases of the software lifecycle beyond the coding stage. Com-bining this research with visual expressions, machine learning techniques, andemerging HCI research, researchers are now developing new software engi-neering methodologies to help end-user programmers reduce defects by sup-porting them beyond the coding stage, such as with incremental visual testing[Rothermel et al. 1998], semi-automatic defect detection [Bottoni et al. 1997;Miller and Myers 2001; Raz et al. 2002], and tightly integrated assertion mech-anisms [Burnett et al. 2003].

Third, as visual programming research has matured, researchers havelearned that visual programming research is not a matter of learning whethervisual expressions are overall superior to text-only notations: every notationhas strengths and weaknesses [Green and Petre 1996]. Rather, the essence ofvisual programming research is to learn how to harness visual programming’sexpressive power to support particular properties that assist human cognition,such as the closeness of mapping, concreteness, explicitness, and immediatesemantic feedback properties discussed above. Progress in this direction hasbeen made largely through multidisciplinary work that draws not only fromsoftware engineering and language research but also from human-computerinteraction (HCI) research, with a strong emphasis on empirical work. One ex-ample of this direction is the work of Pane et al. [2002], who devised a domain-specific programming language only after performing empirical work with theintended audience, to elicit the principles and constructs that were eventuallyused in the design of the language. This increasing emphasis on drawing fromand contributing to empirical foundations is having an important impact onthe measurable effectiveness of visual programming. Further, by demonstrat-ing the impact of empirically-based research involving humans on the genuineeffectiveness of software engineering techniques, an approach long advocatedby several software engineering researchers [Gannon 1977; Basili et al. 1986;Tichy 1998] but too rarely followed, visual programming research makes a valu-able methodological contribution.

The time line graph for visual programming is provided in Figure 6.

5. INTERVIEWS WITH PROGRAMMING LANGUAGES DESIGNERS

To obtain firsthand historical information about the influence of software en-gineering research on programming language design, a set of language de-signers were contacted by email or phone and asked about influences ontheir work. Designers who responded to us were Professor Boris Magnusson(Simula 67), Professor Niklaus Wirth (Pascal, Modula), Dr. Jean Ichbiah (Ada),



Fig. 6. Time line for visual languages.

Dr. Brian Kernighan (scripting languages), Dr. Bjarne Stroustrup (C++), Den-nis Canady (Visual Basic), Tim Lindholm (Java), and Tucker Taft (Ada 95).Each of the participating designers was sent the list of questions below andthen either answered them by email or phone.

The following questions were asked about the influences on the interviewees’language designs, where xxx stands for the particular programming languagewith which the designer was involved.

(1) What were the problems that you were addressing in your design for PLxxx?

(2) What programming practices or software engineering research do you thinkinfluenced your language design, positively or negatively?

(3) Can you recollect any of the papers you were reading, the conferences youwere attending and the people you were talking to when you were designingyour language xxx?

(4) Were there specific applications that drove your design?(5) If you were to design a programming language today, how would it differ

from current programming languages?

Dr. Kernighan, designer of awk, indicated that he thought there was littleinfluence of software engineering research on scripting languages. Kernighanremarked, “I think there’s been only minimal back and forth between scriptinglanguages and software engineering, though perhaps it’s increasing. Speakingspecifically for awk, there was no influence at all from any ‘software engineering’perspective . . . as for the influence of scripting languages on software engineer-ing, I don’t see much there either.” Thus, he declined to answer the questionswe posed.



In this section, excerpts from these interviews are presented, in roughlychronological order of the language they designed, to show relevant influencesbetween software engineering research and programming languages, as re-called by the language designers.

Professor Boris Magnusson (Simula 67):Professor Magnusson has personal knowledge of the early days of Simula

67. We were grateful for his participation, especially given the recent untimelydeaths of Nygaard and Dahl, who jointly won the ACM Turing Award in 2001for the development of Simula 67.

1. What were the problems that you were addressing in your designfor Simula 67? Complexity of large software systems. The experience behindSimula 67 came from developing large discrete event simulation models, pro-grams that indeed tend to get large, complex and involved. These models alsoinclude a notion of concurrency, although it is not necessarily reflected in theexecution of the model.

2. What programming practices or software engineering research doyou think influenced your language design, positively or negatively?The notion of a safe language inherited from Algol is perhaps in this category,the strive to find trivial errors in a program, errors in respect to the languagedefinition, at an early stage. The inclusion of automatic garbage collection,available in LISP systems at the time, was motivated by the same reason. TonyHoare’s work on record handling influenced the formation of the class concept.

[Ed. note: There is no separate response in this interview to question 3.]4. Were there specific applications that drove your design? No! It

(Simula 67) is a general purpose programming language.5. If you were to design a programming language today, how would

it differ from current programming languages? I would put more stresson supporting building of notions of concurrency in the language. This pointis sadly missing in modern languages. Introducing ONE notion of concurrencyin a language, like Thread in Java, is too limiting. If you, for example, want towrite a program that animates a simulation, you need two different time basesand scheduling mechanisms at the same time.

Professor Niklaus Wirth (Pascal, Modula):Professor Wirth was awarded the ACM Turing Award in 1984 for developing

several innovative computer languages, including Modula and Pascal.1. What were the problems that you were addressing in your design

for Pascal and Modula? Two purposes stood in the foreground: 1.To obtain alanguage suitable for system programming. . . 2. To obtain a language suitablefor teaching the fundamentals of programming in a lucid, systematic manner,without undue references to particular computers and implementations.

2. What programming practices or software engineering research doyou think influenced your language design, positively or negatively?Software Engineering was not yet a subject of research; even the term did notexist. Programming methods was the name of the subject. Of great influence toPascal was Structured Programming, put forth by E. W. Dijkstra. This methodof proceeding in a design would obviously be greatly encouraged by the use of a



Structured Language, a language with a set of constructs that could freely becombined and nested. The textual structure of a program should directly reflectits flow of control.

Another key idea stemmed from the fact that the computing profession wassplit into scientific computing and commercial data processing, and from myattempt to unify their bases . . . . Of negative influence was the need to win pro-grammers for a new language. This need forced me to retain constructs andfacilities that programmers were used to and did not want to miss, although Iknew they would have to be left out in the interest of safer programming. Exam-ples are the go to statement, the variant record (data overlay), and incompleteparameter type specification.

3. Can you recollect any of the papers you were reading, the confer-ences you were attending and the people you were talking to when youwere designing Pascal and Modula? By far the biggest influence came fromthe Report on Algol 60. My interest in programming languages was increased byProf. A. van Wijngaarden, who spent a sabbatical semester at Berkeley, where Iwas working for my doctorate. I was brought in contact with the Algol WorkingGroup 2.1 of IFIP, and there the most influential colleagues were E. W. Dijkstra,C. A. R. Hoare and P. Naur. We attended several work meetings and exchangedmany ideas, which first led to Algol W (1966, implemented at Stanford), thento Pascal (1970, implemented in Zurich).

Modula-2 followed in 1979 as intended successor to Pascal, and it grew out ofthe need to further develop Pascal to cater for the needs of large systems (soft-ware engineering). Several ideas came from the language Mesa (B. Lampson,J. Mitchell, J. Morris, Ch. Geschke), to which I was introduced during a sab-batical year at the Xerox Palo Alto Research Center in 1976/7. My main con-tribution was (as to some extent also in the case of Pascal) combining, moldingall constructs into a single, harmonious framework, and in simplifying them,extracting the essentials and discarding the bells and whistles.

4. Were there specific applications that drove your design? In the caseof Pascal, the need for a decent language for teaching and for system program-ming. In the case of Modula-2, the need for a language adequate for modularsystem building, and the desire to finally get rid of antiquated constructs (suchas go to).

5. If you were to design a programming language today, how wouldit differ from current programming languages? If you mean Java andC# by current languages, then my answer is: Look at Oberon (1988). Most oftheir features had been present in Oberon, my successor to Modula-2, some7–10 years earlier. The chief difference to Java and C# is its size, in terms ofnumber of syntactic rules, of number of pages of definition, and in the size of itscompilers. The Report was only 16 pages long, and the entire Oberon compilertook about 45 Kbyte, was very efficient, and due to its transparency, highlyreliable. Oberon was Modula-2 with object-orientation.

The sad thing about new developments is that they always seem to turnout more complex rather than simpler. Yet it is known that progress in (math-ematical) sciences had mostly been through simplification and unification ofconcepts.



Dr. Jean Ichbiah (Ada):Dr. Ichbiah was the principal designer of Ada.[Ed. note: There is no separate response in this interview to question 1.]2. What programming practices or software engineering research do

you think influenced your language design, positively or negatively?Doing programming language design in the mid-1970s, we were addressing aset of objectives derived from software engineering, definitely. These were theyears when hardware prices were coming down significantly and machines werebecoming much cheaper. It was possible to run much larger applications, butprevious programming methods didn’t scale. It was like constructing a smallhut versus a skyscraper. Trying to scale methods of developing programs wasdifficult; the costs were increasing in exponential fashion rather than linearlywith program size. . . we learned how to scale with linear cost, by introducingmodularization and packaging.

Dijkstra had a profound idea, that programs should become closer to text.If you could read a program and understand it, then it was a good program.You should be able to read a program like a book; this was a notion of linearity.The initial ideas were expressed in Dijkstra’s Go tos considered harmful paper,but this title was a misnomer. Dijkstra was laying the foundation of how tounderstand a program through linear thinking. Twenty-five years later we cansee the absolute necessity for this idea, that the complexity of code be linear inits size. This was essential to allow systems to grow in size. The key emphaseswere to make programs readable, maintainable, and reliable. Readability is byfar the more important issue as it controls the other two.

Dijkstra saw an infinite space of possible programs and used a constructiveapproach to extract an infinite subset of programs that you can read easilyand can convince yourself that they are correct. . . . As an example of this inthe design of Ada, I am proud of the textual separation of specification andimplementation, as it lets you know what you need to know to use a module,without getting into details of implementation.

We systematically designed PL features in a manner like structural engineer-ing; that is, we would look for failure patterns and then try to make somethingthat would not break.

3. Can you recollect any of the papers you were reading, the confer-ences you were attending and the people you were talking to when youwere designing Ada? There were several working groups that met severaltimes a year. Two were the IFIP Working Group 2.4 on System ImplementationLanguages [IFIP 2004] and the Purdue Europe LTPL-E committee. There wasa conference on system implementation languages in 1973 or 1974 in Trond-heim. This was a not too big conference and at its end, about 10 researchersmet and formed an IFIP working group that provided collegial feedback andstimulation to participants about 3–4 times a year. Participants included BillWulf and Jim Horning. Another influential group was the IFIP 2.3 group onAlgorithmics. These groups gave researchers a chance to meet multiple times ayear, present what they were working on and to discuss it with peers who couldcomment and criticize.



4. Were there specific applications that drove your design? The AdaPL was fairly general, however one new aspect it addressed was real-time pro-gramming. The metaphor used at the time, to talk about applications that woulduse this new paradigm, was to think of airplanes as software with wings. An-other new aspect of computing addressed by Ada was programs designed to beexecuted on distributed computers.

5. If you were to design a programming language today, how wouldit differ from current programming languages? If I were to design Adatoday, it would not be much different in a way. I would try to make it evensimpler. Although I do not want to design another PL now, I would take Adaand trim it. For example, I would eliminate parameterized types (i.e., variantrecords) Generics also appear in Ada but may be less useful than originallythought . . . . Inheritance seems to me to be a low-level concept; this is a detailof implementation rather than a conceptual thing.

When we were inventing modularity in the 1970s, we were solving the prob-lem of scalability. This resulted in making software that scales linearly. Nowthere is a full industry of components that uses this philosophy, across manyprogramming languages. Improvements in programming languages today aresecond order effects.

Dr. Bjarne Stroustrup (C++):Dr. Stroustrup was the designer and original implementor of C++.1. What were the problems that you were addressing in your de-

sign for C++? Initially, I simply needed a tool to help me with a projectto distribute the Unix kernel across multiple machines. I saw two areas ofneed: To express the logical partitions within the kernel code (the kernelwas—and is—written in C, and C doesn’t provide facilities for directly rep-resenting logical partitions and their communication paths) and to write sim-ulations to determine the effects of different communication patterns result-ing from different software configurations and different types of hardwaresupport.

2. What programming practices or software engineering research doyou think influenced your language design, positively or negatively?Ideas for operating system organization and application building, which I wasexposed to at Cambridge (notably the CAP computer and its use of hardwareprotection) and Newcastle (the C++ notion of exceptions and their use) wasdirectly inspired by the work on reliable systems by Brian Randell’s group.

The “object-oriented” ideas from Simula 67, and appreciation of static typechecking from Simula 67 and Algol 68 (this appreciation wasn’t widely sharedamong people building operating system kernels).

3. Can you recollect any of the papers you were reading, the confer-ences you were attending and the people you were talking to when youwere designing C++? I went to SIGOPS, USENIX, and a distributed systemsconference. . . . However, my main influence was my colleagues in the Bell LabsComputer Science Research Center, including Sandy Fraser, Steve Johnson,Brian Kernighan, Doug McIlroy, Bob Morris, Gregg Chesson, Stu Feldman,Dennis Ritchie, and Steve Bourne. This was in the very early years where the



key notions of C++ were formed. I think that it is significant that the systemspeople dominated over the language people.

4. Were there specific applications that drove your design? It startedwith the distributed operating system kernel, which I never completed, andthe simulations. For years after, my bread and butter work in the Labs relatedto various forms of simulation (network traffic, telephone use, board layout,processor register design, etc.). I also worked with embedded systems and avariety of systems programming tasks. I remember that the application thatfinally caused me to introduce operator overloading wasn’t the obvious math-ematical uses of operators, but modeling of bits, registers, and signals in aprocessor design.

At the time, the UNIX system and networking loomed large in the collectiveimagination of the Lab, as did telecommunications applications (not just hugeswitching applications, but also small switches, embedded control applications,and hand-held gadgets usually weighing a few pounds). In the 1980s, Bell Labswas an environment very rich in diverse real-world applications and peoplewith both research training and real-world experience.

5. If you were to design a programming language today, how wouldit differ from current programming languages? A language design—likeall design—should arise from a need. I don’t clearly see a problem with currentprogramming practice that would best be solved by a new language. Note thatwhen I designed C++, I based it on an existing language, C, to build on existingstrengths to have a complete and useful tool very early on. Should I designanother language, I’d probably do something similar again.

Dennis Canady (Visual Basic):Dennis Canady was a member of the original Microsoft Visual Basic design

team.1. What were the problems that you were addressing in your design

for Visual Basic? Visual Basic was shaped during the emergence of Windows.Since Windows itself was just emerging, there naturally weren’t many Windowsapplications, but applications are needed to make an O/S useful. So, we wantedto make Windows applications easy to write. For one thing, we wanted an in-teractive development environment in which the performance of the languagewould be similar to that of compiled code, but that would have the interactivityand other nice features that come from an interpreted environment. Anothergoal was to give developers of business applications a way to develop Windowsapplications without having to write all that window-oriented code by hand.

2. What programming practices or software engineering research doyou think influenced your language design, positively or negatively?Interactive debugging practices were an influence. In fact, Visual Basic’s designwas influenced by our desire for an execution model that could allow a goodinteractive debugging environment. For example, we wanted to provide quickfeedback about syntax errors, and to point to identifiers in the source. TurboPascal came out about that time, and had an influence on our design. Forth wasalso an influence, which led to a threaded P-code interpreter. Of course, otherversions of Basic, including QuickBasic and Microsoft’s MacBasic, were also



influences. We also looked at visual programming languages, but at the timemost of them were dataflow-based, which did not seem like a good fit. I think wesaw ThinkPad, but not many other programming-by-demonstration languages.Object models (C++, Ada, Smalltalk) were also influences. But creating anapplication in Smalltalk was too large, too isolated from Windows, and tooslow. We asked “How can we do better?” Then Ruby came along [Ed note: thiswas the code name for the visual programming language for Windows shellprogramming mentioned in Section 4.2.]. We purchased the concept, and usedit for Visual Basic.

3. Can you recollect any of the papers you were reading, the confer-ences you were attending and the people you were talking to when youwere designing Visual Basic? I went to some OOPSLAs around that time. Iwas also following the C++ world, and Bertrand Meyer’s work on Eiffel.

4. Were there specific applications that drove your design? Windowsbusiness applications.

[Ed. note: There is no separate response in this interview to question 5.]

Tim Lindholm (Java):Tim Lindholm is a Distinguished Engineer for the Java Software group at

Sun Microsystems. He was an original member of the Java project at Sun andremains the architect of the Java virtual machine.

1. What were the problems that you were addressing in your designfor Java? The language that became known as Java was initially called Oak,and was originally used for programming an embedded device, a sort of crossbetween a large PDA and a super-duper remote control. The next use of Oakwas as the language for a video-on-demand project, the project in which I wasfirst involved. (Early in 1994, Lindholm joined the project.) When the marketfor video-on-demand was created in 1994, a portion of the team went off to in-vestigate how to use Oak as a safe way of deploying applications over the WorldWide Web. It is interesting that in the design of Oak, programming languageconcepts were selected that had in some cases been around for 20 years. Evenso, the first two applications of the technology went nowhere. . . One of the maingoals of Oak was to enable programs to safely move around a network of het-erogeneous computational units. When moving Oak to the Web the team addeda small number of key technical innovations, among them class loaders andverification of program type safety. . . . Then known as Java, the language hitthe wave of popularity just right: while HTML could be downloaded to browserson various machines, it only provided static content; Java applets could makeWeb content dynamic, and people grokked the idea. . . . There were 2 millionpeople working with HTML and considering themselves to be programmingthe Internet. At that point we offered them Java as a power tool. . . .

2. What programming practices or software engineering research doyou think influenced your language design, positively or negatively?At this time, people were starting to be upset with C++ because it was hard towrite programs you could understand and it was not safe, compiling to platform-specific executable code. Gosling called Java, C++ without guns and knives. TheSun team could not use C++ for the applications they needed to write. When



asked “Why was C++ inadequate?” he replied, C++ programs compiled to na-tive binaries, which made it impossible to safely move them about the Internet,and at least hard to make them run on different architectures. Also, we feltthat C++ was sufficiently hard to program in that less-skilled programmers,who we hoped to reach, would have difficulty with it.

Software engineering practices that influenced us included many object-oriented ideas, as expressed in C++ and Smalltalk-80. Java designers need togive credit to folks who developed other object-oriented languages, from whomthey borrowed ideas.

3. Can you recollect any of the papers you were reading, the confer-ences you were attending and the people you were talking to when youwere designing Java? The people I was talking to were pretty much withinthis group at SUN in 1994. There were 30 in the video-on-demand group. Ofthese about 12 of us worked on the Java that people would currently recognize.Between July and December of 1994 we wrote WebRunner, a browser that ranOak applets. . . . It is true to some degree that we went into a back room anddesigned the language. We had problems to solve that directed our work. Wedidn’t design this by committee or opinion poll. We took unto ourselves as work-ing programmers, to answer the question: What is it that we want? We weredesigning a language for ourselves to use.

[Ed. note: In a later communication, Lindholm acknowledged that “the Oakteam did have a lot of highly experienced language designers and implementorswho were very aware of the computer science literature.”]

4. Were there specific applications that drove your design? Specifi-cally we were targeting applications for the Internet to run on browsers. Butwe were aware that the properties of the language we were designing would bemuch more broadly usable.

5. If you were to design a programming language today, how wouldit differ from current programming languages? I am leery of object-orientation as a kind of religion that drags in complexity in the guise of simplic-ity. It bugs me that sometimes to use an object system requires mind-twistingdiscussions on what things mean. Real programmers don’t have time for reli-gious arguments. Nonetheless I would like to see the world take another run ata Smalltalk-like language, something simpler than current popular languages.Java was striving for elegance and simplicity while retaining familiarity andusability. For example, Gosling went against the grain, and refused to put stuffinto Java, such as operator overloading, which makes the language harderto learn and makes it easier to make mistakes in programming. Now thatthe world is more comfortable with garbage collection, threads, and virtualmachines, it would be desirable to try another programming language (likeSmalltalk) where more cleanliness and elegance are embodied.

Tucker Taft (Ada 95):Tucker Taft was chief language designer of Ada 95.1. What were the problems that you were addressing in your design

for Ada 95? In general, Ada 83 was viewed as a “static” and somewhat “closed”language. Our goal for Ada 95 was to make the language more flexible, more



extensible, and easier to interface with the outside world, be it subsystemswritten in other languages, external hardware devices, or underlying operatingsystems. At the same time, we wanted to preserve Ada 83’s strong focus onsafety, reliability, and readability, and its excellent support for ‘programmingin the large’ thanks to its very strong type checking.

2. What programming practices or software engineering research doyou think influenced your language design, positively or negatively?The big jump for Ada 95 was to incorporate the thinking on inheritance andpolymorphism (i.e., object-oriented programming). One of our challenges was toprovide the dynamic extensibility of inheritance and polymorphism, without thenegatives of strong coupling that inheritance can create between a base type anda derived type. . . . The point is that we were very concerned with the softwareengineering aspects of our design choices. Whether we could point to specific“research” that was critical to our work, that would be harder. But generallythe principles that were developed in the software engineering community werevery important.

3. Can you recollect any of the papers you were reading, the con-ferences you were attending and the people you were talking to whenyou were designing Ada 95? At a high level, I would say that the Ada 9X de-sign team was unusually aware of the computer science literature, and formalverification literature, as well as software engineering principles. I would notsay we were avid readers of software engineering research. In fact, I would saywe more often bemoaned the lack of real research into the software engineeringadvantages or disadvantages of particular language design choices. We had torely on our own experience and gedanken experiments more than we wouldhave liked.

I attended OOPSLA a few times. I also read a number of papers relating tomodular thread synchronization mechanisms. Some of this was pretty old stuff,such as Concurrent Pascal. Other articles were more recent, such as work on alanguage called Orca. All of these had various twists on the notion of a monitor.We ultimately ended up with something called “Protected Types” which combinethe guards of Ada 83’s rendezvous (which were in turn inspired by CSP), withthe passivity of monitors. From a software engineering point of view, I (humbly)think protected types were a great synthesis of old and new ideas.

4. Were there specific applications that drove your design? Very largeapplications; real-time applications; embedded applications. But in addition,Ada 83 had emerged as one of the most widely used languages for teachingprogramming in college. Because of that, there was a desire to lower the entrybarrier to the first time user. So there was also a desire to make it easier towrite short programs in Ada 95 that did something useful in a typical desktopenvironment, so we added more features for dealing with things like commandline arguments (not usually relevant in embedded or real-time applications),simplified I/O, etc.

5. If you were to design a programming language today, how wouldit differ from current programming languages? I still feel there is a lot ofresearch worth doing on the relative productivity and error rates for languageswith different features or philosophies. But I realize this is difficult research to



do. I think most people agree about the fundamental goodness of abstraction,modularity, information hiding, and encapsulation. But we certainly don’t allseem to agree about how that should translate into particular language fea-tures. I also think there is an important aspect of language design that has notbeen talked about much, and that is the “human engineering” of languages. . . .By human engineering I mean whether the language is error prone in variousways.

[Ed. note: Taft continued with a critique of several design decisions in twocurrent languages, C# and Java.]

I was pretty disappointed in Java. It has been a roaring commercial success,but from a language design point of view, it took a lot of steps backward. Theydropped enumeration types, which makes absolutely no sense to me from asoftware engineering point of view. People of course reinvent them, but theyare back to the bad old days of defining named constants, with no compilersupport, and no type checking. . . . The other big step backward for Java waseliminating the separation of specification from implementation.

The language C# actually seems better than Java in some of theserespects. . . . I think C# took a step back relative to Java (and a big step back rela-tive to Ada) in relegating thread synchronization support to a class, rather thanbuilding the concurrency primitives into the language. Java at least has auto-matic locking/unlocking as part of making a synchronized method call. Relyingon the programmer to balance their lock/unlock calls is very error prone. Adagoes further and provides significant task safety and coordination guaranteesthrough the use of guards in protected types. This sort of thing is very difficultto accomplish using a thread class with concurrency primitives available as aset of methods like lock, unlock, and wait.

6. SUMMARY

Programming language features such as exceptions, procedural and data ab-straction, and types present evidence of the strong ties between software engi-neering and programming language research (and practice). Individuals whohave worked in both areas tie them together as well as the attention paid by bothcommunities to relevant research in the other community, attested to by theirreferences to this work in their own papers and presentations at each others’conferences. Cotemporality of developments likewise attests to the influencesof these fields on one another.

It is perhaps unsurprising that this symbiosis exists between programminglanguages and software engineering, with regard to software reliability re-search and exceptions, whose purpose is to provide programmer direction forunusual (but anticipatable) circumstances. Similarly, software engineering re-search in modularity and reuse dovetails nicely with programming languagedesign emphasis on control and data abstraction, which evolved into inheri-tance with visibility controls. Likewise, strong typing can be seen as a responseto the emphasis on software reliability; somewhat later, user-defined typesand generics, are mechanisms to provide for software reuse. In addition, soft-ware engineering research on visual programming influenced modern end-user



programming languages, which use visual expressions to allow nonexperts tocreate programs in specific domains. Finally, the oral histories demonstrate thespecific influences of software engineering research (i.e., goals and techniquesdeveloped) as well as previous programming languages, on modern program-ming language design.

ACKNOWLEDGMENTS

We are most grateful to Carlo Ghezzi for reading several drafts of thismanuscript which led to an improved article. We also appreciate the contribu-tions of Daniel Berry, Richard P. Gabriel, Bill Harrison, Andy Koenig, BarbaraLiskov, Mike Mahoney, Mary Shaw, and Charles Weisert, their suggestions andcomments. We also wish to thank the other members of the IMPACT Projectteam for their support of our research. Finally, we thank the anonymous re-viewers for their helpful comments.

REFERENCES

ACMCS. 1989. ACM Comput. Surv., volume 21, issue 3.AMBLER, A. L. AND BURNETT, M. M. 1989. Influence of visual technology on the evolution of lan-

guage environments. Computer 22, 10 (Oct.), 9–22.ARNSON, R., ROSEN, D., WAITE, M., AND ZUCK, J. 1992. The Visual Basic How-To. The Waite Group

Press.BAROTH, E. AND HARTSOUGH, C. 1995. Visual programming in the real world. In Visual Object-

Oriented Programming: Concepts and Environments, M. Burnett, A. Goldberg, and T. Lewis,Eds. Prentice Hall, Manning Publications, and IEEE.

BASILI, V. R., SELBY, R. W., AND HUTCHENS, D. H. 1986. Experimentation in software engineering.IEEE Transactions Softw. Eng. 12, 7 (July), 733–743.

BERGIN, JR., T. AND GIBSON, JR., R. G., EDS. 1996. History of Programming Languages II. ACMPress and Addison-Wesley Company.

BIRTWISTLE, G. 1973. SIMULA BEGIN. Studentlitterature and Auerback Publishing, Inc., Lund,Sweden and Philadelphia, PA.

BOEHM, B. W. 1976. Software enginering. IEEE Trans. Comput. C-25, 12 (Dec.), 1226–1241.BORNING, A. 1981. The programming language aspects of thinglab, a constraint–oriented simu-

lation laboratory. ACM Trans. Prog. Lang. Syst. 3, 4 (Oct.), 353–387.BOTTONI, P., COSTABILE, M. F., LEVIALDI, S., AND MUSSIO, P. 1997. From visual language specification

to legal visual interaction. In 1997 IEEE Symposium on Visual Languages. 234–241.BRON, C., FOKKINGA, M., AND HAAS, A. 1975. A proposal for dealing with abnormal termination of

programs. Tech. Rep. Mem 150, Twente University of Technology. November.BURNETT, M., BAKER, M., BOHUS, C., CARLSON, P., YANG, S., AND VAN ZEE, P. 1995. Scaling up visual

programming languages. Computer 28, 3 (Mar.), 45–54.BURNETT, M. AND MCINTYRE, D. 1995. Visual programming. Computer 28, 3 (March), 14–16.BURNETT, M., PENDSE, C. C. O., ROTHERMEL, G., SUMMET, J., AND WALLACE, C. 2003. End–user soft-

ware engineering with assertions in the spreadsheet paradigm. In International Conference onSoftware Engineering. 93–103.

CARDELLI, L. AND WEGNER, P. 1985. On understanding types, data abstraction and polymorphism.ACM Comput. Surv. 17, 4 (Dec.), 471–522.

CARGILL, T. A. 1993. The case against multiple inheritance in C++. 101–109.CHANG, S.-K., TAUBER, M. J., YU, B., AND YU, J.-S. 1989. A visual language compiler. IEEE Trans.

Softw. Eng. 15, 5 (May), 506–525.COLLINS, A. M. AND QUILLIAN, M. 1969. Retrieval time for semantic memory. J. Verb. Learn. Verb.

Behav. 8, 240–247.COOPER, A. 1996. Why I am called ‘the father of Visual Basic’. http://www.cooper.com. Accessed

December 26, 2002.



COURTOIS, P. J., HEYMANS, F., AND PARNAS, D. L. 1971. Concurrent control with rreaderss andrwriterss. Comm. ACM 14, 10, 667–668.

COX, P. T., GILES, F. R., AND PIETRZYKOWSKI, T. 1989. Prograph: A step towards liberating program-ming from textual conditioning. In 1989 IEEE Workshop on Visual Languages. 150–156.

CRIMI, C., GUERCIO, A., PACINI, G., TORTORA, G., AND TUCCI, M. 1990. Automating visual languagegeneration. IEEE Trans. Softw. Eng. 16, 10 (Oct.), 1122–1135.

DAHL, O. AND NYGAARD, K. 1967. SIMULA 67 common base definition. Tech. rep., NorwegianComputing Center.

DAHL, O.-J., DIJKSTRA, E. W., AND HOARE, C. 1972. Structured Programming. Academic Press.DIJKSTRA, E. 1969. Structured programming. In Software Engineering Techniques: Report on a

Conference sponsored by the NATO Science Committees, J. Buxton and B. Randell, Eds. Rome,Italy, 84–88.

DIJKSTRA, E. W. 1965. Solution of a problem in concurrent programming control. Comm. ACM 8, 9(Sept.), 569.

DIJKSTRA, E. W. 1968a. Cooperating sequential processes. In Programming Languages,F. Genuys, Ed. Academic Press, 43–112.

DIJKSTRA, E. W. 1968b. Go to statement considered harmful. Comm. ACM 11, 3, 147–148.DOD, U. 1980. Reference manual for the Ada programming language. In DOD. New York.ELLIS, M. A. AND STROUSTRUP, B. 1990. The Annotated C++ Reference Manual. Addison-Wesley

Publishing.FRANKEL, M. 1993. Enabling reuse with Ada generics. In Proceedings of the Tenth Annual

Washington Ada Symposium on Ada’s Role in Software Enginering, McClean, VA, 17–30.GANNON, J. 1977. An experimental evaluation of data type conventions. Comm. ACM 20, 8, 584–

595.GANNON, J. AND HORNING, J. 1975. Language design for programming reliability. IEEE Trans.

Softw. Eng. SE-1, 2 (June), 179–191.GHEZZI, C. AND JAZAYERI, M. 1998. Programming Language Concepts. John Wiley & Sons.GLINERT, E. P. AND TANIMOTO, S. L. 1984. Pict: An interactive graphical programming environment.

Computer 17, 11 (Nov.), 7–25.GOLDBERG, A. 1984. Smalltalk–80: The Interactive Programming Environment. Addison-Wesley.GOLDBERG, A. AND ROBINSON, D. 1983. Smalltalk-80: the Language and Implementation. Addison-

Wesley, Reading, MA.GOODENOUGH, J. B. 1975a. Exception handling: Issues and a proposed notation. Comm.

ACM 18, 12 (Dec.), 683–696.GOODENOUGH, J. B. 1975b. Structured exception handling. In Conference Record of the Second

Annual ACM SIGACT/SIGPLAN Symposium on Principles of Programming Languages. 204–224.

GOSLING, J., JOY, B., AND STEELE, JR., G. L. 1996. The Java Language Specification. Addison-Wesley,Reading, MA.

GRAVER, J. O. AND JOHNSON, R. E. 1990. A type system for Smalltalk. In Conference Record of the17th Annual ACM SIGACT/SIGPLAN Symposium on Principles of Programming Languages.136–150.

GREEN, T. AND PETRE, M. 1996. Usability analysis of visual programming environments: A ‘cog-nitive dimensions’ framework. J. Vis. Lang. Comput. 7, 2 (June), 131–174.

GUTTAG, J. V., HORNING, J. J., AND WING, J. M. 1985. The Larch family of specification languages.IEEE Softw. 2, 5 (Sept.), 24–36.

HABERMANN, A. AND NOTKIN, D. 1986. Gandalf software development environment. IEEE Trans.Softw. Eng. SE-12, 12 (Dec.), 1117–1127.

HABERMANN, A. N. 1973. Critical comments on the programming language Pascal. Acta Informat-ica 3, 47–57.

HANSEN, P. B. 1972. Structured multiprogramming. Comm. ACM 15, 7 (July), 574–578.HANSEN, P. B. 1975. The programming language concurrent Pascal. IEEE Trans. Softw. Eng. 1, 2,

199–207.HANSEN, P. B. 1996. Monitors and concurrent Pascal: A personal history. In History of Program-

ming Languages-II, T. Bergin and R. Gibson, Eds. Addison-Wesley, 121–172.HARBISON, S. P. 1992. Modula-3. Prentice Hall.



HELM, R., MARRIOTT, K., AND ODERSKY, M. 1991. Building visual language parsers. In ACM Con-ference on Human Factors in Computing Systems. 105–112.

HIRAKAWA, M., TANAKA, M., AND ICHIKAWA, T. 1990. An iconic programming system, hi-visual. IEEETrans. Softw. Eng. 16, 10 (Oct.), 1178–1184.

HOARE, C. 1969. An axiomatic approach to computer programming. Comm. ACM 12, 10 (Oct.),576–580, 583.

HOARE, C. 1974a. Hints on programming language design. In State of the Art Report 20: Com-puter Systems Reliabilty, C. Bunyan, Ed. Pergamon/Infotech. This paper originated in a keynoteaddress at the ACM SIGPLAN POPL conference in Boston in October 1973 and although it wasnot in the proceedings, it was distributed at the conference. A 1989 collection of Dr. Hoare’s essaysentitled Essays in Computing Science published by Prentice Hall, also contains a reprint of thispaper.

HOARE, C. 1974b. Monitors: An operating systems structuring concept. Comm. ACM 17, 10(Oct.), 549–557.

HOARE, C. 1978. Communicating sequential processes. Comm. ACM 21, 8 (Aug.), 666–677.HOPKINS, M. E. 1972. A case for the goto. In Proceedings of the 25th National ACM Conference.

787–790.HORNING, J. J. 1979. Programming languages. In Computing Systems Reliability, T. Anderson

and B. Randell, Eds. Cambridge University Press, 109–152.HOROWITZ, E. AND MUNSON, J. G. 1984. An expansive view of reusable software. Trans. Softw.

Eng. SE-10, 5 (Sept.), 477–487.ICHBIAH, J., HELIARD, J., ROUBINE, O., BARNES, J., KREIG-BRUECKNER, B., AND WICHMANN, B. A. 1979.

Rationale for the design of the ADA programming language. ACM SIGPLAN Notices 14, 6 (June),1–261.

IEEESW 1989. IEEE Software, issue on parallel programming.IFIP 2004. http://www.mlaa.com.au/IFIPWG2.4/index.htm.INGALLS, D. 1978. The Smalltalk-76 programming system: Design and implementation. In Con-

ference Record of the Fifth Annual ACM Symposium on Principles of Programming Languages.9–16.

KEFFER, T. 1995. Programming with the standard template library, sage advice for coping withthe stl. Dr. Dobb’s Journal 1995, SI3.

KICZALES, G., LAMPING, J., MENDHEKAR, A., MAEDA, C., LOPES, C. V., LOINGTIER, J.-M., AND IRWIN, J.1997. Aspect-oriented programming. In Proceedings of the European Conference on Object-oriented Programming (ECOOP). Springer-Verlag LNCS 1241.

KOENIG, A. AND STROUSTRUP, B. 1993. Exception handling for C++. In The Evolution of C++:Language Design in the Marketplace of Ideas, J. Waldo, Ed. MIT Press. a USENIX Associationbook.

LIBRARY, I. S. R. 1970. IBM System/360 Operating System PL/I (F) Language Reference Manual.4th edition.

LIPPERT, M. AND LOPES, C. V. 2000. A study on exception detection and handling using aspect-oriented programming. In Proceedings of the 22nd International Conference on Software Engi-neering. 418–427.

LISKOV, B. 1993. A history of CLU. In Proceedings of History of Programming Languages Confer-ence (ACM SIGPLAN Notices, vol. 28, no. 3). 133–147.

LISKOV, B. AND GUTTAG, J. 1986. Abstraction and Specification in Program Development. MIT Pressand McGraw-Hill Book Company.

LISKOV, B. AND SNYDER, A. 1979. Exception handling in CLU. IEEE Trans. Softw. Eng. SE-5, 6(Nov.), 546–558.

LISKOV, B., SNYDER, A., ATKINSON, R., AND SCHAFFERT, J. 1977. Abstraction mechanisms in CLU.Comm. ACM 20, 8, (Aug.), 564–576.

LISKOV, B. AND ZILLES, S. 1974. Programming with abstract data types. In ACM SIGPLAN Con-ference on Very High Level Languages. 50–59.

LISKOV, B. AND ZILLES, S. 1975. Specification techniques for data abstractions. IEEE Trans. Softw.Eng. SE-1, 7–19.

LISKOV, B. H. 1972. A design methodology for reliable software systems. In Proceedings of theFall Joint Computer Conference. 191–198.



LITKE, J. 1990. A systematic approach for implementing fault tolerant software designs in Ada.In Proceedings of the Conference on TRI-Ada’90. 403–408.

LUCKHAM, D. C. AND POLAK, W. 1980. Ada exception handling: An axiomatic approach. ACM Trans.Prog. Lang. Syst. 2, 2 (April), 225—233.

MACLAREN, M. D. 1977. Exception handling in PL/I. In Proceedings of the ACM Conference onLanguage Design for Reliable Software. 101–104.

MADSEN, O. L., MAGNUSSON, B., AND MOLLER-PEDERSEN, B. 1990. Strong typing of object-orientedlanguages revisited. In Proceedings of the European Conference on Object-oriented Programming(ECOOP). 140–151.

MCCARTHY, J., ABRAMS, P. W., EDWARDS, D. J., HART, T. P., AND LEVIN, M. 1965. LISP 1.5 Programmer’sManual. MIT Press.

MCILROY, D. 1976. Mass-produced software components. In Software Engineering Concepts andTechniques, 1968 NATO Conference on Software Engineering, J. Buxton, P. Naur, and B. Randell,Eds. 88–98.

MILLER, R. AND MYERS, B. 2001. Outlier finding: focusing user attention on possible errors. InACM User Interface Software and Technology. 81–90.

MURRAY, R. 1988. Building well-behaved type relationships in C++. In Proceedings of USENIX.19–30.

MYERS, B. A. 1990. Creating user interfaces using programming by example, visual program-ming, and constraints. ACM Trans. Prog. Lang. Syst. 12, 2 (April), 143–177.

NYGAARD, K. AND DAHL, O.-J. 1978. The development of the SIMULA languages. In Proceedingsof the History of Programming Languages Conference, ACM SIGPLAN Notices, vol. 13, no. 8.245–276.

PANE, J., MYERS, B., AND MILLER, L. 2002. Using hci techniques to design a more usable program-ming system. In IEEE Human–Centric Computing Languages and Environments. 198–206.

PARNAS, D. 1971. On the criteria to be used in decomposing systems into modules. Tech. Rep.Department of Computer Science, Carnegie-Mellon University.

PARNAS, D. 1972. On the criteria to be used in decomposing systems into modules. Comm.ACM 15, 2, 1053–1058.

PERRY, D. E. 1989. The inscape environment. In Proceedings of the 11th International Conferenceon Software Engineering. 2–12. Selected as best paper from 10 years ago ICSE.

PLAUGER, P. L. 1995. Standard C/C++ the standard template library. C/C++ Users Jour-nal 13, 12, 10–20.

POPEK, G., HORNING, J., LAMPSON, B., MITCHELL, J., AND LONDON, R. 1977. Notes on the design ofeuclid. ACM Sigplan Notices 12, 3, 11–18.

PRIETO-DIAZ, R. 1993. Status report: Software reusability. IEEE Softw. 10, 3 (May), 61–66.RADIN, G. 1981. The early history and characteristics of PL/I. In History of Programming Lan-

guages, R. L. Wexelblat, Ed. Academic Press, 551–600.RANDELL, B. 1975. System structure for software fault tolerance. In Proceedings of the Interna-

tional Conference on Reliable Software. 437–439.RAZ, O., KOOPMAN, P., AND SHAW, M. 2002. Semantic anomaly detection in online data sources. In

International Conference on Software Engineering. 302–312.REDWINE, S. T. AND RIDDLE, W. E. 1985. Software technology maturation. In Proceedings of the 8th

International Conference on Software Engineering. 189–200.REISS, S. 1984. Graphical program development with pecan program development systems. In

ACM SIGSOFT/SIGPLAN Symposium on Practical Software Development Environments.ROBILLARD, M. P. AND MURPHY, G. C. 2000. Designing robust Java programs with exceptions. In

Proceedings of the 8th ACM SIGSOFT Symposium on Foundations of Software Engineering.2–10.

ROSCHELLE, J., KOUTLIS, M., REPENNING, A., JACKIW, N., AND SUTHERS, D. 1999. Developing educa-tional software components. Computer 32, 9 (Sept.), 50–58.

ROTHERMEL, G., LI, L., DUPUIS, C., AND BURNETT, M. 1998. What you see is what you test: A method-ology for testing form-based visual programs. In International Conference on Software Engineer-ing. 198–207.

ROWE, L. A. 1980. Data abstraction from a programming language viewpoint. In ACM Workshopon Data Abstraction, Databases, and Conceptual Modeling.



ROWE, L. A., DEUTSCH, L. P., SHAW, M., THATCHER, J. W., MAYR, H. C., ZILLES, S. N., AND HAYES, P. J.1980. Types (discussion). SIGMOD Record 11, 2, 43–52.

RUBIN, F. 1987. ’goto considered harmful considered harmful. Comm. ACM 30, 3, 195–196.RUBIN, R. V., GOLIN, E. J., AND REISS, S. P. 1985. Thinkpad: A graphical system for programming

by demonstration. IEEE Softw. 2, 2 (Mar.), 73–79.SCOTT, M. L. 2000. Programming Language Pragmatics. Morgan Kaufmann Publishers, San

Francisco, Ca.SHAW, M. 1981. ALPHARD: Form and Content. Springer-Verlag, New York.SHAW, M. 1984. Abstraction techniques in modern programming languages. IEEE Softw. 1, 4,

10–26.SHAW, M. 2001. The coming-of-age of software architecture research. In Proceedings of the 23rd

International Conference on Software Engineering. 657–664.SHAW, M., ALMES, G. T., NEWCOMER, J., REID, B., AND WULF, W. 1978. Comparison of programming

languages for software engineering. Tech. rep., Department of Computer Science, CMU.SHAW, M., WULF, W. A., AND LONDON, R. L. 1977. Abstraction and verificiation is alphard: Defining

and specifying iteration and generators. Comm. ACM 20, 3, 553–564.SMITH, D. C. 1977. Pygmalion: A Computer Program to Model and Stimulate Creative Thought.

Birkhauser.STROUSTRUP, B. 1987. Possible directions for C++. In Proceedings of USENIX C++ Workshop.STROUSTRUP, B. 1993. A history of C++: 1979–1991. In Proceedings of the History of Programming

Languages Conference (ACM SIGPLAN Notices, vol. 28, no. 3). 699–755.SUTHERLAND, I. E. 1963. Sketchpad: A man–machine graphical communication system. In AFIPS

Spring Joint Computer Conference.SUTHERLAND, W. 1966. On-line graphical specification of computer procedures. Tech. rep., MIT.

MIT Ph.D. Thesis.TANENBAUM, A. S. 1976. A tutorial on Algol68. ACM Comput. Surv. 8, 2 (June), 155–190.TEITELBAUM, T. AND REPS, T. 1981. The Cornell Program Synthesizer: A syntax-directed program-

ming environment. Comm. ACM 24, 9 (Sept.), 563–573.TEITELMAN, W. 1984. A tour through cedar. In ICSE ’84: Proceedings of the 7th International

Conference on Software Engineering. IEEE Press, Piscataway, NJ, USA, 181–195.TGS SYSTEMS. 1990. Prograph Tutorial Manual. The Gunakara Sun Systems, Ltd. 2nd Printing,

July.TICHY, W. F. 1998. Should computer scientists experiment more? 16 reasons to avoid experimen-

tation. IEEE Comput. 31, 5 (May), 32–40.VAN WIJNGAARDEN, A., MAILLOUX, B., PECK, J., KOSTER, C., SINTZOFF, M., LINDSEY, C., MEERTENS, L.,

AND FISKER, R. G. E. 1968. Revised Report on the Algorithmic Langauge ALGOL68. Also ap-peared in ACM SIGPLAN Notices, Volume 12, Number 5, 1–70, May 1977; available online athttp://members.dokom.net/2.kloke/RR/rrTOC.html.

WALDO, J. 1991. The case for multiple inheritance in C++. Comput. Syst. 4, 1, 111–120.WEGNER, P. 1984. Capital-intensive software technology. IEEE Softw. 1, 3 (July), 43–97.WIRTH, N. 1971a. Program development by stepwise refinement. Comm. ACM 14, 2, 221–227.WIRTH, N. 1971b. The programming language Pascal. Acta Informatica 1, 35–63.WIRTH, N. 1977. Modula: A language for modular multiprogramming. Software Practice and

Experience 7, 3–35.WULF, W., LONDON, R., AND SHAW, M. 1976. An introduction to the construction and verification of

alphard programs. IEEE Trans. Softw. Eng. SE-2, 4, 390.WULF, W. AND SHAW, M. 1973. Global variable considered harmful. SIGPLAN Notices 8, 28–34.WULF, W. A., RUSSELL, D. B., AND HABERMANN, A. N. 1971. Bliss: A language for systems program-

ming. Comm. ACM 14, 12, 780–790.

Received September 2004; revised June and August 2005; accepted September 2005


The Impact of Software Engineering Research on Modern Progamming

Documents

Transcript of The Impact of Software Engineering Research on Modern Progamming