Christophe Weblog Wiki Code Publications Music

What is a good language to teach at undergraduate level for Computing degrees?

Unfortunately, this is an underspecified question. In order to be able to answer this, we need to have some idea of the programming-related objectives of the degree (on top of those objectives common to every degree, such as teaching our students to live well in their society). Here are some possible objectives, labelled by a handy one-word tag:

  • Think to teach our students how to think and solve problems computationally;
  • Experiment to enable our students to use computers as an experimental and/or expressive medium;
  • Job to improve our students’ chances of obtaining a graduate-level job in the six months immediately after graduation;
  • Career to improve our students’ chances of having a fulfilling and rewarding career;
  • Study to prepare our students for further study, particularly in masters and doctroal programmes offered by Goldsmiths;
  • Society to help our students understand the short- and long-term costs and benefits of particular computing design decisions

The point of stating this list of objectives up front is that each of them has a distinct set of good teaching languages: teaching students to think computationally involves a substantially different approach from maximizing their chances to gain a graduate-level job six months after graduation – it is of course possible to do well at both, but that involves tradeoffs and planning. Here’s my take on optimal kinds of languages for this:

To optimize goal Think, I believe that students should be exposed early to a programming system which minimizes the number of extraneous details between the programmer and the computation. Note that this doesn't mean that we should be teaching Assembly Language (though that is one possibility); there are other models of computation around, and using a lisp-related dialect such as Racket or a Hindley-Milner typed system such as Haskell would allow the students to tackle computational problems immediately without having to deal with more than a minimum of syntax and tooling issues. Teaching in Java (or C++, or similar industry-standard languages) directly at this point is antithetical to the goal, because of the amount of boilerplate and irrelevant knowledge needed in order to achieve anything at all. Using Processing is not as antithetical, because it eradicates at least some of the boilerplate, but the tooling (the Processing “IDE” and its woeful handling of errors, the bizarreness of the base language that it inherits from, and the absence of pedagogical assistance) is subpar.

To optimize goal Experiment, the students should become familiar with a rapid-prototyping environment in their particular domain. For Arts Computing or Music Computing students, this might mean MSP, Processing or Overtone; for CIS students that might be Clojure or Python; for CS students it might be Haskell or a language in the Lisp family. Data Scientists might want R and Games Programmers Unity. The point here is that to allow rapid and free experimentation and expression, the barriers to doing things in the domain of interest should be as low as possible, without concern as to whether the language is a good one for general-purpose activity – though it’s important that there is also a clear path between prototype and production (which eliminates PHP from consideration in my mind, though I accept that this is an argument born from my particular tradeoffs between short and long term.)

Goal Job is an interesting one. Some of our students will want to be recruited by large employers with development teams. These employers are typically not that flexible in their recruitment approach, and will normally test their applicants’ competence in an “industry-standard” language at an assessment centre: in practice this means that our students should be competent in at least one of Java, Javascript, C++ and [[C#]]. (In case anyone doubts: I have seen adverts for server-side and general programming jobs with Javascript as a permissible assessment-centre language). For those of our students with specific industries in mind, though, knowledge of the domain languages of those industries trumps the industry-standard tag: C++ (and domain-relevant mathematics) is practically essential for games programming, while I'd expect Javascript (and knowledge of one or two web stacks) to be similar for a job in creative agencies.

To help our students with goal Career, I think we need to instil in them the clear knowledge that in order for their skills to stay current and relevant they will need to continue to learn new computational technology, as well as become expert in their domains, throughout their working lives. I don't think that this is something that we can achieve by exposing the students to any single language in particular; rather, they should be exposed to a large variety of languages, so that they can appreciate the variety of programming paradigms out there, what they're good for, and the extent to which a language and programming environment adapted for a particular domain can deliver benefits in that domain over a general-purpose language. Ideally, students should be exposed to procedural, functional, object-oriented (both message-passing and generic), dataflow, logic and agent-oriented programming styles, as well as some metaprogramming.

As for further Study, our Masters courses are in some cases aligned with our undergraduate offering, and in some cases not. There would not be any particular difficulty from a programming point of view for undergraduates to take up the MA/MFA in Computational Arts (their art practice is likely to be more of an issue, with the possible exception of the Digital Art undergrads); likewise, there's an obvious route in to MSc Games and Computer Entertainment for our undergraduate Games Programming students. On the other hand, there’s no obvious progression from our undergraduate programmes to Data Science or the MRes in Digital Journalism; this may or may not be a problem. At PhD level, the problem tends to be less about the programming, which is almost always bespoke in any case, and more about the domain of research – though C++ for IGGI students is always likely to be helpful.

Finally, for the students to understand how choice of programming language affects Society, they need to understand how the particular design choices in a language and deployment affect not just a single product but the whole world. The concerns about privacy, autonomy, and security that now regularly make the mainstream media (let alone the technical press) illustrate how design choices get embedded only to cause problems further down the line. This is relevant to programming language choice because to illustrate that it would be good for the students to implement something, such as a simple networking protocol, in both “safe” and “unsafe” languages, and then attempt to break those implementations. The classic unsafe language being C (though C++ can be equally unsafe, and probably is in the hands of an undergraduate), and “safe” could be anything all the way to non-Turing complete languages with proof assistants (e.g. ACL2, used for chip design but general-purpose enough for this)

The overall point, though, is that we cannot optimize all these goals simultaneously. That means we will have to compromise, based on an overall hierarchy of desired outcomes, our judgment of our intake’s needs and desires and our assessment of what their careers and outcomes should be in three years’ time. Before agreement has been reached about what the goals of that teaching are, and the relative importance of those goals, arguments about the relative merits of languages for teaching are likely to be futile.

Further reading:


  • Chris Cannam’s blog, 12 May 2014

(Written in response to an apparently annual discussion on the staff mailing list of the Computing Department at Goldsmiths.)