Programming language design and implementation

For the conference, see Programming Language Design and Implementation.

Programming languages are typically created by designing a form of representation of a computer program, and writing an implementation for the developed concept, ^[1] usually an interpreter or compiler. Interpreters are designed to read programs, usually in some variation of a text format, and perform actions based on what it reads, whereas compilers convert code to a lower level form, such as object code. ^[2]

Design

In programming language design, there are a wide variety of factors to consider. Some factors may be mutually exclusive (e.g. security versus speed). It may be necessary to consider whether a programming language will perform better interpreted, or compiled, if a language should be dynamically or statically typed, if inheritance will be in, and the general syntax of the language. ^[3] Many factors involved with the design of a language can be decided on by the goals behind the language. It's important to consider the target audience of a language, its unique features and its purpose. ^[4] It is good practice to look at what existing languages lack, or make difficult, to make sure a language serves a purpose. ^[4]

Various experts have suggested useful design principles:

• As the last paragraph of an article published in 1972, Tony Hoare has provided some general advice for any software project: ^[5]

  "So my advice to the designers and implementer of software of the future is in a nutshell: do not decide exactly what you are going to do until you know how to do it; and do not decide how to do it until you have evaluated your plan against all the desired criteria of quality. And if you cannot do that, simplify your design until you can."

• At a SIGPLAN symposium in 1973, Tony Hoare discussed various language aspects in some detail. ^[6] He also identifies a number of shortcomings in (then) current programming languages.

  "a programming language is a tool which should assist the programmer in the most difficult aspects of his art, namely program design, documentation, and debugging."

  "objective criteria for good language design may be summarized in five catch phrases: simplicity, security, fast translation, efficient object code, and readability."

  "It is absurd to make elaborate security checks on debugging runs, when no trust is put in the results, and then remove them in production runs, when an erroneous result could be expensive or disastrous. What would we think of a sailing enthusiast who wears his life-jacket when training on dry land but takes it off as soon as he goes to sea?"

• At IFIP Congress 1974, Niklaus Wirth, designer of Pascal, presented a paper "On the design of programming languages". ^[7] Wirth listed a number of competing suggestions, most notably that a language should be easy to learn and use, it should be usable without new features being added, the compiler should generate efficient code, a compiler should be fast, and that a language should be compatible with libraries, the system it is running on, and programs written in other languages.

Many programming languages have design features intended to make it easier to implement at least the first initial version of the compiler or interpreter. For example, Pascal, Forth, and many assembly languages are specifically designed to support one-pass compilation.

Often new programming languages are designed to fix (perceived) problems with earlier programming languages, typically by adding features that (while they may make the interpreter or compiler more complicated) make programs written in those languages simpler. For example, languages with built-in automatic memory management and garbage collection; languages with built-in associative arrays; etc.

On the other hand, a few programming languages were specifically designed to make it relatively easy to write a self-hosting compiler, typically by deliberately leaving out features that make compilation difficult, such as BCPL, Pascal, and RPython.

Implementation

Main article: Programming language implementation

Both interpreters and compilers usually implement some sort of symbol table.

Interpreters

Main article: Interpreter (computing)

An interpreter is a program that reads another program, typically as text, ^[4] as seen in languages like Python. ^[2] Interpreters read code, and produce the result directly. ^[8] Interpreters typically read code line by line, and parse it to convert and execute the code as operations and actions. ^[9]

Compilers

Main article: Compiler

Compilers are programs that read programs, also usually as some form of text, and converts the code into lower level machine code or operations. ^[4] Compiled formats generated by compilers store the lower level actions as a file. ^[2] Compiled languages converted to machine code, tend to be a lot faster, as lower level operations are easier to run, and outcomes can be predicted and compiled ahead of time. ^[9]

Process

Processes of making a programming language may differ from developer to developer; however, here is a general process of how one might create a programming language, which includes common concepts:

• Design: Design aspects are considered, such as types, syntax, semantics, and library usage to develop a language. ^[10]
• Consideration: Syntax, implementation, and other factors are considered. Languages like Python interpret code at runtime, whereas languages like C++ follow an approach of basing its compiler off of C's compiler. ^[11]
• Create an implementation: A first implementation is written. Compilers will convert to other formats, usually ending up as low-level as assembly, even down to binary. ^[12]
• Improve your implementation: Implementations should be improved upon. Expand the programming language, aiming for it to have enough functionality to bootstrap, where a programming language is capable of writing an implementation of itself.
• Bootstrapping: If using a compiler, a developer may use the process of bootstrapping, where a compiler for a programming language is rewritten in itself. ^[13] This is good for bug checking, and proving its capability. ^[14] Bootstrapping also comes with the benefit of only needing to program the language in itself from there-on.

References

1. Tomassetti, Federico (8 May 2019). "How would I go about creating a programming language?". Strumenta. Retrieved 3 March 2023.
2. "Compiler vs Interpreter". Geeks For Geeks. 17 January 2022. Retrieved 3 March 2023.
3. "Programming Languages and Learning". Washington EDU. University of Washington. Retrieved 2 March 2023.
4. "How are Programming Languages created". GoNoCode. 8 December 2021. Retrieved 2 March 2023.
5. Hoare, C. A. R. (1972). "The Quality of Software". Software: Practice and Experience. 2 (2): 103–105. doi: 10.1002/spe.4380020202 . S2CID   62662609.
6. "Hints on Programming Language Design" (PDF). 1973. Retrieved 7 March 2023.
7. "On the design of programming languages" (PDF). 1974. Retrieved 9 March 2023.
8. Diver, Laurence (7 December 2021). "Published on Dec 07, 2021 Interpreting the Rule(s) of Code: Performance, Performativity, and Production". MIT Computational Law Report.
9. Rathi, Mukul (31 March 2017). "How I wrote my own "proper" programming language". mukulrathi. Retrieved 2 March 2023.
10. Chouchanian, Vic. "Programming Languages". California State University Northridge. Retrieved 2 March 2023.
11. Stroustrup, Bjarne. "A History of C ++ : 1979− 1991" (PDF). Archived (PDF) from the original on 2 February 2019. Retrieved 18 July 2013.
12. Ferguson, Andrew. "A History of Computer Programming Languages". Brown University. Retrieved 2 March 2023.
13. Glück, Robert (2012). "Bootstrapping compiler generators from partial evaluators". In Clarke, Edmund; Virbitskaite, Irina; Voronkov, Andrei (eds.). Perspectives of Systems Informatics: 8th International Andrei Ershov Memorial Conference, PSI 2011, Novosibirsk, Russia, June 27 – July 1, 2011, Revised Selected Papers. Lecture Notes in Computer Science. Vol. 7162. Springer. pp. 125–141. doi:10.1007/978-3-642-29709-0_13. Getting started presents the chicken-and-egg problem familiar from compiler construction: one needs a compiler to bootstrap a compiler, and bootstrapping compiler generators is no exception.
14. "Installing GCC: Building". GNU Project - Free Software Foundation (FSF).