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.
If you mean new developers, I don't think there is a best language. All have issues for newbies.
For experienced developers, it depends on their niche. Frontend would be either Javascript or Typescript. I've done JS but not TS. It's a fun language.
Backend, I'm not sure. I work with C++ so, for various reasons, I think it would be good. That's all I can suggest.
As I said, the techniques or concepts transfer across many languages. Iteration and branching, for instance. Once these are learned it is only necessary to find the equivalent in the new language since you already know how to use them. The same applies to libraries for a language, e.g., collections.
As for similarity, not entirely. Snobol has branching, but it is based on the results of a statement with the branch at the end of the line.
@rmerriam @shriramk Some concepts don't transfer across many languages (in Fortran, what's the equivalent of a Prolog logic variable, a Pure rewriting rule, or a Forth IMMEDIATE word?) and even concepts that transfer across many languages don't transfer across all (what's the equivalent of a `while` loop in Coq, a type declaration in Forth, a struct in Fortran 66, or a closure in C?)
I think the concepts that *don't* have an equivalent in languages you're familiar with are usually the most valuable, because sometimes give you powerful new ways to solve problems, and you can always implement them in your programming language of choice with enough effort, writing an interpreter if necessary.
@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.