Typewritten Code

Today, the dominating standard form for computer programming languages is ASCII text (Stack Overflow, 2021). I will refer to it as typewritten code (Arawjo, Ian, 2020 p. 6). This ubiquitous notation restricts innovation in the field of programming language design (Iverson, Kenneth E., 1980 § 5.4). It also presents additional barriers to non-native English speakers due to the use of English-based identifiers (e.g. for variables and functions) (Guo, Philip J., 2018 p. 2).

In his retrospective analysis of early ‘visions’ of programming notation, Arawjo, Ian (2020) describes how FORTRAN, one of the earliest foundational programming languages, developed. He says that it wasn’t ‘inevitable’; instead, it was the product of “incremental improvements to [the programmers’] interactions with computers”, within the constraints of the typewriter keyboards the designers used (Arawjo, Ian, 2020 p. 8).

The virtually universal adoption of typewritten code ensures that it will remain dominant indefinitely. Legacy code maintenance keeps the same languages in use years after they would have otherwise lost relevance (Fleishman, G., 2018). Additionally, even when developing new programs, programmers are almost certain to rely on software libraries created in a typewritten language; although it is possible to make procedure calls between languages, doing so requires some commonality of form to construct argument lists and make said calls.

Beyond the code itself, many of the common software tools used in aid of software development work almost exclusively with typewritten text; code editors and version control systems (Git) are among the most notable of these.

On top of all this, there is the community of programmers who have worked with typewritten code for years or even decades, gaining irreplacable familiarity with the associated coding environment.

Ken Iverson warned of an ‘unfortunate circularity of design’ of programming languages and hardware, where early preoccupations with efficient performance informed the design of early programming languages, which then went on to inform the design of later computers, and so later programming languages (Iverson, Kenneth E., 1980 § 5.4).

In 2022, Python and JavaScript are the most popular programming languages (Stack Overflow, 2021). These indicate that the persistence of typewritten code is no longer based on a continued obsession with performance, since they prioritise ease of use over efficiency. Instead, it is due to the legacy of older languages and programming environments. As a result, I contend that we are ready for a shift towards even more easily-useable notations.

In this essay, I will consider ways for programming methodologies and notations to improve, both to make programming more accessible to non-native English speakers, and to improve their effectiveness as tools of thought and communication.

Despite the fact that Unicode now supports all of the major mathematical symbols that programming notation previously needed to approximate, (≤, ∧, →), all major programming languages remain predominantly stuck with ASCII identifiers and operators (<=, &&, ->) (Stack Overflow, 2021). For older languages, this is unavoidable, due to the need for backwards-compatibility, but even newer languages like Rust retain these conventions.

Code ligatures visually replace some of the more obscure ASCII notations with their Unicode counterparts. One of their primary purposes is to make ASCII-based operators more readable (Fira Code), so there are evidently programmers who desire Unicode operators. Unfortunately, hiding the ASCII operators only increases confusion for the uninitiated.

Modern programming languages such as Python and Haskell allow the creation of Unicode identifiers. The Julia language (Fredrik Ekre and Kristoffer Carlsson and Milan Bouchet-Valat and Michael Hatherly and Alex Arslan and Valentin Churavy and Tim Holy and Sacha Verweij and Morten Piibeleht and Mohit Nain and Kiaran B Dave and Jeff Bezanson and Rafael Fourquet and Chris Foster and Amit Murthy and Chris Rackauckas , 2022) supports both styles, and the APL language (Iverson, Kenneth E., 1980) is predominantly composed of non-ASCII symbols. There is evidently no technical or theoretical barrier to implementing them into languages. Instead, the problem is the practical matter of inputting the characters.

Since old typewriter keyboards only had keys for a tiny number of maths symbols, the designers of early languages had to create the ASCII imitations for the excluded ones (Arawjo, Ian, 2020 p. 6-7). Newer keyboards then only needed to be capable of inputting the same ASCII characters to support the existing languages, perpetuating the prior limitations. This is a case of the ‘unfortunate circularity of design’ referred to by Iverson (see introduction).

The first and most obvious solution is a keyboard which has more symbols on, such as the APL keyboard [image]. This is not a viable approach with respect to maximising adoption, since not all programmers would be willing or able to replace their hardware.

A more plausible alternative would be support within the text editor to input these symbols. For example, the TeX input methods in Emacs (Emacs28, § 22.3) and the Julia REPL (Julia, § Unicode Input) allows the user to input TeX macros, which are then replaced with the corresponding Unicode symbol (e.g. \le → ≤). Unfortunately, any such ‘macro’ system would inevitably add complexity, meaning the additional symbols would still be harder (and crucially slower) to input than ASCII.

Guo, Philip J. (2018) p. 2 discusses how English-based identifiers for logic, functions and variables can present serious obstacles to non-native English speakers. This applies not just to reading other people’s code, but also to creating semantically appropriate names themselves (Guo, Philip J., 2018 p. 6, Chistyakov, Artem, 2017).

One potential solution is simply creating programming languages with identifiers based on natural languages other than English. Whilst programming with one’s native language is naturally easier for learners (Guo, Philip J., 2018 p. 2), I don’t see this as a good solution to the problem of communication between programmers. The issue is that code is inextricably linked to a single language in the first place; English is the standard predominantly for historical reasons.

A more promising approach would be ‘multi-lingual’ programming languages, which could support identifiers in multiple natural languages. \textcite{guo2018} refers to these as ‘bilingual labels’.

The first method was allowing others to create variants of the same language (A. van Wijngaarden and B.J. Mailloux and J.E.L. Peck, C.H.A. Koster and M. Sintzoff, C.H. Lindsey, L.G.T. Meertens and R.G. Fisker, 1973 § 0.1) with non-English identifiers. In this case, there will effectively just be multiple incompatible languages, with the same result as before. This technique, therefore, would be of limited value in aiding communication between programmers with different native tongues.

A more advanced method is block-label localisation in Scratch (Guo, Philip J., 2018 p. 2). The principle is to have an underlying representation for what a given object is, then display the appropriate localised label within the editor. While this does liberate the code somewhat from any given natural language, the method has other problems:

• Every new construct would need localised identifiers in all supported languages, making the process of adding new ones slower.
• There may not be direct 1:1 translations for certain labels (Guo, Philip J., 2018 p. 6).
• In the case of Scratch, user-created identifiers (for lists, variables and custom blocks) are still stuck in one language, ignoring the localisation system entirely.
• This runs counter to the concept of ‘plain’ text, wherein a displayed character or word directly corresponds to the underlying representation. Consequently, it would be challenging to implemented into conventional typewritten languages.

The flaws of these techniques show that multi-lingual programming is not a problem we have a good solution for yet, especially within the domain of typewritten text.

Acknowledging the dominance of the typewritten, we should consider ways to make this family of programming languages more accessible to non-native English speakers. Following the principle of ‘universal design’ (Guo, Philip J., 2018 p. 10), doing so could be beneficial for the programming community at large.

The next logical step after literate programming is heterogeneous programming (Arawjo, Ian, 2020 p. 9). The principle is to use multiple different notations for programming, choosing whichever is most applicable for a given situation. Arawjo gives the example of embedded quantum circuit diagrams within a program which ‘are the code’, coexisting with surrounding typewritten procedure calls.

Scientific research papers could take the form of executable programs (Lasser, J., 2020), with the mathematical equations themselves forming part of the code. Lasser uses Python for its readability, but an executable mathematical notation such as the one in Geogebra would be even more so, even for more complex equations:

def quadratic(a, b, c):
    det = b*b - 4*a*c
    detRootDiv = math.sqrt(det)/(2*a)
    bDiv = -b/(2*a)
        return [bDiv + detRootDiv, bDiv - detRootDiv]

For inter-operation with equations that include non-ASCII symbols, such as \(\lambda\) in radioactive decay, using Unicode identifiers instead of something like lambda would make the meaning clearer.

Typewritten text is deeply entrenched into the practices and culture of programming. In industrial applications, where large teams develop code iteratively over the course of years or decades, it is likely to persist indefinitely. Given all the products this medium has produced, one cannot deny its effectiveness. Instead, a focus on inclusion and accessibility in the field of Computer Science (of which programming is but a small part) should inform our judgements about how we design and implement programs and programming languages.

By shifting the focus of programming from instruction and execution to communication, we can bring an international community of computational thinkers closer together, and create better, more understandable software. In treating programming as a medium of thought, we can consider techniques to make it more expressive, which can grow to gain wider adoption and significance over time.

Arawjo, Ian (2020). To Write Code: The Cultural Fabrication of Programming Notation and Practice, Association for Computing Machinery.

A. van Wijngaarden and B.J. Mailloux and J.E.L. Peck, C.H.A. Koster and M. Sintzoff, C.H. Lindsey, L.G.T. Meertens and R.G. Fisker (1973). Algol 68, ALGOL 68 Revision Committee.

Chistyakov, Artem (2017). The language of programming.

Fleishman, G. (2018). It’s COBOL all the way down.

Fredrik Ekre and Kristoffer Carlsson and Milan Bouchet-Valat and Michael Hatherly and Alex Arslan and Valentin Churavy and Tim Holy and Sacha Verweij and Morten Piibeleht and Mohit Nain and Kiaran B Dave and Jeff Bezanson and Rafael Fourquet and Chris Foster and Amit Murthy and Chris Rackauckas (2022). Julia 1.7 Documentation.

Guo, Philip J. (2018). Non-Native English Speakers Learning Computer Programming: Barriers, Desires, and Design Opportunities, Association for Computing Machinery.

Iverson, Kenneth E. (1980). Notation as a Tool of Thought, Association for Computing Machinery.

Kelly, A. (2019). Error handling omitted for brevity.

Knuth, D. E. (1984). Literate Programming, The Computer Journal.

Lasser, J. (2020). Creating an executable paper is a journey through Open Science, Communications Physics.

Stack Overflow (2021). 2021 Developer Survey.