If you have been following my posts and talks the last few months, you will have seen “programming is writing” in some places already (for example in this post or this video) In these posts I argue that the process of programming is like the process of writing. In both you create something from a high level idea, using words and sentences.
This has lead us to ask the question whether we can learn something from how we teach children reading and writing, to improve how we teach programming. In this post I describe our latest paper on code phonology, or the study of reading code aloud.
Reading language aloud
When children learn to read, they almost invariably start with oral reading: reading the words and sentences out loud, not just to demonstrate their newly acquired skill, but also because they simply cannot do it in a different fashion yet. Most children take years to learn to read silently, during which they go through a number of phases including whispering and lip movement. Several studies have shown that, for novice readers, reading aloud supports comprehension. This should not come as a surprise, sometimes when reading difficult English words, I still read aloud!
While we do not know exactly how reading aloud helps, the fact that is does it often attributed to the fact that reading aloud focuses the your attention to the text, and thus makes it less likely that you will skip letters or words.
Why do we not read code aloud?
This made us wonder, why do we not practice to read code aloud? In the same way that reading text aloud helps to understand meaning, so could reading source code! We call this idea code phonology. Settling on a phonology could be challenging than you think, even for simple statements. For example, how should we pronounce an assignment statement like x = 5? Is it “x is 5”? Or “set x to 5”? Or “x gets 5”? And what about an equality check? Is it “if x is is 5”? Or “if x is 5”? Or “is x is equal to 5”? As you see this could lead to tantalizing discussions (we had some in my code poetry workshop that was also one of the inspirations for this line of work)
A first experiment
To get an initial idea of how children even read code, we had 10 Dutch high school children read a bit of Python. These children all had some programming experience, including some Python. The code (to be found here) contained assignments, loops and conditions. Reading the code in a consistent fashion proved a daunting task to our 10 participants. All of them read at least one symbol, keyword or variable in an inconsistent way! Some of the things they struggled with were:
Symbols
One of the things that the children clearly struggled with was reading symbols (symbols included were: (, ), ==, !=, <, += and =)
An interesting vocalization (which we hardly ever encountered with professional developers) is to say == as “is is”, which 7 children in the experiment did. There were also other ways that the symbols confused the children. The symbol < was vocalized in many different ways, including “smaller than” and “lower than”, but also “arrow” or “bracket”, or skipped entirely.
One participant struggled specifically with combinations of two symbols like != and ==, and systematically only reading the first symbol. This behavior is likely to be influenced by their experience in mathematics where there usually is only one symbol, and that carries over as an assumption into programming. In a different experiment, we observed that same, and asked the kid about it, to which he said that he indeed saw the two = symbols but assumed it was a typo, since “‘is is’ is nothing”. That nicely stresses how important it is to draw attention to these type of differences and help children learn what they are!
Natural language effects
This experiment was made extra interesting by the fact that we did it with Dutch kids. We observed them choosing between Dutch and English for keywords and variables, for example saying “wheel” rather than “while”. Two children spelled out if in Dutch, saying it as “ie-ef”. The most interesting natural language effect though was on the variable i. In Dutch, i is read as “ee” as in “to breed”. In English of course it is read as “ai” like in “fry”. Just one child pronounced the variable in a consistent way (the Dutch way). The other 9 all mixed the Dutch and English vocalization, sometimes even within the same code block.
A different effect was that on word order. One of the subjects changed the order of the words to form a proper Dutch sentence. Rather than saying “if temperatuur is 20”, he said “als temperatuur 20 is” which is grammatically correct.
Syntactic versus semantic level
Some children read things that were not technically in the code, adding meaning. One participant read “for i in range(0,15)” as “for i in a range 0 comma 15″, adding the meaning that the numbers occur in a range and making the sentence more like a sentence in natural language. Another participant read “def kwadraat(x):” as “def function kwadraat x colon” adding the meaning that this is a function definition. That might be good practice for novice learners, or a hint to language designers that function is a better keyword.
Summary
In the exploratory study we have seen confusion over how to pronounce source code, confirming our hypothesis that how to read code is not a given. We observed students struggling with reading keywords, pronouncing variables and symbols. Even though we did not explicitly measure cognitive load in our experiment, it seems that students were spending energy on deciphering symbols, such as < and ==, on what to read and what to skip, and—in case of bilingual learners— on choosing between English and their native language. Cognitive load theory suggests that to free up mental room for more complex thoughts, easier processes must be automated. For example, before reading full words at once, children first automate the skill of reading letters. Before being able to process large multiplications, children need to have automated additions.
Creating a phonology
This experiment shows that it could be very beneficial to learners to agree on how to read source code, such that is can be practiced. And while our end goal is to put the phonology to use, we do believe that its creation has value itself. For example, studying where syntax and sound disagree, gives us insight into how people interpret code, and how they give meaning to syntax.
Some participants in the experiment vocalized the open bracket differently dependent on its context. A participant would say “f of x” when reading a function call, while that same participant used “f takes x” when reading the definition of a function. This gives rise to the question of whether a function call and its definition should be represented with the same symbol. On one hand, using the same symbol seems logical because of the close relationship between definition and application. On the other hand, if many programmers vocalize it differently, is it really a good choice?
Similarly, programming languages can have symbols written in different ways, but vocalized the same by many developers. For example, both = and == are read in the same way by some experienced developers. Some picked “is” while others said “equals”, but they used the same term for all these, and never used “is-is” as novices did. That gives rise to the question of whether these should be different symbols. A study by Stefik and Siebert that showed that it is best for programmers to use = for both assignment and equality checks, seems to confirm the way programmers pronounce symbols. That gives credibility to our hypothesis that pronunciation can give insights into the quality of programming syntax.
Using the phonology
After the establishment of the shared phonology, we see several uses for it. Of course, in education, for learners and their teachers. It will be a useful tool to practice code reading, but also for teachers to diagnose learners. In some cases, the vocalization of code could help educators identify misconceptions novices hold about programming.
In addition to novice programmers, we see broader usage too. A group of people that could benefit from phonology are adult professional programmers engaging in (distributed) pair programming. Wouldn’t it be helpful if conversations like “Open bracket. No, a round one!” would no longer be needed?
And a code phonology could also be useful when designing tools for programming, since an agreed upon method to read code aloud would allow computers to also read the code consistently, possibly aiding blind and visually impaired programmers. Inversely, there are programmers that can read but not easily write code because they lack full control over their arms. A phonology of code will ease the dictation, since it defines how a language should be pronounced. IDE’s or programming-by-voice tools could offer more powerful dictation support by taking advantage of that.
Read the full paper
