Material from HOPL-III Conference Organization

Brief Histories of HOPL-III Paradigms

Fri, 22 Feb 2008 14:29:21 -0500

The HOPL III programming languages can be broadly categorized into five classes (or paradigms): Object-Oriented (Modula-2, Oberon, C++, Self, Emerald, and BETA), Functional (Haskell), Scripting (AppleScript, Lua), Reactive (Erlang, StateCharts), and Parallel (ZPL, High Performance Fortran). Each HOPL III paper describes the perspective of the creators of the language. Hence it is important to understand the context of each programming paradigm during the same period.

These summaries were created in a community wiki, starting a few months before the HOPL-III conference and ending on February 22, 2008.

Brief History of Object-Oriented Programming Languages: 1983-1996

HOPL I and HOPL II described, in detail, the histories of the early object-oriented (OO) languages: SIMULA, Smalltalk, C++, and (to some extent) Ada 83 and Fortran 90. As one can easily see from the first OOPSLA conference in 1986, the OO field was exploding with new concepts and experimental languages. Different mechanisms for sharing (inheriting code, data, and interfaces) included flavors, types, classes/subclasses, delegation/prototypes/exemplars, virtual copies, encapsulators, and genericity. Exploratory languages at OOPSLA 86 included Trellis/Owl, CommonLoops, Oaklisp, Emerald, SOAR, Quicktalk, Impulse-86, Orient84/K, ABCL/1, Concurrent Smalltalk, and Pi. Some of these were toy languages, some continued to exist for a few years, but none achieved the commercial success of their predecessors.

Also presented at the first OOPSLA, through a paper focused not on the language but on the novel combination of generics (as in Ada) and inheritance (as in Simula and other OO languages)[1], the Eiffel
programming language was developed commercially by Bertrand Meyer beginning in 1985. The language developed hand-in-hand with the concept of design by contract. Unlike C++, Eiffel was designed as a
full-fledged OO language rather than a hybrid with an existing language such as C.

The 1995 revision of Ada introduced a complete object-oriented system, which was built on a very different foundation from Simula or C++. Niklaus Wirth had designed Modula as a successor to Pascal in the late 1970s. Though not strictly an OO language, Modula supported strong encapsulation via modules. In 1978, Wirth designed Modula-2 for the Lilith computer. Oberon followed in 1986. The strong modular encapsulation principles of Modula-2 were imitated in Ada 83 and Fortran 90.

For many of the years of this period, C++ and Eiffel were the main commercial successes among OO languages. In the early 1990s, however, Sun Microsystems introduced Java. Java was started as a project called "Oak" by James Gosling in June of 1991. The project underwent a number of changes of direction and focus, but eventually became the language of choice for server-side computing. The first public implementation was Java 1.0 in 1995. Eventually, Java became popular in a variety of domains, with platform support for several application families, including J2EE for enterprise applications and J2ME for mobile applications.

Brief History of Functional Programming Languages: 1983-1996

Functional programming, as a distinct topic in programming languages, arose very early in theory and fairly late in practice. The theoretical foundations date back to 1932, in Alonzo Church's Lambda calculus. The purity and power of the lambda calculus inspired theoreticians for some time to come, as in Peter J. Landin's influential but never-implemented language ISWIM and John Backus's FP programming language presented at his 1977 Turing Award lecture Can Programming Be Liberated From the von Neumann Style? A Functional Style and its Algebra of Programs (http://www.stanford.edu/class/cs242/readings/backus.pdf) .

Functional programming was possible, although not generally singled out as a programming style, from quite early in the history of computing. John McCarthy's LISP programming language was inspired in part by the first chapter of Church's book on lambda calculus. (McCarthy claims to have avoided the rest of the theoretical material because he didn't understand it, though it is possible that he actually understood it and avoided it for sound technical reasons instead.) Lisp allows (and in many cases introduces (albeit in a highly-parenthesized notation rather than the more finely-tuned notations of later languages)) the core mechanisms of successful functional programming languages: it allows the manipulation of functions as data; it is expression-based; it has rich underlying data structures; it is garbage-collected; it allows recursion. While it includes non-functional features, it is possible and even natural to write a great deal of code in the functional subset of the language. Arguably, the first serious functional programs were in Lisp, although Lisp is not actually a functional programming language.

The first truly functional languages that were actually implemented and used for more than minimal examples seem to be the ML programming language of Robin Milner, and the language Miranda of David
Turner, both from the 1970's. Most modern functional programming languages continue in the style of ML and Miranda. Strictly, ML isn't purely functional; it allows side effects. However, ML's side effects are
confined to a small set of types, and much more programming is possible without using them. ML is notable for first class functions, automatic memory management through garbage collection, parametric
polymorphism, static typing, type inference, algebraic data types and pattern matching adopted from the Hope programming language and exception handling.

Dataflow programming languages for describing computer architecture arose in the 1970's. These can broadly be considered functional, or at least declarative, languages. They generally do not have first-class
functions, however. Dataflow programs describe computer architectures in functional terms.

A wide range of functional programming languages arose in the late 1970s and 1980s. Perhaps the most important was the Hope programming language, whose concrete data types and pattern matching were included in ML and have become more or less standard in mainstream functional programming languages.

In 1987, the functional programming community gathered to design a unified functional programming language: Haskell. Characteristic features of Haskell include lazy evaluation, pattern matching, currying,
list comprehensions, guards, definable operators, and single assignment. Haskell has been dominant among purely functional languages since then.

Quasi-functional languages are probably more heavily used than strictly functional ones. Lisp in its incarnations as Common Lisp and Scheme, and ML in its incarnations as Standard ML and dominant in this category, used for academic research and assorted commercial applications.

Brief History of Reactive Languages: 1983-1996

“Reactive Systems” were first defined in a 1985 paper by David Harel and Amir Pnueli. The term refers to not-necessarily-terminating systems whose behavior is characterized mainly by the way they react with their environments, to distinguish from Transformational, or Computational Systems, whose behavior is characterized by transformations, or computation. The essence of the distinction was that computational systems can be specified by input-output relations (as with pre and post conditions in Floyd-Hoare tradition), while reactive systems must be specified and verified in terms of their ongoing behavior.

In the late 1980s, the application areas of reactive system design were in real-time control systems, communication protocol design, and event-driven user interfaces. From a language design perspective, reaction to events (a.k.a event-condition-action) as a basic construct, compositional semantics (full abstraction and bi-simulation) of reactive components, asynchronous and synchronous behavior were fundamental considerations. Development of the field proceeded simultaneously in devising semantic foundations with temporal logic and synchronization primitives for communicating processes as well as visual design notations such as communicating Finite State Machines, Statecharts and Message Sequence Charts.

Languages like Esterel, Lustre and LOTOS appeared for specifying communication protocols. Central to these languages is the synchrony hypothesis, due to Gerard Berry, which prescribes an abstraction whereby steps take zero time. On the visual design notations front, Statecharts [Harel] used AND/OR compositions of state machines to describe reactive systems. Statecharts were put in a more general context in the mid-1980s, where the language was combined with a functional decomposition, so that a statechart could be used to specify the behavior of a function [Harel et al]. Similar combinations were carried out independently, using finite state machines [Ward/Mellor, Hatley/Pirbhai]. ObjChart[Gangopadhyay] and ROOM [Selic] were two early visual notations that adopted the Statechart formalism, but emphasized networks of autonomous objects to define structure and composition of the system under design, where behavior of individual objects was specified by finite state machines. This gave rise to an object-oriented version of the statecharts language, a variant of which serves as the main behavioral medium in the UML.

Since then, languages were commercially applied to various applications areas (Avionics, Embedded Systems, Communication, automotive systems and hardware design). Hand-in-hand verification technologies based on real life success...

Brief History of Parallel Programming Languages: 1983-1996

In the world of parallelism, it is customary to distinguish between two kinds of languages. Parallel programming is traditionally concerned with making transformational programs go faster by exploiting parallel hardware. Thus parallelism is needed for performance, not expressiveness. Parallel programming languages may support parallelism explicitly (the language has explicit concurrent control constructs) or implicitly (there are no such constructs). High performance computing typically falls in this category.

In contrast, concurrent programming is traditionally concerned with expressing reactive computations -- those that maintain an ongoing interaction with their environment. Hence concurrent control constructs are necessary in order to express the underlying programming problem. Operating systems, real-time control software, client/server applications, web services typically fall in this category.

Implicitly parallel languages

A central focus of implicitly parallel languages has been data-parallelism. No explicit control constructs are provided to spawn tasks or threads or enable them to synchronize. Instead operations may be performed on aggregate data-structures (such as arrays, or array sections) in parallel.

Fortran extensions

Fortran 90 introduced the notion of aggregate operations on entire arrays, or sections of arrays. For example, if A, B, C are conformant, the programmer may write A = B + C to indicate that corresponding
elements of B and C should be added and stored in A. Such aggregate operations are made easier to use by introducing "implicit right-hand-side buffer semantics:" the entire right hand side is evaluated and buffered before being assigned to the left hand side (the optimizer can decide to use A for the buffer if this would not change the semantics). The "triple notation" l:u:s is used to specify sets of indices (all the indices between l and u with stride s); an array subscripted with a triple in one or more dimensions specifies an "array section" (a portion of an array). Nonstandard control constructs such as FORALL (standardized in 1995) and DO INDEPENDENT (to be standardized in 2008 as DO CONCURRENT) specify operations that can be performed in parallel on aggregates. This parallelism can be exploited by SPMD architectures. In the early 90s it became feasible to run a single computation on a collection of computers, a process per computer. The computation could work on an array larger than the amount of memory available on a single processor.

A series of languages, Vienna Fortran 90, Kali, Blaze led to the development of HPF. Version 1 was published in 1993 and version 2 in 1997. These languages explored the idea that the programmer would supply a high level directive controlling the distribution of the array (e.g. block distribution, block-cyclic distribution), and continue to write code with a single program counter. The compiler would then generate the necessary message passing and synchronization code to implement these operations. Compared with using MPI directly for message passing, this approach has the advantage of offering a much higher level of abstraction to the programmer. However, it suffered from the lack of flexibility (users wanted to be able to specify more complex distributions than the ones supported in the language) and efficiency (the task of automatically generating efficient code for this language is much harder than originally believed). Research on HPF continues today, attempting to address these limitations.

In 1997, Numrich et al. described F--, which has become Co-Array Fortran. It has been implemented by Cray and others, and will be part of the 2008 standard. Co-Array Fortran attacks the same problems as HPF, but apparently with more success.

Array languages

NESL develops the idea of nested aggregates: aggregates may themselves contain aggregates as elements and, further, may be operated on by parallel functions. NESL runs on Unix workstations, and various parallel machines.

Dependency-based Languages

JADE is an implicitly parallel language for coarse-grained computing developed by Martin Rinard for his PhD. Programs are written in a standard sequential imperative language, augmented with Jade constructs to specify dependencies between data accesses. The compiler extracts a task-dependence graph and maps this graph to the machines at hand. Execution of a Jade program preserves the sequential semantics of the original program. The system was first released in 1994 for shared memory multiprocessors and networks of computers.

SIMD Languages

SIMD languages include C* (an extended C for data parallel programming), and various languages developed for the Connection Machine, including *Lisp and CM Fortran.

Explicitly parallel languages

Languages based on CCS and CSP

Occam was announced in 1983 by INMOS and implemented on INMOS transputers, based on CSP. Its core communication construct is a hand-shake between a process offering a value and a process offering a variable in which to store the value. A process may offer several of these actions simultaneously (through a choice operation),

The Pi-calculus was developed by Robin Milner, Joachim Parrow and David Walker in 1982 as a simple calculus for concurrent systems with dynamically changing connectivity. Active development of the Pi-calculus continues today. Languages based on the Pi-calculus include Occam-pi and Pict.

Data-flow languages

Data-flow languages adopted a different approach to parallelism, based on producer consumer synchronization.

Sisal develops a language for HPC on top of the functional programming Val by adding finite streams and arrays. The output of the compiler is a data-flow program. The first compiler was implemented in 1986. The last version of the Optimizing Sisal Compiler (for Sisal 1.2) was released in 1994.

Id introduced the notion of i-structures as a way of handling fine-grained array update operations in a data-flow context, without losing determinacy. The operational semantics of Id is described as a parallel reduction system on graphs.

Erlang is a general-purpose reactive concurrent language, originally announced in 1987. It extends a sequential single-assignment functional language with concurrency constructs based on Actors. It is fairly unique among concurrent languages in supporting hot swapping. Erlang continues to be in active development. Release 11 was released in May 2006.

Concurrent logic programming languages

Concurrent logic programming languages --- such as Concurrent Prolog, Parlog, GHC and Strand arose from an entirely different tradition (Logic Programming) but may be thought of as more versatile versions of data-flow languages. In these languages computations are represented as dynamically evolving recursive graphs, whose nodes are called processes, and edges are called logical variables. Values are produced for edges through restricted forms of unification. Unification is an elegant operation that permits binding of values to variables as well as destructuring of values into their components. Thus it permits dynamic data-flow -- the direction of flow of data at runtime is not determined statically. Processes may wait for data to arrive on edges before reducing to new graphs, by using one of several clauses.

Of these, Concurrent Prolog was the most general, offering a "read-only" annotation (?) as a way of controlling unification (and hence data-flow) dynamically. The first version of the Logix system, based on FCP was released in 1985. Parlog relied on statically specified "modes" to enforce directionality. It was first released in 1987. GHC used an elegant restriction of unification -- matching -- to specify suspension. GHC was intended to be used as the systems programming language for the Japanese Fifth Generation Systems project pursued at ICOT. It was released in 1990 as the KLIC, a portable implementation of the KL1 system. Strand further restricted unification so that in effect it became an assignment to a single variable at a time. Strand was released commercially by Strand Technologies in 1989.

These languages had an influence on the theoretical development of declarative concurrent programming languages -- e.g. through the development of Concurrent Constraint Programming -- but are not in wide-spread use today.

Languages based on C

Cilk is an extension of C based on the idea of work stealing. It is intended for general-purpose parallel computation, and has primitives for spawning recursive computations. However, all computations spawned within the body of a function must terminate before the function call returns. Cilk has been used for algorithms that can be expressed using dynamic, asynchronous computation.

Split C is an extension of C for distributed memory multiprocessors. It extends C with a partitioned global address space. The address space for the computation is the union of the address space of the participating processes. Pointers may be global or local; global pointers may point into memory allocated in a process other than then process in which the reference lives. Split C follows an SPMD programming model. It was a precursor UPC.

Concert C is an extension of ANSI C for parallel and distributed computing developed at the IBM TJ Watson Research Center. It permits the creation of new processes on the current processor or a remote processor. It permits processes to communicate through one-way, asynchronous queues of messages. Arbitrary C data-structures may be communicated between processes (using marshalling and demarshalling). It transparently integrated remote procedure calls. It was designed to run on a heterogeneous collection of machines and operating systems. The first compiler was released in 1994.

Object-oriented languages

Illinois Concert C++ was developed to permit the expression of irregular and fine-grained concurrency in an extension of C++. Fine-grained concurrency was supported by a "conc" block which permits unrelated statements to be executed in parallel. It introduced the notion of object consistency as a way of building up concurrent data abstractions from modular pieces. It integrated arrays into the object system. The first compiler was released in 1995.

Charm++ is a portable concurrent object-oriented language based on C++. It uses actor-style concurrency for asynchronous messaging between objects, as well certain kinds of shared objects. It provides extensive support for load balancing. It provides a "branched chare" -- a replicated object which has a parallel interface and can be used as the basis for data-parallel algorithms. The system was first released in 1995.

Miscellaneous languages

Linda was developed by David Gelernter and Nicholas Carrero as a simple means of extending sequential programming languages with the notion of a tuplespace. A tuple space is shared by multiple processes and permits the injection of tuples, their (associative) removal, and their destructive update. Linda has been integrated into Prolog, Ruby, C and Java. Linda was first released in 1985.

Brief History of Scripting Languages: 1983-1996

Early scripting languages in Unix included the Bourne shell, Awk and XXX.

REXX (or Rexx) was started by Mike Cowlishaw in 1979, described to the public in 1981 and first shipped as an IBM product in 1982, soon achieving widespread use both for general scripting and as the embedded language of the XEDIT editor. Large applications could be, and were, entirely constructed in it. Its direct influence on other languages is hard to quantify because its core user community was in high-end mainframes rather than computer science, but its design and feature set make it a strong contender for being the first successful 'modern' scripting language. See "The Early History of REXX" by Mike Colishaw in IEEE Annals of the History of Computing, Vol.16, No.4 (Winter 1994). This was a special issue devoted to programming languages and included articles on SIMULA, Data-Flow Languages and the Origins of Computer Programming.

ABC was created by Lambert Meertens and others at CWI in the late '70s and early '80s; its most important influence was to be the main inspiration for Python. ABC was first released to the public around 1985.

Perl was started by Larry Wall in 1987; Perl 1.0 was released the same year.

Tcl was started by John Ousterhout at UCB in 1988; it was first release to the public in 1990.

Python was started by Guido van Rossum at CWI in 1989; it was first released to the public in 1991.

Lua was started by Roberto Ierusalimschy, Luiz Henrique de Figueiredo, and Waldemar Celes at PUC-Rio in 1993; it was first released to the public in 1994.

Ruby was started by Yukihiro "Matz" Matsumoto in 1993; it was first released to the public in 1995.

HOPL-III Submission Calendar

Fri, 5 Jan 2007 12:24:34 -0500

• July 8, 2005: Authors submit 1 page abstract to show intent to submit
• August 15, 2005: Authors submit draft papers to PC
• January 31, 2006: Final deadline for full paper submission
• April 15, 2006: Feedback sent to authors
• September 1, 2006: Final revised versions of papers due
• December 15, 2006: PC Chairs notify authors of acceptance or rejection of final versions
• January 20, 2007: Authors to send in final revised papers
• March 25, 2007: Authors to receive marked up copy from copy editor
• April 15 , 2007: "Camera ready" version of accepted papers due for posting on DL & assembling for electronic proceedings
• June 9-10, 2007: HOPL-III held at FCRC

Content Guidelines for Authors

Thu, 4 Jan 2007 12:38:56 -0500

The criteria for the programming languages considered appropriate for HOPL-III are:

1. The programming language came into existence before 1996, that is, it was designed and described at least 11 years before HOPL-III (2007).
2. The programming language has been widely used since 1998 either (i) commercially or (ii) within a specific domain. In either case, “widely used” implies use beyond its creators.
3. There also are some research languages which had great influence on widely used languages that followed them. As long as the research language was used by more than its own inventors, these will be considered to be appropriate for discussion at HOPL-III.

Please be sure to include within your paper a clear indication of how the subject material satisfies these criteria (i.e., 1&2 or 1&3). This information can certainly be provided indirectly as part of the overall text. (For instance, some of the criteria are dates; it suffices to include the dates as part of the historical narrative.)

The main purpose of these guidelines is to help you develop the appropriate content for your contribution to HOPL-III. The questions herein point to the kind of information that people want to know about the history of programming languages. A set of questions is included for each of the major areas to be covered by HOPL-III:

Early history of a specific language

Later evolution of a specific language (usually a language treated in HOPL-I or in HOPL-II)

The sets of questions overlap to some extent. This guideline includes both sets of questions, in the hope that having the other set available may prove useful to you.

Even within a single set, the same question, or very similar questions, may be asked in different contexts. Please draft your paper in light of these different emphases and contexts.

Your paper should try to answer as many questions as possible in your topic area: it is understood that you might not be able to address every one of them. Because history can unfold in so many different ways, some of the questions may be clearly irrelevant to your particular topic, or your particular point of view. The information requested might no longer be available, but please remember this information is important as well. Several questions are of the form “How did something affect something else?”—it can be important for the historical record to assert that “it didn’t.”

The question set suggests the content, not the form, of your paper. (In particular, your paper should not be in question-answer format.) The questions are organized into topics and subtopics for your convenience during your research; this structure is not meant as an outline for your paper. (Topics, subtopics, and questions are also numbered and lettered for convenience of reference.) Please feel free to use whatever form and style seems most appropriate and comfortable to you.

The Program Committee strongly suggests that you examine at least one paper from each of the proceedings of HOPL-I and HOPL-II to see what earlier contributors did. The references are:

History of Programming Languages,
Edited by, Richard L. Wexelblat,
Academic Press, 1981

History of Programming Languages-II,
Edited by, Thomas J. Bergin, Jr. and Richard G. Gibson, Jr.,
ACM Press/Addison-Wesley Publishing Company, 1996

The first two History of Programming Languages conferences established high technical and editorial standards. We trust that your contribution will help HOPL-III maintain or surpass these standards.

Questions on the Early History of a Language

Wed, 3 Jan 2007 13:15:04 -0500

I. BACKGROUND

1. Basic Facts about Project Organization and People

(a) Under what organizational auspices was the language developed (e.g., name of company, department/division in the company, university?) Be as specific as possible about organizational subunits involved.

(b) Were there problems or conflicts within the organization in getting the project started? If so, please indicate what these were and how they were resolved.

(c) What was the source of funding (e.g., research grant, company R&D, company production units, or a government contract?)

(d) Who were the people on the project and what was their relationship to the author(s) (e.g., team members, subordinates)? To the largest extent possible, name all the people involved, including part-timers, when each person joined the project and what each person worked on. Indicate the technical experience and background of each participant, including formal education.

(e) Was the development done originally as a research project, as a development project, as a committee effort, as an open-source effort, as a one-person effort with some minor assistance, or….?

(f) Was there a defined leader to the group? If so, what was his or her exact position (and title) and how did he or she get to be the leader? (e.g., appointed “from above”, self-starter, volunteer, elected?)

(g) Was there a de facto leader different from the defined leader? If so, who was this leader and what made them the de facto leader, i.e., personality, background, experience, a “higher authority” or something else?

(h) Were there consultants from outside the project who had a formal connection to it? If so, who were they, how and why were they chosen, and how much help were they? Were there also informal consultants? If so, please answer the same questions.

(i) Did the participants of the project view themselves primarily as language designers, as implementers, or as eventual users? If there were some of each working on the project, indicate the split as much as possible. How did this internal view of the people involved affect the initial planning and organization of the project?

(j) Did the language designers know (or believe) that they would also have the responsibility for implementing the first version? Whether the answer is “yes” or “no” and was the technical language design affected by this?

2. Costs and Schedules

(a) Was there a budget? Did the budget provide a fixed upper limit on the costs? If so, how much money was to be allocated and in what ways? What external or internal factors led to the budget constraints? Was the money formally divided between language design and actual implementation? If so, indicate in what way?

(b) Was there a fixed deadline for completion of the project? Was the project divided into phases and did these have deadlines? How well were the deadlines met?

(c) What is the best estimate for the amount of human resources involved (i.e., in person-years)? How much was for language design, for documentation, and for implementation?

(d) What is the best estimate of the costs prior to putting the first system in the hands of the first users? If possible, show as much breakdown on this as possible.

(e) If there were cost and/or schedule constraints, how did that affect the language design and in what ways?

3. Basic Facts About Documentation

(a) In the planning stage, was there consideration of the need for documentation of the work as it progressed? If so, was it for internal communication among project members or external monitoring of the project by others, or both?

(b) What types of documentation were decided upon?

(c) To the largest extent possible, cite both dates and documents for the following (including internal papers and web sites which may not have been released outside of the project) by title, date, and author. (In items c1, c4, c9, and c10, indicate the level of formality of the specifications – e.g., English, formal notation – and what kind.)

* (c1) Initial idea

* (c2) First documentation of initial idea

* (c3) Preliminary specifications

* (c4) “Final” specifications (i.e., those which were intended to be implemented)

* (c5) “Prototype” running (i.e., as thoroughly debugged as the state of the art permitted, but perhaps not all of the features included)

* (c6) “Full” language compiler (or interpreter) was running

* (c7) Usage on real problems done by the developers

* (c8) Usage on real problems done by people other than the developers

* (c9) Documentation by formal methods

* (c10) Paper(s) in professional journals or conference proceedings

* (c11) Please identify extensions, modifications and new versions

4. Languages and Systems Known at the Time

(a) What specific languages were known to you and/or other members of the development group at the time the work started? Which others did any of you learn about as the work progressed? How much did you know about these languages and in what ways (e.g., as users, from having read unpublished and/or published papers, informal conversations)? (Please try to distinguish between what you, as the writer knew and what the other members of the project knew.)

(b) Were these languages considered as formal inputs that you were definitely supposed to consider in your own language development, or did they merely provide background? What was it about these languages that you wanted to emulate (e.g., syntax, capabilities, internal structure, application area, etc.)?

(c) How influenced were you by these languages? Put another way, how much did the prior language backgrounds of you and other members of the group influence the early language design? Whether the answer is “a lot” or “a little,” why did these other languages have that level of influence? (This point may be more easily considered in Section II: Rationale of Content of Language.)

(d) Was there a primary source of inspiration for the language and if so, what was it? Was the language modeled after this (or any other predecessors or prototypes)?

5. Intended Purposes and Users

(a) For what application area was the language designed, i.e., what type of problems was it suppose to be used for? Be as specific as possible in describing the application area; for example, was “business data processing” or “scientific applications” ever carefully defined? Was the apparent application area of some other language used as a model?

(b) For what types of users was the language intended (e.g., experienced programmers, mathematicians, business people, novice programmers, non-programmers)? Was there any conflict within the group on this? Were compromises made, and if so, were they made for technical or non-technical reasons?

(c) What equipment was the language intended to be implemented on? Wherever possible, cite specific machine(s) by manufacturer(s) and number, or alternatively, give the broad descriptions of the time period with examples (e.g., “COBOL was defined to be used on ‘large’ machines which at that time included UNIVAC I and II, IBM 705.”) Was machine independence a significant design goal, albeit within this class of machines? (See also Question (1b) in Rationale of the Content of the Language.)

6. Source of Motivation

(a) What (or who) was the real origin of the idea to develop this language?

(b) What was the primary motivation in developing the language (e.g., research, task assigned by management?

II.RATIONALE OF THE CONTENT OF THE LANGUAGE

These questions are intended to stimulate thought about various factors that affect most language design effort. Not all the questions are relevant for every language. They are intended to suggest areas that might be addressed in each paper.

1. Environment Factors

To what extent was the design of the language influenced by:

(a) Program size: Was it explicitly thought that programs written in the language would be large and/or written by more than one programmer? What features were explicitly included (or excluded) for this reason? If this factor wasn’t considered, did it turn out to be a mistake? Were specific tools or development environments designed at the same time to support these choices?

(b) Program libraries: Were program libraries envisioned as necessary or desirable, and if so, how much provision was made for them?

(c) Portability: How important was the goal of machine independence? What features reflect concern for portability? How well was this goal attained? See also question (1) on Standardization and question (5c) under Background.

(d) User Background and Training: What features catered to the expected background of intended users? In retrospect, what features of the language proved to be difficult for programmers to use correctly? Did some features fall into disuse? Please identify such features and explain why they fell into disuse? How difficult did it prove to train users in the correct and effective use of the language, and was the difficulty a surprise? What changes in the language would have alleviated training problems? Were any proposed features rejected because it was felt users would not be able to use them correctly or appropriately?

(e) Execution Efficiency: How did requirements for executable code size and speed affect the language design? Were programs in the language expected to execute on large or small computers (i.e., was the size of object programs expected to pose a problem)? What design decisions were explicitly motivated by the concern (or lack of concern) for execution efficiency? Did these concerns turn out to be accurate? How was the design of specific features changed to make it easier to optimize executable code?

(f) Target Computer Architecture: To what extent were features in the language dictated by the anticipated target computer, e.g., its word size, existence of floating-point hardware, instruction set peculiarities, availability and use of index registers, special-purpose co-processors and accelerators, etc.?

(g) Compilation Environment: To what extent, if any, did concerns about compilation efficiency affect the design? Were features rejected or included primarily to make it easier to implement compilers for the language or to ensure that the compiler(s) would execute quickly? In retrospect, how correct or incorrect do you feel these decisions were? What decisions did you make regarding use of the compiler run-time system?

(h) Programming Ease: To what extent was the ease of coding an important consideration and what features in the language reflect the relative importance of this goal? Did maintainability considerations affect any design decisions? If so, which ones?

(i) Execution Environment: To what extent did the language design reflect its anticipated use in a batch, embedded, portable, office, or networked environment? What features reflect these concerns?

(j) Parallel Implementation: Were there multiple implementations being developed at the same time as the later part of the language development? If so, was the language design hampered of influenced by this in any way?

(k) Standardization: In addition to (or possibly separate from) the issue of portability, what considerations were given to possible standardization? What types of standardization were considered, and what groups were involved and when?

(l) Networking/Parallel Environment: To what extent did the language design reflect its anticipated use in a networked- or parallel-execution environment? What features reflect these concerns?

2. Functions to be Programmed

(a) How did the operations and data types in the language support the writing of particular kinds of algorithms?

(b) What features might have been left out, if a slightly different application area has been in mind?

(c) What features were considered essential to properly express the kinds of programs to be written?

(d) What misconceptions about application requirements turned up that necessitated redesign of these application specific features before the language was actually released?

3. Language Design Principles

(a) What consideration, if any, was given to designing the language so that programming errors could be detected early and easily? Were the problems of debugging and testing considered? Were debugging and testing facilities deliberately included in the language?

(b) To what extent was the goal of keeping the language simple considered important? What kind of simplicity was considered most important? What did your group mean by “simplicity”?

(c) What thought was given to make programs more understandable and how did these considerations influence the design? Was there conscious consideration of making programs “easy to read” versus “easy to write”? If so, which were choosen and why?

(d) Did you consciously develop the data types first and then the operations, or did you use the opposite order, or did you try to develop both in parallel with appropriate iteration? Were data and operations combined into objects?

(e) To what extent did the design reflect a conscious philosophy of how languages should be designed (or how programs should be developed)? What was this philosophy?

4. Language Definition

(a) What techniques for defining languages were known to you? Did you use these or modify them, or did you develop new ones?

(b) To what extent--if any-- was the language itself influenced by the technique used for the definition?

5. Concepts About Other Languages

(a) Were you consciously trying to introduce new concepts? If so, what were they? Do you feel that you succeeded?

(b) If you were not trying to introduce new concepts, what was the justification for introducing this new language? (Such justification might involve technical, political, or economic factors.)

(c) To what extent did the design consciously borrow from previous language designs or attempt to correct perceived mistakes in other languages?

6. Influence of Non-technical Factors

(a) How did time and cost constraints (as described in the Background section) influence the technical design?

(b) How did the size and structure of the design group affect the technical design?

(c) Provide any other information you have pertaining to ways in which the technical language design was influenced or affected by non-technical factors.

III. A POSTERIORI EVALUATION

1. Meeting of Objectives

(a) How well do you think the language met its original objectives?

(b) Do the users think the language has met its objectives?

(c) How well do you think the computing community (as a whole) thinks the objectives were met?

(d) How much impact did portability (i.e., machine independence) have on the acceptance by users?

(e) Did the objectives change over time? If so, how, when, and in what ways did they change? See also question (2d) under Rationale of Content of Language and answer here if appropriate.

2. Contributions of Language

(a) What is the major contribution made by this language? Was this one of the objectives? Was this contribution a technical or a non-technical contribution, or both? What other important contributions are made by this language? Were these part of the define objectives? Were these contributions technical or non-technical?

(b) What do you consider the best points of the language, even if they are not considered to be a contribution to the field (i.e., what are you proudest of, regardless of what anybody else thinks)?

(c) How many other people or groups decided to implement this language because of its inherent value?

(d) Did this language have any effect on the development of later hardware?

(e) Did this language spawn any “dialects”? If so, please identify them. Were they major or minor changes to the language definition? How significant did the dialects themselves become?

(f) In what way do you feel the computer field is better off (or worse) for having this language?

(g) What fundamental effects on the future of language design resulted from this language development (e.g., theoretical discoveries, new data types, new control structures)?

3. Mistakes or Desired Changes

(a) What mistakes do you think were made in the design of the language? Were any of these able to be corrected in a later version of the language? If you feel several mistakes were made, list as many as possible with some indication of the severity of each.

(b) Even if not considered mistakes, what changes would you make if you could do it all over again?

(c) What have been the biggest changes made to the language (albeit probably by other people) since its early development? Were these changes or new capabilities considered originally and dropped in the initial development, or were they truly later thoughts?

(d) Have changes been suggested but not adopted? If so, be as explicit as possible about changes suggested, and why they were not adopted.

4. Problems

(a) What were the biggest problems you had during the language design process? Did these affect the end result significantly?

(b) What are the biggest problems the users have had?

(c) What are the biggest problems the implementers have had? Were these deliberate, in the sense that a conscious decision was made to do something in the language design, even if it made the implementation more difficult?

(d) What trade-offs did you consciously make during the language design process? What trade-offs did you unconsciously make?

(e) What compromises did you have to make to meet other constraints such as time, budget, user demands, political, or other factors?

IV. IMPLICATIONS FOR CURRENT AND FUTURE LANGUAGES

1. Direct Influence

(a) What language developments of today and the foreseeable future are being directly influenced by your language? Regardless of whether your answer is “none” or “many, such as…,” please indicate the reasons.

(b) Is there anything in the experience of your language development which should influence current and future languages? If so, what is it? Put another way, in light of your experience, do you have advice for current and future language designers?

(c) Does your language have a long-range future? Regardless of whether your answer is “yes” or “no”, please indicate the reasons.

2. Indirect Influence

(a) Are there indirect influences which your language is having now? Are there any indirect influences that it can be expected to have in the near future? What are these, and why do you think they will be influential?

Questions on the Evolution of a Programming Language

Tue, 2 Jan 2007 13:23:33 -0500

The principle objective of a contribution in this category is to treat the history of a major language subsequent to its original development. In many cases, this entails extending the history of some language whose origins were treated in HOPL-I, or in HOPL-II. (Authors of papers in this category will be working with a member of the Program Committee, who will keep you informed of other relevant papers under consideration.)

When a programming language is first developed, it is typically the work of an individual or a small, concentrated group. Later development of the language is often the result of an expanded, re-staffed group, and perhaps additional individuals or groups outside the original organization. Similarly, while the original work is often focused on language design and implementation for a single environment, later developments are undertaken in a broader arena.

When compared with questions about the early history of a language, the following questions reflect this change in context. In particular, these questions are about the set of diverse development activities that surround the language, such as standardization, new implementations, significant publications, language-oriented groups (e.g., SIGs, user groups), etc.

These questions are grouped into the same four broad categories that apply to papers on the origins of a language:

1. Background
2. Rationale
3. A posteriori evaluation
4. Implications for current and future languages

The first question applies broadly to the language itself. It is intended to identify the particular development activities that are the focus of the history paper. In contrast, you should address the remaining questions for each of the activities identified in that initial background section.

You might also have significant information to contribute in response to questions raised about the early history of the language. Please examine the questions provided for authors of “early history” papers.

Where appropriate, your contribution should make reference to related papers from HOPL-I, HOPL-II, or HOPL-III.

I. BACKGROUND

1. Basic Facts About Activities, Organizations and People

(a) What are the categories of development to be discussed (e.g., standardization, new implementations, open source, significant publications) and what specific activities are reported on?

(From this point on, each question is intended to apply independently to each development activity identified in question I.1(a) above.)

(b) What organizations played principal roles in these developments? Identify them as precisely as possible: corporation and division, university and department, agency and office, etc. How were these organizations sponsored and funded?

(c) What, if any, was the nature of the cooperation or competition among these organizations?

(d) Who were the people involved in these developments? How were they related organizationally to each other and to the original developers for this language? Please be as specific as possible regarding names, titles, and dates.

(e) How did the roles of various individuals change during the course of the activity?

2. Costs and Schedules

(a) What was the source and amount of funding for supporting the development? Was it adequate?

(b) What was the schedule, if any?

(c) What was the estimated human effort required to carry it out?

(d) What was the estimated cost of the development?

(e) What were the effects of cost and schedule constraints?

3. Basic Facts About Documentation

(a) What are the significant publications arising from development? For each provide:

• A specific reference
• Names of authors (if not part of the reference)
• Intended audience (e.g., user, implementer)
• Format (e.g., manual, general trade book, standards document)
• Availability

4. Languages/Systems Known at the Time

(a) What languages or systems other than the one in question had an effect on the development? In what ways did they affect the development?

(b) How did information about each of these languages or systems become available to the people it influenced?

5. Intended Purposes and Users

(a) What was the intended purpose of the development?

(b) Were the results proprietary, for sale, freely distributed, etc.?

(c) For whom were its results intended? How did this group of people differ from the originally intended set of users for this language?

6. Motivation

(a) Who was the prime mover for the development?

(b) What was the underlying motivation for the development?

II. RATIONALE FOR THE CONTENT OF THE DEVELOPMENT

To the extent that is appropriate, apply the “early history” questions in each of the following subcategories to the activity being addressed.

1. Environment Factors

(a) What were the effects on the development of concerns about program size, program libraries, portability, user background, execution efficiency, target computer architecture and speed, compilation environment, programming ease, execution environment, character set, parallel implementation, standardization, networked or parallel environment?

(b) In what ways had the environment changed since the original development of the language?

2. Expected Applications of the Language

(a) How did expected applications influence choice of operations, data types, and objects?

(b) What features were essential to meet intended applications?

3. Design Principles Applied to the Development

(a) What, if any, was the underlying, consciously applied design philosophy?

(b) What considerations were made for detecting and correcting errors in the development?

(c) What role did “simplicity” play, and what was meant by “simplicity”?

(d) What role did “understandability” play? Which was given higher priority: “ease of reading” or “ease of writing”, and why?

(e) Were certain aspects of language (e.g., data types, operations, objects) considered more fundamental to the development than others? Why?

4. Language Definition

(a) What language definition techniques were used in this development? To what extent was the result of the development influenced by these choices?

5. Concepts of Other Languages

(a) To what extent was the introduction of new language concepts or features a part of this development?

(b) In what ways did concepts from other languages influence this development?

6. Influence of Non-Technical Factors

(a) What was the effect of other, similar developments on this one (e.g., overlapping standardization efforts)?

(b) What was the effect of time and cost constraints on the development?

(c) How did the size and structure of the development group affect results?

III. A POSTERIORI EVALUATION

1. Meeting of Objectives

(a) How well did the development meet its objectives?

(b) How well did the users feel the development met its objectives?

(c) What was the reaction of the computing community at large?

(d) How did portability of results impact their acceptance?

(e) Did the objectives of the development change over time? If so, when, how, and why did they change?

2. Contributions of the Development

(a) What were the biggest contributions of this development? Were they among the original objectives?

(b) What do you consider its best features? What do you consider its worst features?

(c) How has this development affected other activities (e.g., development of other languages, dialects, language processors, standards, operating systems, and computer hardware)? Which of these other activities have become significant in their own right?

(d) In what way is the computer field better or worse off because of this development?

(e) What fundamental effects on programming language methodology have arisen from this development? (e.g., new data types, control structures, techniques for definition, for types of documentation, application design strategies, theoretical discoveries, etc.)

3. Mistakes or Desired Changes

(a) What mistakes were made in the development? Were these mistakes corrected in later developments?

(b) What changes would you now make, if you could?

(c) What were the biggest changes made to the development results since they were first released? Had they been considered earlier and then dropped, or were they truly later thoughts?

(d) What significant changes have been suggested but not adopted, and why?

4. Problems

(a) What were the major obstacles in carrying out the development?

(b) What were the major problems encountered by people who used its results: e.g., language users, designers, implementors, standards committees, etc.?

(c) What trade-offs were made during the development? Which were made consciously and which were recognized after the fact?

(d) What compromises were made to meet other constraints such as time, budget, user demand, and political factors?

(e) Which estimates (time, cost, effort, and human resources) were farthest from reality? Why were they off?

(f) What application-specific features might better have been left out?

IV.IMPLICATIONS FOR CURRENT AND FUTURE LANGUAGES

(a) Which current and foreseeable developments are being directly or indirectly influenced by this development, and why?

(b) Which results, if any, of this development have a long range future? Why?