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. ↵
5/ The real problem in CS Ed is we don't think enough about how we can relax constraints, widen the space of methods, future-proof 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 & determine lot other things. What languages make hard get ignored because folks are afraid to make CS hard for students. ↵
@shriramk Have found learning new languages opened my mind a lot; I wonder what a CS curriculum would look like that embraced Haskell, Kanren, Elixir, Levien's Io, Coq, Pure, Forth, Verilog, APL, ToonTalk, and the pi-calculus? Type of, solving difficult problems in each of them?
Could maybe get bogged down in puzzle-solving without students achieving transferability to other domains.
Long ago, one of my courses was a survey of multiple languages. We did Algol, FORTRAN IV, Snobol, and Lisp. Since then, I've used many languages professionally. Exposure to other languages does two things.
First, learning a new language is easier than you might expect. You know some techniques, like loops, exist, so you can look for them—no need to learn about these fundamentals. Even today, if you are doing FP, you know something iterates over collections.
Second, you can read other languages sufficiently to understand the implementation's logic, if not the details. I frequently do this with Python.
@rmerriam @shriramk I think is true that if you know Algol you can figure out Fortran, but Snobol and Lisp are pretty different (at least the sublanguage of Lisp without SETQ) and I think Coq and Kanren are even further out.
Helps to understand a program in a language you don't know well if the language is designed for easy readability by people who aren't familiar with it, like Python and COBOL. Also helps if the author is aiming for that. Lots of Haskell code isn't.
@rmerriam @shriramk Yeah, Kanren is kind of like a super-Prolog (or a super-Snobol, maybe). I think Forth is maybe actually a little less weird in that sense, with most of its strangeness being syntactic.