HOPL IV
Mon 1 Jun 2020

The Papers track of HOPL-IV will include published papers that will be complemented by oral presentations at the conference. The Program Committee encourages submissions that discuss and analyze the historical development of individual programming languages, programming language families, language features, design themes, and other strong influences on the direction of programming language design, implementation, and usage.

Detailed information is listed on separate pages. Click on either the tabs above or the links in the list below.

Call for Papers

For HOPL-IV the Program Committee encourages submissions that discuss and analyze the historical development of individual programming languages, programming language families, language features, design themes, and other strong influences on the direction of programming language design, implementation, and usage. A HOPL-IV paper that is about a single specific language should detail the early history or evolution of that language and the motivation for creating that new language; ideas about the language should have been documented by 2009, and the language should have been widely used by 2011. A HOPL-IV paper that addresses a language or language family already described in a previous HOPL conference should provide substantial new detail about language evolution, development and standardization activities, new dialects and implementations, significant publications, applications, user groups, and other technical and social consequences. A HOPL-IV paper about a more general historical theme or trend should take a cross-language perspective to discuss and analyze some issue or design feature that has affected the historical development of programming language design, implementation, and usage over a span of at least twenty years.

The Program Committee will work closely with prospective authors to ensure that both the content and presentation of the papers are of high quality. There will be two rounds of careful reviewing. The first round will select the papers for the conference (conditional acceptance); the second round will polish the papers and ensure that they meet the requirements for technical accuracy, historical completeness, and clarity. The Program Chairs may also ask outside experts to provide additional reviews. For each selected paper, a member of the Program Committee will be assigned as a “shepherd” to ensure that intermediate drafts are carefully revised and written clearly, and that the recommendations of reviewers are addressed.

Complete Author Guidelines and Instructions will soon be posted here. Because of the complex nature of the history of programming languages, there is no upper bound on the length of submitted papers—authors should strive for completeness. We strongly recommend that prospective authors examine papers presented at previous HOPL conferences to get an idea of appropriate length, content, and organization. The website http://research.ihost.com/hopl has information about past HOPL conferences and links to their proceedings.

Papers awaiting acceptance to any other conference or journal are not eligible for submission to HOPL-IV. If a closely related paper has been submitted elsewhere, the HOPL-IV chairs must be notified. Authors of accepted papers are expected to make presentations (to be recorded in video form) at the conference. Final papers and video recordings of the presentations will be placed in the ACM Digital Library.

Program committee member policy: There will be no restriction on submissions from PC members. The program chairs/general chairs may not submit papers. PC papers will be held to a higher standard than other papers. The criterion for acceptability of a PC paper is a clear accept.

Authors should submit a 1-page abstract by July 31, 2018. Full papers for the first round are due on August 31, 2018, with notification to authors in February 2019. Second-round submissions will be due in August 2019, with notification to authors in January 2020. Final copy will be due in March 2020. Authors of accepted papers will be required to sign ACM copyright release forms.

Inquiries may be sent by email to hopl4@sigplan.org.

HOPL has been held only infrequently; the first three were in 1978, 1993, and 2007. HOPL-IV is scheduled for June 2020.

HOPL-I

The first History of Programming Language Conference (now also called HOPL-I) was held in 1978. [ACM website; historical website] The program chair, Jean Sammet, established the general format and rigorous reviewing criteria that have been followed ever since. (Sammet was also the author of the book Programming Languages: History and Fundamentals, an encylopedic survey of programming languages as of 1969.)

Each HOPL-I paper discussed the development and evolution of a computer programming language, the people who participated in that work, and the context in which it was undertaken. A separate brief technical summary of each presented language was also prepared, either by the authors of the corresponding paper or by a separate invited expert. For each paper there was an oral presentation at the conference, followed by a relatively lengthy question-and-answer session, both of which were transcribed and published. Papers on these languages were presented at HOPL-I:

ALGOL (American side) COBOL LISP
ALGOL (European side) FORTRAN PL/I
APL GPSS SIMULA
APT JOSS SNOBOL
BASIC JOVIAL language summaries

The HOPL-I proceedings were also published as a book, edited by Richard Wexelblat.

HOPL-II

HOPL-II, held in 1993, was also chaired by Jean Sammet. [ACM website; historical website] Some papers addressed concepts and/or language families rather than single languages. As for HOPL-I, a separate brief technical summary of each presented language was also prepared, either by the authors of the corresponding paper or by separate invited experts. Papers on these fourteen topics were presented at HOPL-II:

Ada (and summary) ALGOL 68 (and summary) Smalltalk (and summary)
C (and summary) Forth (and summary) Discrete Event Simulation Languages (and summary)
C++ 1979–1991 (and summary) FORMAC (and summary) Evolution of Lisp (and summary)
CLU (and summary) Pascal (and summary) Monitors and Concurrent Pascal (and summary)
Icon (and summary) Prolog (and summary)

The HOPL-II proceedings were also published as a book, edited by Thomas Bergin and Richard Gibson. (The transcripts of the presentations and discussion appear only in the book, not on the ACM website.)

HOPL-III

In 2007, HOPL-III was chaired by Barbara Ryder and Brent Hailpern, with Jean Sammet on the program committee. [ACM website; historical website] For this conference, all oral sessions were videotaped. The twelve papers at HOPL-III described thirteen languages:

AppleScript Erlang Modula-2 and Oberon
BETA Haskell Self
C++ 1991–2006 High Performance Fortran (HPF) Statecharts
Emerald Lua ZPL

The HOPL-III conference also included the retrospective multimedia keynote presentation 50 in 50 (also reprised at Yow! 2010 and viewable here).

Submission Preparation Instructions

Deadlines: The deadline for submission of an initial one-page abstract is Tuesday, July 31, 2018, Anywhere on Earth. A full paper submission must be added by Friday, August 31, 2018, Anywhere on Earth. These deadlines will be strictly enforced.

Submission: Submissions will be accepted through a web interface at https://hopl4.hotcrp.com. To avoid last-minute problems, authors are encouraged to create a hotcrp account and a HOPL-IV submission page for their submission well ahead of July 31, 2018 (which is the deadline for abstracts).

Improved versions of an abstract may be submitted at any time before the abstract submission deadline using the same web interface. Similarly, improved versions of a full paper may be submitted at any time before the full paper submission deadline. In each case, the last version submitted before the deadline will be the version reviewed.

Paper format: Submissions must be in PDF format, printable in black and white on both US Letter sized and A4 sized paper, and interpretable by common PDF tools. All submissions should adhere as closely as possible to the “ACM Small” template that is available (in both LaTeX and Word formats) from http://www.acm.org/publications/authors/submissions. This is a single-column page layout with a 10-point font, 12-point line spacing, and wide margins: the main text block is 5.478 inches (13.91 cm) wide and 7.884 inches (20.03 cm) tall. For authors using LaTeX, the use of the review option is also strongly encouraged but not required. (The review option will add line numbers, which will make it easier for reviewers to reference specific parts of your paper in their comments, but should have absolutely no other effect on the typesetting.)

Because of the complex nature of the history of programming languages, there is no upper bound on the length of submitted papers—authors should strive for completeness. The Program Committee strongly recommends that prospective authors examine papers presented at previous HOPL conferences to get an idea of appropriate length, content, and organization. For more information, see the Content Guidelines for Authors.

Citation format: HOPL-IV papers are expected to use author-year citations for references to other work. Author-year citations may be used as either a noun phrase:

The lambda calculus was originally conceived by Church (1932).

or a parenthetic phrase:

The lambda calculus (Church 1932) was intended as a foundation for mathematics.

A useful test for correct usage is to make sure that the text still reads correctly when the parenthesized portions of any references are omitted. Take care with prepositions; in the first example above, “by” is more appropriate than “in” because it allows the text to be read correctly as a reference to the author.

In LaTeX, use \citet to get a citation in the form of a noun phrase and \citep to get a citation in the form of a parenthetic phrase:

\citet{Church-1932} produces “Church (1932)”

\citep{Church-1932} produces “(Church 1932)”

For details, see Sections 2.3 through 2.5 of the natbib documentation (http://ctan.org/pkg/natbib).

Authorship Policies: All submissions are expected to comply with the ACM Policies for Authorship.

Republication Policies: Papers must be unpublished work that is not currently submitted for publication elsewhere as described by SIGPLAN’s Republication Policy. Submitters should also be aware of ACM’s Policy and Procedures on Plagiarism.

Final Publication and Copyright Requirements

Because of the long lead time for the HOPL conference, the precise formatting requirements for the final versions of papers to be published have not yet been determined.

Authors of accepted papers will be required to choose one of the following publication rights:

  1. Author licenses the work with a Creative Commons license, retains copyright, and (implicitly) grants ACM non-exclusive permission to publish (suggested choice).
  2. Author retains copyright of the work and grants ACM a non-exclusive permission-to-publish license.
  3. Author retains copyright of the work and grants ACM an exclusive permission-to-publish license.
  4. Author transfers copyright of the work to ACM.

These choices follow from ACM Copyright Policy and ACM Author Rights, corresponding to ACM’s “author pays” option.

Presentation Requirements

On-the-record in-person presentation and discussion of papers is an important part of the HOPL conference format. At least one author of each accepted submission will be expected to attend and present their paper at the conference. (HOPL-IV welcomes all authors, regardless of nationality. In the extreme case that authors are unable despite reasonable effort to obtain visas to travel to the conference, efforts will be made to enable remote participation. In such cases, the HOPL-IV chairs should be contacted (email: hopl4@sigplan.org) for guidance.)

The schedule for presentations will be determined and shared with authors after the full program has been selected.

Each presentation will consist of a long talk (likely 45 minutes or longer), to be followed by a question-and-answer session, according to the conference schedule. HOPL-IV presentations and associated question-and-answer sessions will be videorecorded and released online.

A paper may be presented at the conference only if (i) all authors of the paper have signed a copyright form to permit publication by ACM under one of the allowed copyright options, (ii) at least one author of the paper is registered to attend the conference, and (iii) all presenters have signed a consent form to permit videotaping and online publication of the presentation.

The first three History of Programming Languages conferences established high technical and editorial standards. We trust that your contribution will help HOPL-IV maintain or surpass these standards. These guidelines are intended to help you develop the appropriate content for your contribution to HOPL-IV.

Appropriate Languages

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

(1) The programming language came into existence before 2009, that is, it was designed and described at least 11 years before HOPL-IV (2020).

(2a) The programming language has been widely used since 2011 either (i) commercially or (ii) within a specific domain. In either case, “widely used” implies use beyond its creators.

(2b) Certain research languages had great influence on widely used languages that followed them. If the research language was used by more than its own inventors, and the paper clearly traces its influence on other languages in wider use, then it may be considered appropriate for discussion at HOPL-IV.

Please be sure to include within your paper a clear indication of how the subject material satisfies these criteria—not only (1), but also either (2a)(i) or (2a)(ii) or (2b). 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.

Categories of Submissions

There are four kinds of papers that may be considered for HOPL-IV:

  • Early History of a specific language, typically including the story of its initial design and first implementation(s)

  • Later Evolution of a specific language (usually a language already treated in an earlier HOPL conference)

  • A cross-language examination of a specific Feature or Concept

  • Consideration of a Class of Languages having a common theme or purpose

These categories overlap to some extent; for example, Evolution of a single initial language may result in a Class of Languages that share some Feature or Concept. It is not necessary to label your submission as belonging to a specific category; rather, the categories are intended as a tool to help you organize the story you want to tell and to make sure that relevant information is not overlooked.

Questions for Authors

For each category we provide a set of questions that you should consider when writing your paper (to see them, click on the links in the list shown above). The questions point to the kind of information that people want to know about the history of programming languages. The four sets of questions overlap to some extent; 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. It may be appropriate for you to examine more than one set of questions. Conversely, keep in mind that there may be important aspects of your specific story that the questions fail to address.

Your paper should try to answer as many questions as possible, but 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 that the very fact of unavailability may be important to report as well. Several questions are of the form “How did something affect something else?”; it may be important for the historical record to assert that “it didn’t.”

A question set is intended to suggest 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 to serve 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 for your paper seems most appropriate and comfortable to you.

We recommend that you read two pages of advice from Michael S. Mahoney about What Makes History?. This will help you to adopt an appropriate historical perspective when writing.

Examples

The Program Committee strongly suggests that you examine at least one paper from each of the proceedings of HOPL-I, HOPL-II, and HOPL-III to see what earlier contributors did. Links to all prior HOPL papers (within the ACM Digital Library) may be found here. We also suggest here examples of papers in each category:

Please see the Content Guidelines for Authors for detailed instructions on how to use this set of questions.

The principal objective of a contribution in this category is to record the history of the origins, early development, and initial deployment of a single programming language.

I. BACKGROUND

These questions are directed primarily to the origins of the project and to the people involved and how they were organized.

  1. 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)?

    (c) Did the motivation change over time before the language was released? After the language was released?

  2. 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 other languages did any of you learn about as the work progressed? Was such learning in intentional pursuit of information to guide the design or development of the new language? 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, from documentation, from reading the code for the implementation, from having participated in the design or implementation)? Please try to distinguish between what you, the author, knew at the time and what the other members of the project knew at the time.

    (b) Were these other languages regarded as formal inputs 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?

    (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)?

  3. 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, consortium or collaboration, open-source project, standardization effort)? Be as specific as possible about organizational units and 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, government contract)?

    (d) Who were the people on the project and what was their relationship to the author(s) (e.g., team members, subordinates, managers)? 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 and when. Indicate the technical experience and background of each participant, including formal education.

    (e) Were the design and implementation done together, by a single person or team? Alternatively, were there separate design and implementation steps or phases, and if so, were the design and the implementation done by the same people or different (possibly overlapping) teams?

    (f) Was the design 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 what? Was it a side effect of some other effort that happened to produce a language as a subgoal, but the language itself ended up being important in its own right?

    (g) Was the implementation 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 what?

    (h) Was there a separate documentation team, or was documentation written by designers and/or implementors?

    (i) Was testing (“quality assurance”) done by a separate team? By the designers or implementors?

    (j) Were there any persons whose roles were “marketing” or “user liaison” or “user training”? If so, who fulfilled such roles, and how?

    (k) 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)?

    (l) Was there a de facto leader different from the defined leader? If so, who was this leader and what made this person the de facto leader (personality, background, experience, a “higher authority”, something else)? Was one person the “manager” and another the “technical lead”? Or did more than one person fill either or these roles? Was technical leadership divided according to multiple design or implementation areas?

    (m) 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.

    (n) Did the participants in the project view themselves primarily as language designers, as implementors, 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?

    (o) 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”, was the technical language design affected by this?

    (p) Did the language designers know (or believe) that they would also have the responsibility for maintaining subsequent versions? Whether the answer is “yes” or “no”, was the technical language design affected by this?

  4. 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, 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, for implementation, and for other functions?

    (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?

  5. 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) Did any sort of intentional specification precede implementation, or was an initial implementation followed by documentation?

    (d) If documentation and implementation were found to be in conflict, was one generally considered more definitive than the other? If so, which one, and why? Did this change over time?

    (e) Was a test suite developed to verify the implementation? If so, was it used to perform regression tests on the compiler or other parts of the implementation? Was the test suite made public? To what extent was the test suite considered part of the (internal or external) specification or documentation?

    (f) 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.

    • (f1) Initial idea

    • (f2) First documentation of initial idea

    • (f3) Preliminary specifications

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

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

    • (f6) “Full” language compiler (or interpreter) was running

    • (f7) Usage on real problems done by the developers

    • (f8) Usage on real problems done by people other than the developers

    • (f9) Documentation by formal methods

    • (f10) Paper(s) in professional journals or conference proceedings

    • (f11) Please identify extensions, modifications and new versions

    • (f12) Independent implementations by other groups or organizations

    For each of these stages, where relevant, indicate the level of formality of the specifications. Were specifications entirely in prose (in English or some other “natural language”), or were any formalisms used (examples include BNF, regular expressions or other ways of marking optional or repeated elements in the syntax, syntax diagrams (aka “railway charts”), attribute grammars, mathematical equations, algebraic specifications, denotational semantics, the Vienna definition language, compiler-construction tools such as parser generators, and proof assistants)? Were the formalisms directed primarily to the explanation of syntax, or was formalism also used in the explanation of semantics (that is, program behavior)?

    (g) If there were independent implementations, did they rely entirely on specifications and documentation, or did they read or borrow from an existing code base and/or communicate directly with the original development team?

    (h) Please reflect on the project documents as historical sources. Throughout your paper, identify when you are relying on these documents for information, and when you are relying on memory or other sources. Are there places where memory and documentation conflict? Do you now regard the available documentation as a complete and faithful record of the history, or can you identify gaps or incorrect information in the documents?

    (i) It may be appropriate to reproduce a limited number of original documents or photographs in your paper. Which ones are the most relevant for telling the story?

  6. Intended Purposes and Users

    (a) For what application area was the language designed? What type of problems was it intended to be used for? Traditional labels such as “business data processing” or “scientific applications” may be too vague; please be as specific as possible and appropriate in describing the application area.

    • (a1) Was a specific statement of application area or purpose drafted when the project started? If so, did it change over the course of the project?

    • (a2) 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) Why develop a new language? Why were existing languages deemed sufficiently inadequate for the purpose that a new effort was justified?

    • (c1) Was the design developed from whole cloth in response to the stated application area or purpose?

    • (c2) Was the intent to create a language “just like language X, except for thus-and-so specific improvements”?

    • (c3) Was the intent to create a synthesis of the best ideas from two or more other languages?

    • (c4) Was the language created in order to exemplify or promulgate a specific theoretical idea?

    • (c5) Was the language initially the result of “just hacking around”, perhaps by grafting a new idea or two onto an existing language?

    (d) How much of the language design effort went into application-specific features, and how much of it went into “structural issues” or “software engineering issues” such as modularity, namespace management, debugging support, or features coders of libraries might need as opposed to application programmers?

    (e) What equipment was the language originally intended to be implemented on? Wherever possible, cite specific machine(s) by manufacturer(s) and model numbers, or alternatively, give broad descriptions relevant to the time period with specific examples. Consider this example from the HOPL-I paper about COBOL:

    COBOL was designed from its inception to be used on large computers (by 1959 standards, although by 1978 standards they would be considered minicomputers), intended for business data processing use. In particular, machines for which COBOL was certainly being considered were the UNIVAC I and II, the IBM 705 and 709, the Honeywell 800, RCA 501, Sylvania MOBIDIC, [and] Burroughs B-5000.

    Was machine independence a significant design goal, albeit within this class of machines?

  7. Distribution

    (a) Was the language specification (information needed to create a complete implementation) made available to users? Was it considered proprietary? Was it provided for free or for sale? What distribution media were used?

    (b) How was the language implementation made available to users? Was it considered proprietary? Was it provided for free, for lease or subscription, or for sale? What distribution media were used? Were users able to run it on their own hardware, or only as part of a service on hardware they did not own?

    (c) How was the language documentation (information needed to use the language, which may or may not include the specification and may or may not include tutorial material) made available to users? Was it considered proprietary? Was it provided for free or for sale? What distribution media were used?

    (d) Did the answers to any of the preceding questions change over time?

II. RATIONALE OF THE CONTENT OF THE LANGUAGE

These questions are directed to the technical content of the language design and implementation effort and 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. This is not necessarily an exhaustive list of relevant questions.

  1. Environmental 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? Or, conversely, was it explicitly thought that typical programs would be small and/or written primarily by 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 and/or Frameworks: Were “program libraries” (or “standard frameworks”) envisioned as necessary or desirable, and if so, how much provision was made for them? Were “standard libraries” a major portion of the language design effort? If so, what libraries were especially important? Which libraries were novel, unusual, or essential to the “flavor” of the language? Alternatively, was it an important design goal of the language to be able to interoperate with existing libraries already coded in another language?

    (c) Portability: How important was the goal of machine independence? What features reflect concern for portability? How well was this goal attained?

    (d) User Background and Training: What features catered to the expected background of intended users?

    • (d1) Were any notational or semantic features of the language intentionally modeled on notations or semantics not widely used in computer science but customary in an intended domain of application?
      • (d2) 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?

      • (d3) 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.

    (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 and/or execution speed 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 characteristics of the anticipated target computer (e.g., word size, floating-point hardware, instruction set peculiarities, application-specific instructions, register or cache structure, special-purpose co-processors and accelerators, parallelism, synchronization features, transactional memory)? Were there multiple targets, and if so, in wha way did this affect the language design or implementation?

    (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, timeshared, embedded, portable, mobile, wearable, kiosk, office, or networked environment? What features reflect these concerns?

    (j) Multiple Implementations: 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, improved, or 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? Was execution efficiency in a networked or parallel environment (as opposed to single-CPU efficiency) a concern?

    (m) Interoperability: Was it important for programs written in this language to interoperate with code written in other languages, operating systems, or other tools? If so, which ones, and why? Did this require specific technical features in the new language?

    (n) Documentation: Were features included to specifically to support documentation of programs coded in the language? If so, did they support documentation tied to the program representation, generation of separate documents (paper documents, files, web pages), or both? What tools and conventions were used or supported?

    (o) Reliability: Were features included specifically to support detection or prevention of programming errors and/or proofs of program correctness? Were otherwise common or familiar features omitted in order to help prevent programming errors?

    (p) Debugging: Were features included specifically to support the debugging process?

  2. Functions to be Programmed

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

    (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 application-specific features before the language was actually released?

    (e) To what extent were application-specific features incorporated directly into the language design, and to what extent was the expectation that application-specific features would be provided (perhaps as libraries) by coding in the language itself? Were any features of the language specifically intended to support or enable the latter?

  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”? Was there an explicit statement of simplicity that guided the design effort?

    (c) To what extent was the goal of keeping the language consistent considered important? What kind of consistency was considered most important? What did your group mean by “consistency”? Was there an explicit statement of consistency that guided the design effort?

    (d) Were there any other explicitly stated principles that guided the language design? If so, were any specific proposed features modified or omitted after coming into conflict with a stated principle?

    (e) 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 chosen and why?

    (f) 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?

    (g) 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?

    (h) Did you intentionally model the language according to an existing style or school of thought (e.g., Algol-like, Lisp-like, macro-like, imperative, declarative, block-structured, object-oriented, functional, pure, or stack-based)? If so, why? In what ways does your resulting design reflect this style or school of thought, and in what ways does it differ, and why?

    (i) Were any slogans or catchphrases used as summaries or reminders of language design principles? Were they used internally or also externally? Were they used seriously or jocularly?

    (j) Did the developers of the language make any attempt to evaluate specific features, or the entire language design, objectively/empirically? Did the results lead to changes in the language design? Did such changes result in programs that were somehow better (e.g., shorter, more reliable, more efficient, easier to read, easier to maintain)?

  4. Language Specification

    (a) What techniques for specifying 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 specification?

    (c) What formalisms and/or tools were used in the specification process?

  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? (Conversely, was it a design goal to avoid introducing new concepts? If so, why?)

    (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) How did the size and structure of the implementation group affect the implementation?

    (d) How did the size and structure of the documentation group affect the documentation?

    (e) Did the membership of any of these groups change over time, and if so, how did such changes affect the design, implementation, or documentation efforts?

    (f) 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

These questions are directed to assessing the language project from today’s standpoint.

  1. Meeting of Objectives

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

    (b) What is the size and nature of the current user community? Do the users think the language has met its objectives? Do the users think the language has met their needs? If not, what do users think could be done, or should have been done, to further improve the language?

    (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 acceptance by users?

    (e) How much impact did other specific aspects of the language (such as execution efficiency, compilation efficiency, ease of programming, or specific libraries) have on acceptance by users?

    (f) Did the objectives change over time? If so, how, when, why, and in what ways did they change?

    (g) Was the language eventually put to unexpected uses, or adopted by an unexpected user community? If so, what were the results? Did the language change further in response to these new uses? How might the language or even the initial objectives have been different if these uses had originally been anticipated?

  2. Contributions of Language

    (a) What is the major contribution that was 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 defined 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) Are there now multiple independent implementations of the language?

    (d) What other people or groups decided to implement this language because of its inherent value?

    (e) Did this language have any effect (positive or negative) on the development of later hardware?

    (f) Did this language have any effect (positive or negative) on the development of later languages? Have specific innovative features of this language appeared in later languages?

    (g) 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? Describe the resulting “family tree” of both languages and development communities.

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

    (i) 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? Why do you consider them to be mistakes? 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 (possibly by people other than the original development team) since its early development? Were these changes or new capabilities considered originally and omitted in the initial development, or were they truly later thoughts? If they were originally considered and omitted, why were they omitted (e.g., desire for simplicity, consistency with overarching design principles, time or other resource constraints)? Were they omitted with the intent to reconsider them later?

    (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 implementors 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 are the biggest problems the documenters of the language have had? Would the language have been easier to document or to explain to users if the language had been designed differently?

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

    (f) 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

These questions are directed to the ways in which your language or language project might affect its successors.

  1. Direct Influence

    (a) Have other, more recent language designs been directly influenced by this one? Have other languages borrowed specific features, implementation techniques, specification techniques, documentation techniques, debugging techniques, or proof techniques from this language effort? Has any other language had interoperability with this language as one of its design goals?

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

    (c) 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? What are the important lessons learned from the development of this language? What are the important lessons from the user experience?

    (d) 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?

    (b) 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?

To be provided soon

Please see the Content Guidelines for Authors for detailed instructions on how to use this set of questions.

The principal objective of a contribution in this category is to record the history of a programming language feature or concept.

This question set has a quite different focus from the set dealing with the development of some particular language. A particular language feature or concept is incorporated in multiple particular languages; therefore much of the information solicited here is comparative. However, to the extent that you were party to the development of particular language(s) embodying this feature, it may be appropriate also to be guided by the Questions on the Early History of a [single] Language.

For simplicity, these questions usually refer to a “feature” rather than a “feature or concept.”

  1. Origins

    (a) Who invented or introduced this feature? Was it a single person, a team, or a committee? What was their background? How did they come to use this background in their development?

    (b) What are the important publications (e.g., papers, language manuals) about the feature? Please make a special point of identifying as many early publications as possible, including informal and internal documents.

    (c) If the feature first appeared in a simpler or even “half-baked” form before the widespread form emerged, be sure to describe the early forms, with citations, and how and why they evolved. What factors caused the feature to reach a “definitive” form (e.g., perceived technical merit, feedback from early or prospective users, institutional pressures)?

    (d) Was the creation or implementation of the feature motivated more by theory or by practice?

    (e) Did the feature emerge as the result of a research project? A corporate or industrial project? A standardization process? “Just hacking around”?

    (f) Was there a stated rationale or set of goals for the feature?

    (g) Was there a stated set of design principles for the feature?

    (h) Was the feature first created especially for a single language (from it then presumably spread to other languages), or did its creator(s) originally have in mind a class of languages (e.g., Algol-like, functional, object-oriented, parallel)?

    (i) In which language(s) was this feature first introduced? Who introduced it? How did the people involved with it interact in the process, if more than one person was involved?

    (k) Was a new language created specifically to embody or exemplify this new feature, or was its first implementation or embodiment grafted into an existing language, or was it one of a number of innovations in a new language?

    (l) Please consult the Background section of Questions on the Early History of a Language for questions about project organization, project funding, documentation, and distribution.

  2. The Nature of This Feature or Concept

    (a) What are the distinctive characteristics of this feature? Be sure to discuss both syntax and semantics, and what aspects are essential and which are nonessential.

    (b) Was the feature intended to express an idea previously very difficult or impossible to express in existing languages? Alternatively, was it intended to make an already expressible idea more convenient, more concise, more abstract, more concrete, more specific, more reliable, or more maintainable?

    (c) What shortcomings of existing languages prompted the discovery, invention, and/or introduction of this feature?

    (d) What set of expressive or methodological problems did this feature address at the time of its introduction? How was the absence of this feature handled prior to its introduction?

    • (d1) Does the feature address some specific application area?

    • (d2) Does the feature address a problem related to program organization?

    • (d3) Does the feature address a problem related to compile-time processing?

    • (d4) Does the feature address a problem related to run-time processing?

    • (d5) Does the feature address a problem related to a specific hardware architecture or class of architectures?

    • (d6) Does the feature address a problem related to operating systems, input/output, user interfaces, or networking?

    • (d7) Does the feature address a problem related to documentation?

    • (d8) Does the feature address a problem related to debugging?

    • (d9) Does the feature address a problem related to ensuring (or increasing the likelihood of) program correctness?

    • (d10) Does the feature make programs easier to write? To read? To compile? To execute? To verify?

    • (d11) To what extent did the feature support the coding of libraries (as opposed to end applications)?

    (e) How did this feature enhance a programmer’s ability to express the solution of a problem?

    (f) What forces (e.g., theoretical concerns, market demand, error-proneness of alternative forms) supported the introduction and evolution of the feature?

    (g) What external influences (e.g., changes in technology, new classes of problems, new classes of users) contributed to the need for this feature, or to its introduction and evolution?

    (h) What other features or concepts were precursors of this one? In which language(s) did they exist?

    (i) Was the feature intended to extend, supersede, provide an alternative to, or complement an already existing feature or concept?

    (j) Is the concept of a “negative” form that perhaps manifests itself as a lack of language features (e.g., there are no goto statements, there are no global variables, there are no side effects, multiple processes or threads cannot share data structures or pointers, the programmer cannot explicitly deallocate data structures)? What are the positive and negative consequences of such restrictions?

    • (j1) Did this concept require the creation of new complementary features, or the adoption of already existing features from other languages, to compensate for this lack?

    • (j2) Are such compensating features essentially the same in all languages that embody the concept, or did different languages end up with different sets of compensating feature? Why?

    (k) To what extent did implementation of the feature require changes to a compiler (e.g., intermediate code representations, code analyses, phase structure)? To the structure of compiler output (such “binary files”)? To linkers, loaders, debuggers, or other tools? To run-time organization (e.g., code, data, register conventions, stack organization, heap organization)? To libraries?

    (l) To what extent does the presence of the feature make interoperability another language easier or more difficult? Does the answer to this question depend on whether that other language does or does not also support or provide the feature?

  3. Use and Subsequent Evolution

    (a) To what extent was the feature used in practice? Did its actual usage correspond to the expectations of its designers (in terms of both amount of use and nature of use)? Did experience from use lead to changes in the nature of the feature in the same language, or in subsequent languages?

    (b) How did this feature evolve over time? Into what other forms has the feature evolved in languages currently in use?

    (c) What language(s) have embodied or now embody this feature? (Please be as inclusive as you can. However, it may be appropriate to concentrate on a few exemplars when making comparisons.)

    • (c1) How does the feature manifest itself in each language? Give examples.

    • (c2) In what ways are these languages similar or different in their incorporation of the feature?

    • (c3) Why do languages differ in the ways they incorporate the feature? Do such differences cause any problems for users?

    (d) How did this feature interact with other features in the languages which embody it? How has this interaction influenced the evolution of this or other features? With what other language features is it most or least compatible? Are conflicts primarily syntactic or semantic in nature?

    (e) What obstacles (institutional, financial, psychological, political, temporal, technological, etc.) were encountered during the introduction and evolution of this feature? How did they affect it? How were they overcome?

    (f) What is the present incarnation of the feature, if any? In which languages can it be found today?

    (g) Were there competing or complementary features or concepts that conflicted with this one? If so, what was the nature of this conflict, and how was it resolved?

    (h) Has the feature itself evolved into distinct (and possibly competing) forms? Which languages exemplify these distinct forms? Why did differing forms arise?

    (i) Did the developers or users of the feature make any attempt to evaluate the feature objectively/empirically? Did the results lead to changes in the feature? Did such changes result in programs that were somehow better (e.g., shorter, more reliable, more efficient, easier to read, easier to maintain)?

  4. A Posteriori Evaluation

    These questions are directed to assessing the feature or concept from today’s standpoint.

    (a) How well did the feature meet (or fail to meet) its expectations and goals?

    • (a1) Is the feature still available today in one or more widely used langages?

      • (a2) Is the feature still in widespread use today by programmers? If not, was the feature eventually superseded by yet another idea, or was it simply abandoned?
    • (a3) If the feature failed, why did it fail?

    (b) How did specific implementations affect its acceptance?

    (c) How was the feature received by those affected by it (e.g., programmers, problem solvers, documenters, managers)?

    (d) What were the biggest problems that arose during the design or creation of the feature? How were they addressed? Did these problems affect the end result significantly?

    (e) What were the biggest problems that arose during further evolution of the feature? How were they addressed?

    (f) If languages have differed in how they incorporate the feature, have such differences caused any problems for users? If so, have these problems been addressed? In what manner? Has addressing these problems resulted in further changes to the feature?

    (g) What are the biggest problems the users have had in understanding or using the feature? Does using the feature well require a significant amount of education, training, or experience?

    (h) What are the biggest problems the implementors have had? Were these deliberate, in the sense that a conscious decision was made to implement the feature “elegantly” or “completely”, even if it made the implementation more difficult?

    (i) Conversely, was a conscious decision made to implement the feature in “quick and dirty” manner or “incompletely”, in order to avoid certain implementation difficulties? Has this decision been made the same way in all languages that embody the feature, or have languages differed in how completely they implement the feature? Has the answer to this question changed over time?

    (j) What are the biggest problems the documenters of the feature have had? Would the language have been easier to document or to explain to users if the feature had been designed differently?

    (k) What other trade-offs were made during the feature design and implementation process? Were they conscious or unconscious?

    (l) What compromises were made to meet other constraints such as time, budget, user demands, political, or other factors?

    (m) If there are competing or complementary features or concepts that conflicted with this one:

    • (m1) Has the feature effectively displaced or even rendered obsolete some other feature?
      • (m2) Does the feature now coexist in the same language(s) with some competing or alternative feature? If so, in which situations may its use be considered preferable, and in which situations might an alternative be preferred?

      • (m3) Does the feature now exist in a language that competes with other languages that do not have the feature? If so, in which situations may the availability of the feature make use of its language preferable, and in which situations might an alternative language be preferred?

    (n) What other features or concepts were influenced by this one? Were other features or concepts later created specifically to complement, build on, or supersede this one?

    (o) How did this feature contribute to software methodology?

To be provided soon