Probably the most commonly asked question by teachers coming to computing is: what programming language should I teach with? An idealised answer might be that it doesn’t matter — the ideas and principles are similar across all of them. However, in practice, teachers do need to pick one (or two) languages to use, and this allows them to concretise much of their planning. One teacher recently asked this question, and this blog post expands on my response there.
There’s no perfect or right choice for which language to teach — although I would argue that there are some bad choices, especially for younger age groups (teaching C++ to a group of six year-olds would not be the best option). I also think that the programming environment can be as important as the language. Taking Scratch as an example, part of Scratch’s appeal is the environment — the graphical display of the produced program — and part is the block-based programming. App Inventor is a similar block-based programming language to Scratch, but in a different environment that produces GUI-based mobile phone apps. The two systems are not interchangeable, despite effectively sharing a common language. Similarly, Greenfoot is a graphical environment for Java (disclaimer: I work on Greenfoot) which produces quite a different effect than Java on the command-line.
I suggest that there are four key issues for choosing which language/environment to teach — in no particular order: teacher confidence/competence in the language, language accessibility, student engagement and suitability for the curriculum. Teacher confidence/competence is obviously a personal thing, and only matters when the teacher has prior experience — not the case for many teachers about to be thrown in at the deep end in the UK! I’ll discuss the other three key issues below.
Accessibility is a bit of a nebulous concept, but one way or another, it’s clear that some languages offer an easier start in programming, especially for younger age groups. Scratch is one of the gold standards for easy accessibility, being used from very young ages (six and upwards), and avoiding whole classes of errors (e.g. syntax errors). At the opposite end there are full-text programming languages with lots of capabilities, but easy to go wrong (e.g. C++). Position on the spectrum in-between is not clear, but conventional wisdom has it that Python is more accessible than Java or C#.
One obvious factor in learner engagement is the application domain, or what students can actually produce by programming. Many years ago, programming education centred on spitting out the prime numbers or solving quadratic equations. Nowadays, the horizon is much broader: applications can be in robotics, or on the web, or making games, or apps, and so on. This tends to be more a property of the environment than the language, and theoretically it’s the same principles behind any application — which causes many to think that the application doesn’t really matter. At an overall learning-the-principles level it doesn’t matter, but I believe that when you’re in the classroom with 20 pupils, it does matter, and some applications are an easier sell to the class than others. (Research has repeatedly suggested that students, especially minority students, are more interested in CS when they can see practical applications that benefit others.)
There is also a problem of wanting a modern system — especially in the more traditional CS core participants in older age groups. There’s a post by Mark Guzdial where he points out that Logo still exists in the same form as it always has, yet we don’t teach with it any more. He argues that it’s because the students don’t just want to learn some arbitrary thing — they want to join a larger community of practice.
Sometimes when older students sniff that a system is out of date or irrelevant (whether it is or not), they can go cold on it quite quickly. I suspect that how they decide something is old-hat is quite a weird and subjective thing, but we get this at university a lot — the students want to learn what they think is being used in industry, rather than trusting that we will teach them transferable principles. Educationally, this can be irritating. To use a sports analogy, it’s generally considered that football in the UK has suffered from lots of kids playing 11-a-side on full-size pitches from a young age, when the better move would to be play smaller games or futsal, to produce Barcelona-quality players. In programming, as in football, it doesn’t necessarily make sense to start out in a perfect replica of the professional setting. However, it can often be difficult to convince students that it is a good idea to start simpler than their eventual goal in order to have a better learning route.
Suitability for the Curriculum
Suitability for the curriculum, or specifically suitability for the assessment, is very irritating from our point of view in developing Greenfoot (which is intended to increase learner engagement). Many teachers relate that they can’t use Greenfoot because although it can cover all the principles needed by a course, it doesn’t suit some of the sample projects (especially for UK GCSEs). That rather deflates the righteous argument that computer science is all about the principles and language doesn’t really matter! So if you need to build GUIs, your options might look a bit different to if you are allowed to do robotics projects (or whatever). It seems to me a sad thing when the teaching of CS is constrained because a certain system doesn’t have a GUI builder, but the considerations of a curriculum and its concomitant assessment are a real practical concern when picking a teaching language/environment.
For UK teachers, this is mainly an issue at GCSE and A-Level (ages 14–18). Earlier age groups where there are no external assessments do not have to worry so much about this issue, although teachers may wish to align the earlier teaching with what students would do if they took the computing GCSE.
A possible further factor is availability of teaching material, but that depends on how much the teacher prefers to use/adapt existing material vs creating their own. And finally, there are sometimes practical issues. Software being cloud-based, or producing EXEs (banned on many school systems, sigh…) can cause problems in a school, so unfortunately this also needs to be borne in mind.
I haven’t given an answer to the question of what language to teach with, because there is no one right answer — especially not for different teachers in different settings. But hopefully I’ve provided a few factors to bear in mind while making the language decision. (I haven’t really gone into language issues in-depth here (OOP vs procedural vs functional, dynamic vs static typing, etc), but I suspect that they aren’t actually the most important issues in choosing a language. Feel free to disagree in the comments or suggest other important factors in the choice of language/environment.)