1/ “What programming language should I teach?” is the least productive question to ask in computing. There’s a good reason: it’s the wrong question to ask. The reason language wars feel pointless is that they’re a symptom of this problem. Here’s why:

2/ Curricula are never designed in isolation. All curricula, for anything, have to consider at least two things. First: goals. These include learning objectives, but often go farther (like “students must eventually get jobs”).

3/ Also, constraints. The constraints dictate what the admissible set of solutions is. Constraints vary across both space (different places) and time (different years). Without stating constraints, finding solutions is meaningless.

4/ Also, methods. Whereas, programming languages are a solution-space artifact. You don’t *start* with them, you *end* with them, relative to everything else. So starting with the “which PL” question is guaranteed to lead to talking at cross-purposes.

Picture showing a funnel where constraints, goals, and methods go in, and solutions come out.|400

5/ The real problem we have in CS Ed is that we don’t think enough about how we can relax the constraints, widen the space of methods, future-proof the goals, etc. So we go from one blub language to another per decade: Pascal, C, C++, Java, Python…

6/ Here is my highly scientific visualization of the progress we’ve made in computing education. Whatever languages make easy become the default and determine a lot of other things. What languages make hard get ignored because folks are afraid to make CS hard for students.

Slide entitled

7/ For a long time, educators found curricula like SICP hard. (Now, they’ve just stopped talking about it.) This got translated to “Scheme is hard”, because people can only see things through the overly simplistic lens of programming. But:

8/ What they missed is that SICP and other curricula, typically coming out of FP, had gone well past the “rubbing two rocks to get sparks” to the “igniting boosters” stage. It was blub all over again, at the level of curriculum, not language features.

9/ This is the problem with “language” discussions. We need *curriculum* discussions. If someone asks you “what language should I use”, please don’t provide answers. Please ask questions. Good questions. The right questions.

10/ A lot of people reading this are techies who are sometimes asked to help out in schools. I beg you, please watch at least until 8m30s into this talk, “Curriculum Design as an Engineering Problem”. You’ll get it. It’s written for you.


The “What language should I learn?” is the most common question I get asked by those who want to get into coding, for 40 years of my life now. It stems from the belief that when they get a job, they’ll only ever use what they learned in school.

Because if we’ve learned anything from the history of computing, it’s that nothing ever changes.

Your answer is in context of curricula. I wonder how you would change that for 1:1 for a third grader? About to start teaching my daughter. Am comfortable with Scheme, Python, Scala, C++, Prolog, Haskell, Starlogo, javascript, perl; I should be able to adopt anything you suggest.

Why only one? Teach 5 different with maximally different paradigms. For each lang write simple parser and meta circular evaluator. Curious students will extend it in any direction they want.

I started teaching programming when I inherited Peter Landin’s courses, around 1979. He’d invented blackboard notation. A flexible, extensible notation to teach programming clearly. Don’t care (even in coursework or exams) what implemented programming language students use if any