Ruby
What happens when a linguist learns to code?
Summarized using AI
What happens when a linguist learns to code?
by Erica SosaIn this video titled "What happens when a linguist learns to code?" presented by Erica Sosa at RubyConf 2019, the speaker explores the parallels between learning natural languages and programming languages. Sosa, a former linguist who transitioned to software engineering, discusses how principles from linguistics can enhance the process of teaching and learning programming.
Key points from the talk include:
- Human vs. Computer Language: Sosa highlights differences in grammar between the two, emphasizing that while human language grammar is intuitive and descriptive, programming language grammar is more prescriptive and rigid.
- Language Acquisition: She differentiates between first language acquisition—where exposure and feedback play significant roles—and second language acquisition, which involves managing transfer from the first language when learning a second.
- Pedagogical Approaches: Sosa introduces teaching strategies from linguistics that can be applied to programming instruction, such as learner-centered instruction, content-based instruction, and maintaining engagement within the zone of proximal development— the learner's capacity to grasp concepts with appropriate support.
- Practical Steps: Suggestions include effective pair programming, encouraging discovery learning, checking comprehension through specific questions, and avoiding jargon when explaining concepts.
- Conclusion and Future Directions: Sosa concludes by reflecting on how her linguistics background informs her programming career and emphasizes the need for interdisciplinary approaches to programming pedagogy, borrowing strategies from language teaching to improve coding education.
By drawing these comparisons, Sosa aims to provide insight into both fields and encourage better methods in teaching programming based on established principles from linguistics.
00:00:12.129
Hey everybody, thank you so much for coming to hear my talk. My name is Erica Sousa, and this is what happens when a linguist learns to code. Out of curiosity, has anyone in here studied linguistics? Oh, okay, cool, quite a few people. Has anyone ever taught a language? Okay, a couple of people. Has anyone ever learned a second language? Yeah, a lot more. Has anyone learned a second programming language? Yeah, even more. Has anyone ever taught coding in a formal setting? Okay. Has anyone ever taught coding in an informal setting, like mentoring? Okay, great. So, a lot of different experiences in here. That's great.
00:00:30.800
Today, I'm going to explore how learning a natural language compares to learning a programming language. I will see what we can apply from the field of language teaching to programming instruction. I hope that anyone who is interested in learning or teaching programming languages will walk away from this talk with some concrete ideas on how to be better teachers and learners of code. You might guess from the name of this talk that I'm a career changer and I used to be in the field of linguistics. I began my career by teaching English as a Second Language, both abroad and in the U.S. Some years later, I got a master's degree in linguistics, and then I went into university teaching of ESL, applied linguistics, and second language acquisition.
00:01:12.890
After many years in linguistics, I decided I was ready for the next challenge and transitioned to software engineering. I attended a coding bootcamp where I learned Ruby and JavaScript, and then I freelanced for a while, doing web development for small companies. Eventually, I got a job at Braintree, where I still work today. The first engineering team I worked on at Braintree was a Ruby team. Later, I moved to a JavaScript team, which I am still part of currently. So, that's to say I learned Ruby as my first programming language and JavaScript as my second programming language.
00:02:04.020
Now, I want to jump into my real topic, which is how learning a natural language compares to learning a programming language. When you study something or work in a certain field, many people make assumptions about what you do. Some of those assumptions are right, and some of them are wrong. I realized throughout my career that many people had ideas about language and linguistics, and it turned out that a lot of them had more questions about how language and linguistics relate to coding and programming.
00:02:32.510
Specifically, they would ask me if my background in linguistics helped me learn how to code. At first, I thought those two things were completely unrelated, but the more I considered the question, the more I realized that there was indeed some overlap. Initially, for this talk, I wanted to explore every single way that we could compare natural language to programming language, but that is a really huge topic, and I didn't have time for that. So instead, I'm going to focus on a few specific areas related to learning languages. This is our agenda for today: human versus computer language, first language acquisition, second language acquisition, teaching language, and programming pedagogy. For those who aren’t familiar with the term pedagogy, it means the theory and practice of teaching.
00:03:29.239
Let's start with human versus computer language. I want to talk a little bit about the similarities and differences between these two types of language. There are many ways they compare or don't compare, but today we'll focus on grammar. When I say grammar, I'm not talking about how your old English teacher might scold you for ending a sentence with a preposition, not that kind of grammar. Grammar in a linguistic sense is the mental system that allows human beings to form and interpret the sounds, words, and sentences of their language. This grammar is descriptive, not prescriptive, meaning we're interested in how language is actually used, not how we think that language should be used.
00:04:44.079
Let's go over some fundamental principles of human grammar. All languages have a grammar, so there's no such thing as a primitive or advanced language. All languages are equal because they are all governed by rules. All grammars are alike in basic ways, so there are some qualities that all human languages share. For example, all human languages have a concept of subjects, objects, and verbs. All spoken languages have the AA vowel sound. All grammars change over time, so language change and evolution is an inevitable feature of human language. People who actively try to control speech or the way people talk generally don’t win that battle.
00:06:01.310
An example of this change is the phrase 'because reasons.' We used to have to say 'because of reasons,' and people told you all day long that you can't remove that preposition. But that's not true because we do it. Language change is organic; that's how it works. It's a natural and expected part of the evolution of language. Grammatical knowledge is subconscious, so we understand the grammar of our native language intuitively. We don’t need to think about a rule explicitly before we speak, as it’s part of that mental system of our grammar.
00:06:56.220
Here's an article that just popped into my feed. It discusses a rule of English that is being explicitly taught in ESL classrooms and how native speakers aren’t even aware of it. If you take this phrase, 'a nice new house,' for a native English speaker, that sounds very normal to say. Now take 'a new nice house.' Does that sound weird? Yeah, okay, 'a new nice house' that sounds strange to a native speaker. There's a reason for this: there’s an order to the way we place adjectives in front of nouns, and native speakers just know this rule intuitively.
00:07:26.990
That rule is: opinion, size, age, shape, color, origin, purpose. Did anyone know this? A few people. Well, how many of those people are second language learners? Almost all. We can say 'a nice big old pointy red German gardening shed,' but we cannot say 'a pointy German old big nice gardening red shed.' It's funny, it's ridiculous. But this is your subconscious grammar. So what about programming? How can we take these concepts and relate them to programming? All languages have a grammar, and this is true. All programming languages have rules that govern their use, and to some extent, that grammar is both prescriptive and descriptive.
00:09:14.180
It's prescriptive because these are very rigid rules. If you try to get creative with computer language, it's not going to work. Things are going to break. For instance, in human language, we can say 'Do you like ice cream?' and we can also say 'You like ice cream.' Dropping the 'Do' is not a problem. In Ruby, however, we can’t just drop a word off of an expression. We can’t drop 'DEF' at the beginning of this method definition because it’s going to break. However, to some extent, it's also descriptive because we can use certain constructions even if they're frowned upon by the community.
00:09:57.470
In the Ruby world, we want to see the first version, saying 'yummy?' for a Boolean method, but we could still use 'is_underscore_yummy.' It wouldn’t break. All grammars are alike in basic ways. This one is hard to say definitively because there’s such a wide variety of programming languages out there. However, I did a little research and found that most people think there are some universals—some basic universals—related to programming languages, particularly higher-level programming languages. These include things like conditionals, loops, code reuse (or functions), mathematical operations, variables, comparison, and Boolean logic.
00:10:57.310
All grammars change over time, which is probably true. I don’t know if we can call it a definitive truth, but I do feel confident in saying that human language and computer language change differently over time. Computer languages change inorganically, meaning that someone has to decide to write a new feature, and then others decide if that feature is permissible or not. Then a new version has to be released to allow that feature. I can't just decide I want to do pattern matching in Ruby 2.6; I've got to wait for 2.7.
00:11:43.590
Grammatical knowledge is subconscious in programming languages, which is probably false. No person is a native speaker of any programming language since all programming languages are intentional human creations. However, someone who knows a programming language particularly well could have an intuition that something is not quite right, without actually knowing for sure. I'm going to give you a chance to look at this Ruby example, and I want you to pay close attention to how this class gets its name. I'm going to give you a second, and if you think it's kind of weird or funny, I want you to raise your hand. Okay, some people think it's kind of funny—I too think it's kind of funny.
00:12:47.020
So what’s happening here is that an anonymous class is being created. We check the name, and it’s nothing; it’s anonymous. Here's the weird part: we name that class by assigning the entire object to a constant. It can only be named like this with a constant, and you can't reassign the object. Then we check the name, and it’s 'WTF.' Like, what's going on here? This is weird! I’m willing to bet that a lot of Ruby developers would not know this intuitively. I have a little data to back me up here because this example was posted in a Braintree Slack channel and people were going crazy with heads-exploding emojis and stuff.
00:13:50.230
Using your programmer's intuition, you might think this couldn't be done. In the case of programming languages, we can't always rely on our intuition to determine what’s grammatical because ultimately, it’s the interpreter that decides what’s right and what’s wrong. By the way, this is not a bug; this is documented. Again, we can see how grammatical knowledge in this case is quite explicit. So, that was a little bit about some very high-level commonalities and differences between natural language and programming language.
00:14:35.320
Next, I want to talk about how we learn both human and programming languages. First, we need to differentiate between first and second language acquisition. When we say second language acquisition, we’re talking about everything that is not your first language—your second, your third, your fourth. This means learning a first human language is a separate process from learning a second and subsequent human languages.
00:15:16.510
Learning a first language is a process of exposure, feedback, and inborn knowledge. Exposure means the more language you hear, the faster you pick it up. When we say feedback, we're not talking about explicit correction because that doesn't work well with children. We're referring to the process of interaction and certain types of linguistic interaction yielding different behavioral results. Inborn knowledge is the idea that there’s something about being human that predisposes us to language, even if we don’t know exactly what that something is. However, barring some extreme circumstances, every person in this world will acquire a human language.
00:16:27.310
Can we compare learning a first human language with learning a first programming language? Yes and no. We could definitely say that learning a programming language is a process of exposure and feedback—exposure because it requires a lot of practice, and feedback could come from another person. However, many times it’s derived from your errors, your interpreter, or your tests. It would be challenging to say that there is some inborn knowledge that allows us to acquire a programming language. There are similarities between human and programming languages in that we’re learning to express concepts through the language we’re using.
00:17:31.250
For example, I might be learning about iteration for the first time and using Ruby loops to express that concept. However, when learning a natural language as a baby, you have already developed some concepts, and you're just learning how to express them. As humans, we're not born with a sense of how to conceptualize software development, so we’re learning both the concepts and the language at the same time. Assuming there’s a benefit in learning concepts before the language, can we find a way to decouple concepts from syntax? We’re going to put a pin in that and revisit it at the end.
00:18:52.560
Now, let's talk about learning all the languages after your first—which is to say, second language acquisition. Does anyone in here speak two or more human languages? Cool! How about three or more? Wow! Four or more? Whoa! Five? Six? Oh my god, okay, I’m going to stop that’s a lot, that’s great. It’s very difficult to come up with a comprehensive theory of second language acquisition because there are so many more factors at play than in first language acquisition.
00:19:45.010
What is the first language? What is the second? What is the learning environment? What’s the learner's age? How do they learn? What’s their motivation for learning? Lots of factors. In the absence of any sort of unifying theory, second language acquisition draws from many different fields: linguistics, psychology, philosophy, and pedagogy. First language transfer is both an interesting and applicable phenomenon when we talk about programming. This is the idea of transferring the features of your first language onto your second language.
00:20:53.010
The most obvious example of this in human language is pronunciation. If someone learns a language after a certain age, they'll almost definitely retain some pronunciation features of their first language while speaking their second language. You could certainly apply this to programming languages. For example, in JavaScript, I might write some Ruby code that looks like using underscore for boolean methods versus using 'yummy?'. I might use camel case instead of snake case, explicitly return from a method, or use parentheses in a method call when I don’t actually need to. None of these things would break in Ruby, but they would probably mark you as a second language learner.
00:22:27.560
Human languages generally fall into one of two categories: languages where pronouns are optional and languages where they are required. When the pronouns are optional, we call this pronoun drop. For example, in English, we can say 'she eats ice cream,' but we can’t just say 'eats ice cream.' However, in Spanish, we can do that; we can pronoun drop with no issue. In linguistics, this is called the null subject parameter, but I will refer to it as the optional subject parameter because I think that is easier to understand. In Italian and Spanish, they allow an optional subject, while in French and English, the subject is required.
00:23:23.070
According to this principle, optional subject languages are the superset of required subject languages. Studies of second language acquisition have shown that it’s easier for speakers of subset languages to learn superset features than the other way around. For example, it's easier for an English speaker to drop their pronouns when learning Spanish than for a Spanish speaker to always remember their pronouns when learning English.
00:24:21.820
So how might we apply this to programming languages? Here’s one idea: remember how we talked about method calls with parentheses in Ruby? In Ruby, you do not need parentheses to call a method; they're optional. But in JavaScript, you absolutely need these parentheses; otherwise, you’re just referencing the method and not actually calling it. Let's put this into the subset principle model; we'll call it optional parentheses. If this follows, it would be easier for someone who learned JavaScript first to adapt to the optional parentheses of Ruby than for someone who learned Ruby first to always remember their parentheses in JavaScript.
00:25:09.750
In my case, this is definitely true because I still make this mistake in JavaScript of not explicitly calling functions, due to my background in Ruby. So, while all of this is theoretical, what is the practical application here? The field of programming pedagogy is still fairly new, but identifying concepts that are easier to learn than others, truths that persist across languages, or examples of first language transfer could be really helpful in this emerging discipline.
00:26:08.550
Now, how do we teach language? This is a really big question, and the field of second language teaching has been around for a long time. I picked out a few practices that I believe we can directly apply to teaching programming. The first is learner-centered instruction. This is an approach developed in the 1970s and 80s, originating as a reaction to the one-size-fits-all philosophy that was dominant in language teaching up to that point. This practice stems from the idea that learners are diverse.
00:27:03.820
This may seem obvious today, but it was really novel back in the day. If a learner is unique, there’s no one solution that fits every student. So, instead of focusing solely on the subject, which is language, we should focus on the learner and what they need. How do we know what a diverse group of learners needs? It's quite simple: we ask the learners and involve them directly in the decision-making process around their learning.
00:27:37.690
How can we make coding instruction more learner-centered? This is a good question, and we’ll come back to it. Content-based instruction refers to an approach to language teaching that organizes instruction around meaningful content and subject matter. This contrasts with traditional instruction that focuses explicitly on teaching the language itself. This approach teaches through the language. For example, imagine you are a teacher with students interested in the environment and pollution. For your lesson, you might have them read background material about the environment and then organize a debate on the best way to approach the issue and solve the problem of pollution. They would then write a journal entry about it.
00:28:53.370
The content revolves around the environment and pollution, and they use language to explore that content. What might coding content-based instruction look like? Again, we’ll put a pin in that and revisit it in a bit. The zone of proximal development is another theory in the field of education. It refers to the distance between what a learner can do independently and what they can do with help from a more skilled counterpart. According to this theory, we want to stay in the middle zone: if we are too far left, the learner will be bored; if we are too far right, they’ll be lost.
00:29:49.300
There are tasks that learners can't do, even with assistance, simply because they are not ready for those concepts in their phase of development. I know I went through my history of learning to code very matter-of-factly, but the initial years were incredibly difficult. In my past, I was used to grasping new concepts fairly easily, but this was the first time I felt that no matter how hard I tried, there were some things I couldn’t comprehend, which made me feel inadequate.
00:30:28.170
At this point, I was aware of the zone of proximal development, but I hadn’t thought to apply it to my coding career. For example, you can't go from learning how to write a basic method directly to a concept like multi-threading. You must first understand concurrency before mastering multi-threading. There’s a specific order to how these concepts need to be acquired, and we can’t skip around it. It’s vital for learners to know this so they don’t feel inadequate for failing to grasp concepts beyond their current understanding.
00:31:23.970
Similarly, educators need to ensure that the materials are appropriately challenging for their learners. So how can we keep learners within the zone of proximal development? Let’s discuss some ideas. Not every idea will work for everyone, and that’s perfectly fine. If you see a suggestion you like, give it a try because it may work for you. Pairing is an effective method because the sweet spot for a learner is typically slightly more challenging than what they can do alone.
00:32:06.600
Pairing provides the scaffolding needed to learn something they do not yet know. However, think carefully about who the learner is paired with because it’s often not ideal to pair with the most experienced person in the room since the knowledge gap may be too wide. Sometimes pairing with someone slightly more experienced is more beneficial, as the smaller knowledge gap makes the step up more attainable.
00:32:53.880
Encourage learners to touch the keyboard only after asking. Allow them to ask, and then they can type. Generally, let the learner drive because they won’t learn nearly as much by watching someone else code as they will by coding themselves.
00:33:08.200
Encourage discovery! Let the learner try things and make mistakes. Even if you know immediately that what they are doing won’t work, don’t say anything—let them go. When they fail, they'll understand exactly why it didn't work, which is a far more valuable lesson than simply informing them why something will fail.
00:33:27.620
Check for comprehension. It’s common for someone to ask, 'Do you understand?' and receive a yes or no. When they say yes, you won’t truly know if they understand because they might simply want you to leave them alone. When they say no, a common follow-up question is, 'What don't you understand?' But that’s a complex question for someone who doesn't understand.
00:33:44.060
Instead, ask what they do know. For instance, you could ask, 'What does this method do? Where does that variable come from? Can you trace this code path out loud for me?' Questions like these foster comprehension. Avoid over-explaining. The more you elaborate on a topic, the more likely you are to touch on a concept that a learner is not ready to grasp. Keep your explanations concise and straightforward.
00:34:45.340
Finally, be mindful of jargon. It is common for someone learning a concept to understand it without knowing the specific word for it. If you use a term and your learner looks confused, try rephrasing it. They might actually understand what you're talking about; they just might not know the term.
00:35:01.840
So that brings us to the conclusion of the agenda. We covered a lot of topics! What happens when a linguist learns to code? Well, she starts thinking about how to apply her former career to her current one, resulting in a talk like this. I believe that career changers bring a lot of value to software engineering by offering new perspectives on familiar concepts.
00:35:46.940
Programming pedagogy is genuinely a field in its infancy. We've only just begun teaching coding in schools, boot camps, and online, while language teaching has been around much longer. My hope is that we can take an interdisciplinary approach and draw from this more established discipline as we figure out the best ways to teach programming. Thank you so much for coming to hear my talk! Please feel free to get in touch or catch me outside with any questions.
Explore all talks recorded at RubyConf 2019
+84