1.5 Factors Influencing Language Development

Surprisingly enough, programming languages did not historically evolve based on the abilities of programmers (Weinberg 1988). (One could argue that programmers’ abilities evolved based on the capabilities and limitations of programming languages.) Historically, computer architecture influenced programming language design and implementation. Use of the von Neumann architecture inspired the design of many early programming languages that dovetailed with that model. In the von Neumann architecture, a sequence of program instructions and program data are both stored in main memory. Similarly, the languages inspired by this model view variables (in which to store program data) as abstractions of memory cells. Further, in these languages variables are manipulated through a sequence of commands, including an assignment statement that changes the value of a variable.

Fortran is one of oldest programming languages still in use whose design was based on the von Neumann architecture. The primary design goal of Fortran was speed of execution since Fortran programs were intended for scientific and engineering applications and had to execute fast. Moreover, the emphasis on planning programs in advance advocated by software design methodologies (e.g., structured programming or top-down design) resulting from the software crisis¹⁹ in the 1960s and 1970s promoted the use of static bindings, which then reinforces the use of compiled languages. The need to produce programs that executed fast helped fuel the development of compiled languages such as Fortran, COBOL, and C. Compiled languages with static bindings and top-down design reinforce each other.

Often while developing software we build throwaway prototypes solely for purposes of helping us collect, crystallize, and analyze software requirements, candidate designs, and implementation approaches. It is widely believed that writing generates and clarifies thoughts (Graham 1993, p. 2). For instance, the process of enumerating a list of groceries typically leads to thoughts of additional items that need to be purchased, which are then listed, and so on. An alternative to structured programming is literate programming, a notion introduced by Donald Knuth. Literate programming involves crafting a program as a representation of one’s thoughts in natural language rather than based on constraints imposed by computer architecture and, therefore, programming languages.²⁰ Moreover, in the 1980s the discussion around the ideas of object-oriented design emerged through the development of Smalltalk—an interpreted language. Advances in computer hardware, and particularly Moore’s Law,²¹ also helped reduce the emphasis on speed of program execution as the overriding criterion in the design of programming languages.

While fewer interpreted languages emerged in the 1980s compared to compiled ones, the confluence of literate programming, object-oriented design, and Moore’s Law sparked discussion of speed of development as a criterion for designing programming languages.

The advent of the World Wide Web in the late 1990s and early 2000s and the new interactive and networked computing platform on which it runs certainly influenced language design. Language designers had to address the challenges of developing software that was intended to run on a variety of hardware platforms and was to be delivered or interacted with over a network. Moreover, they had to deal with issues of maintaining state—so fundamental to imperative programming—over a stateless (http) network protocol. For all these reasons, programming for the web presented a fertile landscape for the practical exploration of issues of language design. Programming languages tended toward the inclusion of more dynamic bindings, so more interpreted languages emerged at this time (e.g., JavaScript).

On the one hand, the need to develop applications with ever-evolving requirements rapidly has attracted attention to the speed of development as a more prominent criterion in the design of programming languages and has continued to nourish the development of languages adopting more dynamic bindings (e.g., Python). The ability, or lack thereof, to delay bindings until runtime affects flexibility of program development. The more dynamic bindings a language supports, the fewer the number of commitments the programmer must make during program development. Thus, dynamic bindings provide for convenient debugging, maintenance, and redesign when dealing with errors or evolving program requirements. For instance, run-time binding of messages to methods in Python allows programs to be more easily designed during their initial development and then subsequently extended during their maintenance.

Graham (2004b) describes this process with a metaphor—namely, an oil painting where the painter can smudge the oil to correct any initial flaws. Thus, programming languages that support dynamic bindings are the oil that can reduce the cost of mistakes. There has been an incremental and ongoing shift toward support for more dynamic bindings in programming languages to enable the creation of malleable programs.

On the other hand, static type systems support program evolution by automatically identifying the parts of a program affected by a change in a data structure, for example (Wright 2010). Moreover, program safety and security are new applications of static bindings in languages (e.g., development of TypeScript as JavaScript with a safe type system). Figure 1.4 depicts the (historical) development of contemporary languages with dynamic bindings and languages with static bindings—both supporting multiple styles of programming. Languages reconciling the need for both safety and flexibility are also starting to emerge (e.g., Hack and Dart). Figure 1.5 summarizes the factors influencing language design discussed here.

With the computing power available today and the time-to-market demands placed on software development, speed of execution is now less emphasized as a design criterion than it once was.²² Software development process methodologies have commensurately evolved in this direction as well and embrace this trend. Agile methods such as extreme programming involve repeated and rapid tours through the software development cycle, implying that speed of development is highly valued.

19. The software crisis in the 1960s and 1970s refers to the software industry’s inability to scale the software development process of large systems in the same way as other engineering disciplines.

20. While a novel concept, embraced by tools (e.g., Noweb) and languages (e.g., the proprietary language Miranda, which is a predecessor of Haskell and similarly supports a pure form of functional programming), the idea of literate programming never fully caught on.

21. Moore’s Law states that the number of transistors that can be placed inexpensively on an integrated circuit doubles approximately every two years and describes the evolution of computer hardware.

22. In some engineering applications, speed of execution is still the overriding design criterion.