Final Paper: Does Computer Programming Shape Thought?

“Theory is when you know something, but it doesn't work. Practice is when something works, but you don't know why. Programmers combine theory and practice: Nothing works and they don't know why. “ - Anonymous

Of the twenty richest individuals in the world, five of them have made their money in the computer industry (Forbes 1). Today’s up and coming business leaders, such as Larry Paige and Sergey Brin, come from a new breed of entrepreneurs that focus on online opportunities. Since Google’s start nearly ten years ago, both Mr. Paige and Mr. Brin, transformed from Stanford Graduate students with little money to their name into two of the most influential businessmen with an assessed value of $20 billion each (Forbes 2, Forbes 3). It is also worth noting that five of the ten fastest growing careers are computer related (Career One Stop). Overall, it is easy to see that computer skills are becoming a necessary requirement for success in today’s transforming economy.

Of the skills most sought out, two of the five fastest growing careers relate specifically to computer programming (Career One Stop). The number of programmers has been increasing exponentially, with only 100 existing in 1950 and growing to a number 10,000,000 by the year 2000 (McConnell). This rapid rise in importance of a specific skill set has many widespread and not very well understood implications on society. In the realm of psychology, many questions begin to pop up. How does programming influence a person’s behavior, or more specifically, thought processes? Because programming languages are developed to serve special purposes, do programmers think differently when programming? More specifically, do they think differently when programming in different languages?

Experiment

“There are 10 kinds of people in this world....Those who understand binary and those who don't.” - Anonymous

Participants

Ten participants from the Stanford community performed the experiment voluntarily. All of the participants gave informed consent. Five of the individuals could program only in Java, three had programming experience in Javascript, and the final two had programming experience in both.

Materials

A pencil and a sheet of paper with a prompt such as “Starting from a blank text editor, how would you print the numbers 1-10 on a screen in the [java/javascript] language?” was given to each individual, with the programming language reflecting their personal experience. If they knew both, they were asked to provide an example in both languages.

Procedure

Each participant was given five minutes to perform the task. They were isolated in a room and did not have access to outside resources. After the individual had completed the task of writing their procedure on paper and the paper was ensured to have a relevant answer, the participant was free to leave.

Results

Results of the test showed that individuals who programmed exclusively in Java provided an answer similar to the following. Areas that differed slightly are presented in brackets - [] .

class [example] {
public static void main(String[] args){
for(int [i]=1; [i]<11; type="text/javascript">
for ([x]=1; [x]<=11;[x]++) { document.write("[The number is ]" + [x]); }

Results from the javascript programmers varied more significantly, with two of the programmers producing the following (variations in brackets and script tags removed because of browser issues):

for ([x]=1; [x]<=11;[x]++) { document.write("[The number is ]" + [x]); }

The other javascript programmer produced the following:

function printNumbers()
{
var i=1;
for (i=1;i<=11;i++) { document.write("The number is " + i); document.write(" "); } }

The final two programmers produced essentially the same thing in java as the java-only programmers, while both created code very similar to the second example of javascript.
Overall, although there were slight variations with every test subject, the code that was most in common fundamentally was reproduced above, with the irrelevant aspects (such as function name) neglected from analysis.

Analysis

“Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.” - Donald Knuth

Why Java and Javascript?

Java is an object-oriented, strict programming language. What this means is that when programming in this language, it has to be in function format, with the code following a very specific and predictable path - namely by creating a class and telling what needs to be done within that class. Javascript, on the other hand, is a loose programming language that can be written with an object-oriented approach, but doesn’t have to be (as seen by the two examples above.) These languages were chosen specifically for these reasons, and they provide a simple, but effective example of how programming in specific languages influences thought.

Analyzing the Results

Understanding the fundamental differences between coding in javascript and java highlights how these languages shape the way we think. Because we are forced to think in one specific way in java when programming the scenario tested, there isn’t much variation in terms of how ideas or tasks are accomplished. Although there aren’t differences at this level of programming, don’t mistake the fact that when programs become more complicated, there is much more creativity and ways of accomplishing the task. Javascript, on the other hand, because it was designed with more flexibility in mind, programmers can express more individual judgement in creating a program. This is important because there are times in which it isn’t necessary or important to code with reusability in mind (which is the reasoning of creating functions.) If a piece of code is to be used only once, it is a waste of time, resources, computing power, and unnecessarily complicates the design process.

Programming Languages Shape Thought

This relates to language and thought through an analysis of verbs and their usage in different languages. On a conceptual level, both English and Indonesian utilize verbs to express action. One difference of expression is that English uses time to change verbs - will pass, is passing, has passed. If an English speaker were to use pass instead of using the time-sensitive form of the verb, many speakers would then ask, “When did this happen?” In programming terms, the lack of a time reference in English results in a “parsing error.”

In Indonesian, on the other hand, it is much like javascript in the respect that time does not have to be indicated with the verb. There are modifiers that can be applied, but it is not necessary. If it is irrelevant to say that you are drinking, drank, or will drink a soda, then you don’t have to specify it in Indonesian (Boroditsky). As a result, English speakers have to be more consciously aware of and focus on when something happens, and their thought processes become more attuned to the “when” of situations.

Conclusion

“The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.” -Tom Cargill

Next Steps

Through the simple test and example highlighted above, it is empirically proven that programming languages shape thought much like natural language shapes thought. The next step is to analyze to what extent programming languages shape thought. There have been several theories that propose how programming in general shapes thought, and one example in particular says that it produces seven fundamental changes in thought:

1. rigorous thinking, precise expression, recognized need to make assumptions
   explicit...;
2. understanding of general concepts such as formal procedure, variable, function, and transformation since these are used in programming;
3. greater facility with the art of "heuristics'', explicit approaches to problems useful for solving problems in any domain, such as planning, finding a related problem, solving the problem by decomposing it into parts, etc...;
4. the general idea that "debugging" of errors is a "constructive and plannable
   activity" applicable to any kind of problem solving...;
5. the general idea that one can invent small procedures as building blocks for
   gradually constructing solutions to large problems...;
6. generally enhanced self-consciousness and literacy about the process of solving problems...;
7. enhanced recognition for domains beyond programming that there is rarely a single "best'' way to do something, but different ways that have comparative costs and benefits with respect to specific goals (Pea & Kurkland 1984).

Through the development of several tests, each of these changes could be analyzed individually. There are several complications that come up when trying to analyze these questions, though. Finding qualitative measures and developing the ideal environment, for example, are two common issues to overcome. One test that could potentially be run for “change 3” is to take two groups of very similar students at Stanford University, for example, with the key similar factor of not knowing how any programming language, and run a test on their problem solving skills at the beginning of the school year. Have one group of the students learn how to program and develop a certain level proficiency, and prevent the second group from learning how to program. After said proficiency develops, introduce a similar test to the one provided in the beginning and compare the results between the groups.

Contrary Example

A similar test as the one presented above was performed with the results indicating that “the Logo programming experiences had no significant effect on planning performances, on any of the plan efficiency or planning measures” (Pea & Kurland, 1983). The primary problem with this test is that it didn’t look for and develop a specific programming proficiency with the test subjects. They were given a specific time frame to develop the skills, but given more time to interact with a computer does not guarantee an individual will become a more proficient programmer. If students were to focus more on learning “low level [programming] form such as grammar, semantic rules, and some pre-established algorithms for solving classes of problems” (Pea & Kurland, 1984), they wouldn’t learn the skills that allow for more effective problem solving. Testing for specific proficiencies in programming would rectify this issue.

Final Thoughts

While there are several directions and tests that can be developed from this study, there are many key assumptions that have to be isolated and understood before we proceed. Although the contrary example above seemed to prove that learning programming skills does not shape problem solving capabilities, we still need to look for and remove potential issues that create a level of vagueness and guesswork in the testing methods in order to provide accurate results that accurately assess the hypothesis. Because we judge a writer’s proficiency by the core skills they understand and utilize rather than the amount of time they have invested into writing, we should exact the same standard when testing programmers.

Even though computer programmers are in high demand in the business world, we still have a long way to go in understanding how this recently acquired skill set influences our thought processes. The individuals learning these skill sets are obviously doing something right as their reflection in society suggests, and in contrast to the initial quotation, people like Larry Page and Sergey Brin combine theory and practice in such a way that they know what works and why.Sources

Works Cited

Forbes 1 Online

Forbes 2 Online

Forbes 3 Online

Career One Stop Online

McConnell, Steve. Online

Boroditsky, Lera. In class discussion. December 6, 2007.

Pea, Roy and Kurland, Midian. “ON THE COGNITIVE EFFECTS OF LEARNING COMPUTER PROGRAMMING.” New Ideas Psycholgy. Vol. 2 (1984).

Pea R. D. Programming and problem solving Children s experience with Logo. Paper presented at Annual Meetings of the American Educational Research Association, Montreal, Canada, April 1983.