This essay explores the role of programming languages in shaping our thoughts and worldviews, similar to the position adopted by the Sapir-Whorf hypothesis towards human language. The first part of this essay adopts a historical perspective, by tracking the developments and advancements made in programming languages in order to elucidate the mechanisms by which programming languages shape our reality. Subsequently, we will be looking at how programming languages shape our reality on a day-to-day basis. Thus, we will be discussing whether (and how) programming languages frame our problem-solving capabilities and how object-orientation infiltrate reality in structuring modern work teams.
Introduction
According to the Sapir-Whorf hypothesis, language influences thought and perception and consequently, speakers of different languages think and perceive reality in different ways and each language has its own worldview. (Hussein, 2012) While there is much research in the fields of linguistic relativity and determinism, there is little work on the role of programming languages in influencing human thought and perception. Would Whorf agree to extend the theory of linguistic relativity to the realm of programming languages?
In this essay, I discuss the role of programming languages in shaping the way we understand reality. I assert that thought, of programmers and non-programmers alike, is shaped by programming languages. This is a position similar to that adopted by linguistic relativists towards the role of language on the worldview and cognition of speakers (Boroditsky, 2003). In exploring this position, I will be adopting the Foucauldian approach of examining historical development and discourse over time (Grbich, 2007). Following a look at the history of computer programming languages, this essay will then bring the focus back to the role of programming languages in present day reality that we experience. The analyses reinforce my central argument that the reality which we experience is influenced by concepts present in programming languages, and power structures underlying reality in turn play a crucial role in determining the future direction of and developments in programming languages.
Programming languages is a broad term and can be taken to mean different things to people of different levels of knowledge and expertise. To a layman, the term may be taken to mean a symbol system which allows humans to write programs that “speak” to computers. On the other hand, programmers may choose to distinguish low-level programming languages from their high-level counterparts, recognising that the two groups of languages share similarities as much as differences in terms of syntax and semantics. In this essay, programming languages will refer to the means of instructing computers to perform a specific task (Ferguson, 2000).
Impact on international relations
To begin, we will first take a historical look at how programming languages contributed to the paradigmatic shift from physical labour to electrical replacements. In 1822, Charles Babbage conceptualised and constructed the first mechanical computer, the difference engine, and proposed that it be used for computation of astronomical and mathematical tables (O’Connor & Robertson, 1998). The difference engine executed calculations when its gears were changed, and thus, physical motion, the act of changing gears, can be considered the earliest form of computer or programming languages. Subsequently, the demand for improved speed and accuracy in computing ballistic firing tables led to the innovation of the Electronic and Numerical Integrator And Computer (ENIAC) in 1945. Physical motion as the first programming language was displaced by electrical signals, and this shift share several parallels as the second Industrial Revolution.
According to Mokyr (1998), during the second Industrial Revolution:
The consequence of changing production technology was the rise of technological systems… These [railroad and telegraph networks] systems expanded enormously after 1870, and a number of new ones were added: electrical power and telephone being the most important ones. The second Industrial Revolution turned the large technological system from an exception to a commonplace.
Babbage’s invention of the difference engine coincided with the first Industrial Revolution, which saw the rise of new manufacturing processes while the creation of ENIAC happened shortly after the second Industrial Revolution, which saw the pivotal discoveries in electricity and thus made electrical signals the next programming language. The fact that ENIAC was able to achieve unprecedented computational power and speed, as well as general-purpose programmability, contributed to the advancements that proponents of the second Industrial Revolution fought for: electricity and electric power. I assert that the success of ENIAC brought about greater acceptance towards the ideology behind the second Industrial Revolution and thus, enabled the proliferation of manufacturing processes powered by electricity over their predecessors that ran on physical labour.
Secondly, advancements made in developing new programming languages with greater computational power further consolidated the United States’ military prowess and cemented the worldview that the United States remains as the leading global military superpower. As mentioned previously, ENIAC’s development and creation was initially driven by the need for efficient and accurate computation of ballistic firing tables for the United States military during World War II. According to Moye (1996):
[ENIAC’s] impact on the generation of firing tables was obvious. A skilled person with a desk calculator could compute 60 second trajectory in about 20 hours; the Bush differential analyzer produced the same result in 15 minute; but the ENIAC required only 30 seconds, less than the flight time.
ENIAC’s test runs also consisted of computations for the hydrogen bomb (Randall, 2006), which was developed in response to the Soviet’s atomic bomb success. The computational prowess of ENIAC served not only as a display of the United States’ military power as part of the Cold War agenda, but perhaps also served to aid the United States in deterring nations from starting another world war. All in all, developments in powerful programming languages, such that that which drives ENIAC’s execution, have a profound effect on international relations. These developments consolidated United States’ dominant military position at the time and maintained international order by deterring war.
The way we position the United States on the world map as a military superpower is hence partly shaped by programming languages: because of advancements in the area of programming languages and the computational power that these advancements bring about, we are conditioned to believe that we are indeed under American hegemony. This position bears similarities to, according to Croucher (2015):
… a revisionist argument that the real purpose of the [atomic] bombings was not to induce a Japanese surrender, which was already imminent, but as a show of strength to intimidate the Soviet Union at the dawn of the Cold War.
However, it is also worth noting that not only is our perception of reality, that being United States’ dominance, shaped by developments in programming languages, such developments are in fact propelled by national security and military objectives, and so are reflections of existing power structures. For instance, the United States will strive to remain at the forefront of computer languages and emerging technologies and retain its position as the world’s strongest superpower.
Computing technology as niche to ubiquitous
Developments in programming languages set the stage for a paradigm shift, from viewing computing technology as niche to viewing it as ubiquitous. Grace Hopper wrote the first compiler, A-0, in 1951 because she believed that programs should be written in a language as close to English as possible, as opposed to machine code or assembly languages (Williams, 2015). Hopper’s works paved the way for programming languages to evolve to become human-readable. Betts (1992):
… Hopper developed the Flow-Matic programming language in 1957 for business data processing applications on the classic Univac line of computers from what was then Sperry Corp. Flow-Matic was notable because it used English-like instructions and was the main precursor of Cobol, the most widely used business programming language today.
Hopper’s vision was to revolutionise programming languages. Her works focused on moving code beyond a form to executable language, to a type of text that does what it says. In other words, code’s goal is no longer only to be executed by a machine, but now, it is also to be understood by humans, be it programmers who wrote the code itself or non-programmers seeking to understand the underlying code behind the systems they use.
Hopper recognised that “the major obstacle to computers in non-scientific and business applications was the dearth of programmers for these far from user-friendly new machines” (“Grace Murray Hopper”, 1994). This became the impetus for her works which aimed to fine-tune programming languages and allow them to be comprehensible and usable by non-programmers. Common Business Oriented Language (COBOL) was one of the earliest high-level programming languages (Li & Abraham, 2002) and based on Hopper’s programming language design work. The application of programming to business context is unprecedented because computer programs were traditionally niche, limited to the area of (mathematical) computations. In addition, it was not always a given that programs are usable by non-expert user groups like business people. Today, we interact with computer programs in the form of smartphone applications, computer games and so on, on a daily basis.
In retrospect, our understanding of the role of computer programs are shaped by historical developments in compilers and programming languages. Developments in high-level programming languages which make them easier to learn and more usable inevitably results in a rise in the number of programmers such that today, even a layman can pick up programming as a hobby. Our worldview of computer programs being ubiquitous, present in all areas of life from business to entertainment to healthcare, signifies a paradigm shift from an earlier worldview that computer programs and programming are niche, specialised and limited in applicability.
Do programming languages constrain our thoughts and worldviews?
Programming languages as we understand them today vary drastically from what they used to be in the difference engine or ENIAC days. Back then, a programming language’s sole purpose was to instruct a computer to execute tasks. Yet today, we have the luxury of creating obfuscated code recreationally, and “explore and exploit the play that is possible in programming language design” (Mateas, 2008). It seems that the scope of problems that are solvable by computer systems has grown exponentially with advancements made in programming languages and technology. However, is the potential of programming truly limitless? I posit that it is precisely programming languages, the set of rules governing syntax and semantics, that imposes a limit on what is imaginable or thinkable in the realm of programming. In this manner, programming languages inevitably shape our thoughts with regards to the extent that technology can solve our problems, both presently and in the future.
Wittgenstein (1922) famously proposed the idea that “the limits of my language mean the limits of my world”. This statement appears to confirm the assumption made by Mateas (2008) in his definition of esoteric programming languages: “they are intended to test the boundaries of programming language design itself”, which assumes that using (standard programming) languages, there exists a limit to what can possibly be expressed.
Programming languages impose a limit on the imaginable and thinkable, and thus places a limit on what problems we deem as solvable by computer systems, or in Turing’s terms, computable. This idea is acknowledged by Petre (1990),
Indeed, many of the arguments of modern designers are based on a conviction that programming languages guide the programmer’s thinking. Associated with this conviction is a certain amount of evangelism about how programmers should think.
Based on this quote, there are two things we can focus on: one, programming languages frame the programmer’s thought and problem-solving process, and two, the underlying assumption of the first assertion that there exist a yardstick that measures superior thinking in programming. The first part trivially supports my proposition that programming languages shape the thoughts of programmers. The second part, however, alludes to a yardstick, and I posit that such expectations are limited by what is imaginable, or thinkable, within the finite concepts and categories that the existing worldview provides. Here I appeal to schema theories, and since we are interested in the effect of schema on cognition, we will look to a psychology definition of schema. Piaget (1952) defined a schema as “a cohesive, repeatable action sequence possessing component actions that are tightly interconnected and governed by a core meaning”.
Ormerod (1990) uses an example to illustrate how a programmer evokes schema in solving a programming problem:
“If a programmer is required to think of an alternative to iteration for dealing with lists, the words ‘iteration’ and ‘lists’ will activate the schema ‘programming languages’. This will allow the programmer to access knowledge about looping constructs, and thus generate alternatives such as ‘recursion’.”
The above example support two assertions. Firstly, the problem-solving process is both guided and limited by the application of prior knowledge. (Ormerod, 1990) Imagine if there were no existing programming languages that support recursion, or if the programmer is working with a programming language that supports other looping constructs (currently unbeknown to us) more efficiently than recursion. In these two thought experiments, the resulting solutions that the programmer derives are vastly different than if he subscribes to the standard, existing programming paradigm and possess knowledge of today’s most commonly used programming languages. Secondly, schemas contain relatively abstract knowledge which is independent of any one event. (Ormerod, 1990) This means that schemas are invoked involuntarily and across all events. It follows that during the problem-solving process, we are unable to escape our schemas and so, unable to conceptualise beyond what our existing constructs render imaginable or thinkable. In the realm of computer programming, these constructs refer to programming languages.
Mateas (2008) writes that:
Universality in a programming language is obviously a desired trait, as it means that the language places no limits on the processes that can be specified in the language.
Prima facie, Mateas refers to the goal of programming language designers of creating universal computational system. Yet Turing himself would agree that there are only countably many computable functions, and most functions are non-computable. This leads us to conclude that programming languages cannot achieve universality. It then follows that our process of solving problems using programming cannot achieve “universality” either; in other words, we are unable to consider the entirety of the infinite solution space, because what our finite minds can conceive is still governed by schemas derived from programming languages.
In his work, Ormerod (1990) describes programming as a problem-solving skill:
Problems are often described as having a ‘state space’, which consists of all the features of a problem, and all the possible moves that may be made between initial and goal states.
Inherent characteristics of programming languages, such as data structures and looping constructs, determine the set of all “possible moves” in problem-solving using programming. This further corroborates my point that thought, specifically the approach to problem-solving using programming, is indeed shaped by programming languages and what we know about them.
Object-oriented programming penetrates reality
In the final portion of this essay, I will be focusing on the topic of object-oriented programming (OOP), which is a programming model organised around objects rather than actions, and data rather than logic (Rouse, 2008). I assert that concepts within the OOP paradigm has penetrated real-life and can be observed in modern work spaces, such as programming or software engineering teams.
In this work on word-processing programs, Fuller (2003) draws our attention to the object-oriented nature of Microsoft Word. He goes on to claim that not only is Microsoft Word an object-oriented software, even Microsoft’s work team that is behind the software displays “object-oriented qualities”:
The productive part of the company is structured into work teams with closely defined domains of expertise and function responsible for each class of object – for instance, each toolbar.
I assert that decentralised work teams draw inspiration from concepts of classes from the OOP paradigm. Curtis and Walz (1990) describes Weinberg’s (1971) egoless team as a common structure for teams of programmers:
In Weinberg’s egoless team no central authority is posited in any team member. Different members take leadership responsibility for those project tasks that match their unique skills. The communication network in this team structure is decentralised, with technical information flowing freely among all team members.
The egoless team shares similarities to object-oriented concepts as well as Microsoft’s work team as described by Fuller. For example, splitting of a project into tasks and decentralising responsibility resembles the splitting of functionalities into logical units and translating them into classes of objects; having a free flow of information among team members resembles how objects call methods and pass messages between one another. Fuller (2003) sums up the similarities between OOP and work teams elegantly:
Object Orientation as a method therefore passes over into the structure of working practices, with each programmer having an equivalently limited position.
Conclusion
Going back to our original definition of programming languages as the means of instructing computers to perform a specific task and programming as “a procedure specification task by means of a computer language” (Hoc & Nguyen-Xuan, 1990), we examined the developments in programming languages and by extension, programming, over the past two centuries since Babbage’s difference engine. There are strong evidences to suggest that firstly, programming languages contributed to the paradigmatic shift from physical labour to electrical replacements, and secondly, developments in programming languages set the stage for a paradigm shift, from viewing computing technology as niche to viewing it as ubiquitous. Following the historical perspective, we adopted a present-day view of programming languages and technology. We observe that programming languages shape our problem-solving schema, and so influence our representations, problem space and goal structures of problems. In addition, we also find that concepts within the OOP paradigm has penetrated real-life and can be observed in modern work spaces, as in the case of Microsoft. This allows us to conclude that programming languages play a significant role in shaping, or at least influencing, our thoughts, perceptions and worldviews.