I recently had two CS colleagues (from different schools) make the claim that we shouldn’t worry about the programming language in the first course because it just doesn’t matter. They each believed that we should focus on the CS learning outcomes. The belief is that if students learn the concepts well, then the students can simply apply it to whatever language they learn next. Ben Shneiderman and Richard Mayer described it this way in 1979 (see link here):
Learning a first language requires development of both semantic concepts and specific syntactic knowledge, while learning a second language involves learning only a new syntax, assuming the same semantic structures are retained. Learning a second language with radically different semantics (i.e., underlying basic concepts) such as LISP or MICRO-PLANNER may be as hard or harder than learning a first language.
The empirical evidence I know suggests that the learning a second language isn’t easy for most learners. While there is typically transfer from one programming language to another, it’s not seamless. Tshukudu and Cutts have been studying what transfers and what doesn’t when students move between Python and Java (see paper here). David Weintrop studied students moving from block-based to text programming. Yes, there was transfer, but learning was slowed when they shifted modality (see blog post here).
The first programming language is particularly important when we think about programming for other-than-CS majors. Students want to learn what’s valued in their desired community of practice. If a student wants to become a data scientist, R or Python makes a lot more sense than learning C. A computational artist might be motivated to learn Processing, but might not see a lot of relevance for learning MATLAB. Not everyone who learns programming today wants or needs the ability to switch languages as easily as computer scientists do.
I’ve been thinking recently about this question from the other side. Why did anyone ever think that the first programming language didn’t matter?
I have a hypothesis that this belief once was true, when the field was younger. When CS curricula were first defined in the late 1960’s, there was an emphasis on the mathematical underpinnings of programming. Nathan Ensmenger describes it in "The Computer Boys Take Over" as part of increasing the perceived professionalization of computer science. So students who entered computer science in the early days typically had a stronger mathematical background than the average students learning to code today. This is obvious when you consider that the average has shifted. Programming was mostly taught to undergraduates in the 1970’s, and today, there are probably more K-12 students learning coding in the US than there were undergraduate CS majors in the 1970’s. CS education was developed assuming a stronger mathematics background than we can assume today.
Here’s my hypothesis: The transfer that Shneiderman and Mayer saw wasn’t from one language to another. It was transfer of different forms of the same mathematics. If we teach the semantics of the programming language based on mathematics students already know, then a new syntax is just a new formalism for the mathematics. Math has always been taught, "Now let’s try it this way." Mathematicians love to explore the same idea in different formalisms or with different approaches. Check out the Pythagorean theorem page in Wikipedia — there are more than a half-dozen proofs described. We’re conceptualizing the problem wrong if we think only about the programming knowledge transferring. For students with a strong mathematical background, the first programming language and future programming languages are just different notations for things the students already knows. That explains why what Shneiderman and Mayer are describing used to be true. But I don’t think it is anymore.
But what if the coding learner doesn’t know a lot of mathematics already? What if it’s a sixth grader who struggles with math class and is now taking his first CS class? What if it’s a graphic designer who is trying to script PhotoShop but avoided math classes doesn’t think of themselves as a programmer (see Brian Dorn’s work)? I predict that transfer to Python or MATLAB is going to be a lot harder than what Shneiderman and Mayer were describing. What if the coding learner is a "conversational programmer" (see paper here) who wants to be able to talk to programmers about their tasks but doesn’t actually want to develop software? The modern coding learner is a lot different than the ones in the 1970’s.
We don’t have to make programming about mathematics. We know that most people using Scratch are telling stories without a lot of math (see paper here). Conversational programmers struggle to find resources that help them learn because so many of them require a focus on the logic and mathematics (see paper here), but we are developing approaches to help conversational programmers learn without the math (see paper here). We might be able to teach a lot more people about programming if we don’t expect students to know mathematics first, which we may have been able to expect 40+ years ago.
If I’m right, there are implications for researchers and for teachers. For researchers, if you’re looking for transfer and not measuring mathematical prior knowledge, you may be missing a critical explanation for any transfer you’re seeing. For teachers, be aware of accidentally teaching programming-as-math. If your students are struggling, maybe you’re relying too much on mathematical knowledge that isn’t there.
Mark Guzdial is professor of electrical engineering and computer science in the College of Engineering, and professor of information in the School of Information, of the University of Michigan.
Maybe you can teach more people to program if you downplay math, but they will be better programmers if they learn and use math. Leslie Lamport argues this view in an essay on teaching concurrency (http://lamport.azurewebsites.net/pubs/pubs.html#teaching-concurrency) and in a recent interview (https://learning.acm.org/bytecast/ep16-leslie-lamport). I recommend giving these a read and listen.
Thank you for your comment, but I think you missed the point. MOST of the people who are studying programming today do not want to be better programmers. Most people who learn to program are K12 students, end-user programmers, or conversational programmers. Professional programmers and computer scientists are just one slice. Yes, they likely need math to be good at concurrent programming. Not everyone is going to do concurrent programming.
I do agree with your article at some level. It's always important to focus on the actual goal in education. If the actual goal isn't to teach mathematics, then requiring students to learn mathematics can only be justified by absolute necessity, and it's definitely not necessary.
That said, are we really sure that learning mathematics isn't the actual goal? I don't mean learning how to solve math problems, but rather I mean mathematics in the same broader sense that you seem to use it here. (Obviously, knowing the quadratic formula doesn't help with programming at all; but being able to think formally by naming abstractions absolutely does!) I'd say that if learning coding has any value at all, it's because it's an indirect route to learning mathematics, and indeed to learning a different kind of mathematics - the expressive, communicative, modeling-heavy sort of mathematics that's so hard to capture in a classroom setting - that makes it so valuable. That also strikes me as precisely the skill set needed to become a "conversational programmer", where the goal is explicitly to understand abstractions and ideas in the way programmers think about them rather than merely to write working code.
Does that mean the first programming language doesn't matter? No! I agree with you there. But the case for this sounds less like "coding shouldn't require math", and more like "mathematics can sometimes be learned as a result of coding, not as a prerequisite". Then the two qualities to look for in a beginning programming language are (a) pedagogical appropriateness, such as discoverability and empowerment of students to develop self-efficacy, and (b) easy of the path from that programming language to understanding abstraction, mathematical communication, and expressive modeling. Scratch, for instance, does great on criterion (a), and mediocre (but not terrible!) on criterion (b). Most other languages we have are mediocre at best on (a), and honestly not much better on (b) either. But that frames the search, at least, and in my biased opinion, highlights the value of approaches like Bootstrap or CodeWorld that are specifically designed to help students develop mathematical communication and modeling skills.
The case of R or Python for data science is ultimately just not that interesting. Sure, if you are teaching a population of students who want to apply a specific tool, you should teach them that tool. But this doesn't apply at all to the conversational programmers you refer to, nor most K-12 students. If you don't want to be a programmer, then that industry motivation is out the window. The more important concern is authenticity in the student's mind, and there are lots of approaches to that besides just picking a poor learning tool (like R, for instance) just because it's commonly used. The argument for choosing a first language based on likelihood of professional applications is by and large just as weak as it always was.
Maybe for some people, learning programming is a way into learning mathematics. For all the reasons you list, programming can be a terrific context for learning mathematics. This is an area of active debate right now -- why are we teaching programming at all in K-12? See https://www.educationnext.org/computer-science-for-all-as-new-subject-spreads-debates-flare/
But there are reasons for using programming in education that have nothing to do mathematics. Computing is a powerful tool, and programming is a way of harnessing and directing that power. In our work with social studies teachers, they want to use computing for data visualizations in history class. Computing is necessary for dealing with hundreds of years of data. Programming is a great way to define the visualizations you want. The history teachers with whom we work really don't want to deal with mathematics. So, we're exploring alternative ways of thinking about programming: https://computinged.wordpress.com/2020/09/14/lets-use-programming-in-social-studies-classes-nsf-funding-for-our-work-in-task-specific-programming-languages/
Based on Katie Cunningham's work with conversational programmers (https://computinged.wordpress.com/2021/06/21/katie-cunninghams-purpose-first-programming-glass-box-scaffolding-for-learning-to-code/), I don't think that they think about their need as mathematics. I suggest that it's the math-iness that most turns them off to traditional programming classes.
I support and encourage those who want to use programming for teaching mathematics. Let's not limit programming's role in education to just mathematics, though.
Displaying all 4 comments