Why did we ever think a student's first programming language didn't matter?

As someone who has taught (or TAed) undergrad courses in all but APL and machine language, I would suggest a different sequence:

- LISP / Scheme - Python - C - Assembler / machine - whatever else beyond here

maybe leave out the LISP depending on how religious one feels about it (I'm a fan, from a pedagogical approach at least).

Most students have a very weak understanding of what a computer does (i.e. Von Neumann arch, executing an infinite tape of instructions, etc). I like LISP / Scheme because it really helps bridge the gap between expressions (which students can pretty intuitively grok from high school math education) and it really has no language design warts; you can write a metacircular evaluator in ~10 lines.

Python is a next step because it goes from "how does coding work?" to "okay how can I do stuff with this?". The language itself is pretty straightforward (although certainly has its warts too, e.g. the odd methods of variable scoping), but there are a ton of libraries and it is pretty much useful straight away for anything one wants to design a course around. Many unis combine "learning Python" with programming some robot, doing an AI thing, or other such practical outcomes.

Importantly, whenever I taught a "relatively beginner Python course", I would always spend a huge amount of time on teaching students about ipdb / pdb. Allowing students to explore the state and stack of a running program is a critical doorway for them to step through to not only learn how to debug their own problems (less of a load on me!), but also really start to grok the "program is a sequence of instructions that change state" thing.

C before assembler, although I have found it's often useful to "combine" them so that the concept of a pointer seems less odd and more useful. Also, C still has tools that students can use to explore their code (e.g. gdb), whereas they're much more on their own with assembler.

After that, it really depends on what students want to do. They can stick with systems stuff and do Rust / C++ / Go or go to Javascript or go crazy with the PL stuff with Haskell, etc.

Certain people (perhaps yourself) really understand this "program is a sequence of instructions that mutates state" thing, but in my experience, most of my students really don't get that. If I were to throw them into that deep end of the pool where they lack the tools to debug their own problems, I would get a lot of bad reviews / people switching out of the major. On top of that, students often like to really be able to produce cool stuff, which they can in Python very easily. Many students may bounce off the lower level stuff if they just want to do front end too, which is perfectly fine in a "top down" approach from higher-level languages.

This is very key. By the time I entered undergrad CS, the kids who had owned computers growing up, and played or even modded videogames, had a massive starting advantage over the ones who hadn't.

The entire first year of CS courses was mostly there to instill fundamental computer skills (not CS skills!) in the ones without that preexisting knowledge.

From [1], 2002 187 students investigated for cheating at GT. 77 students had their final letter grade dropped by at least one letter grade, 26 received an F, 32 received a zero for the assignment, one student was suspended for two semesters.

Though I couldn’t read the full article, but that’s what it seemed to say in the first two paragraphs.

There seems to be two slashdot threads discussing the issue from 2002. Perhaps it was worse after you left?

[1] https://www.chronicle.com/article/georgia-tech-concludes-che...

Foreign languages come with an enormous amount of experience. Whether that experience comes from watching a lot of foreign language media or living there or something else entirely probably doesn't matter. You need to build intuition and that seems to only come with experience. Teaching in this sense tends to provide subpar results, because no teacher can spend enough time to get students the experience required to become close to fluent. (I also suspect that it's not just the amount of experience total, but that there's some kind of minimum "experience density" based on time. Eg an hour a week for 20 years might not be enough, but 2 hours every day for 1.5 years might be. But this is just a hunch.)

At least that's my personal experience. We studied English for 11 years in school, some studied it later in university too. Every single person my age that was good at it used English outside of the classroom - mostly on the internet. They had enough experience that even without knowing the grammar rules they got the right answers "because it felt right".

I think this applies to learning anything else that requires to recognize patterns works in the same way: programming, mathematics, listening to a different language, reading handwriting, fighting difficult bosses in video games etc. You can theoretically understand all the pieces, but still be incapable of utilizing them for a satisfactory result.

> programming fundamentals from one language to another,

But the fundamentals of different classes of programming languages differ. For instance, Haskell's model of computation is not Turing machine but a G-Machine. It's a different matter that G-Machine and Turing machine are equivalent and that doesn't mean learning one is sufficient to understand the other. There is very little that can be transferred between the two.

To take another example, Javascript supports continuation passing style coding where as Java didn't until very recently.