[ogintherapgame]

Terrible suggestion. We need to kill all these c'isms as fast as possible. Teach people to write nice data-structures, with good api's, and with generic and sensible types. All these C'isms like returning -1 for false and 'nil' children seriously sucks. For a systems class it might still be suitable, but you could design good courses around other languages like ada, zig, rust w/e.

If you want to teach them a lisp as a first language, at least use Racket, which actually have modules designed for education. I think it's less of a headache to use a language with a more modern syntax, like python or pyret, but Racket is excellent of course. You can introduce lisp later in a undergraduate compiler/interpreter class so you don't have to talk about parsing for a month.

[jlokier]

Why would you need to talk about parsing for a month with Lisp?

Lisp famously has one of the simplest syntaxes possible that is still structured, and one of the simplest data structures to understand. There's almost nothing to it.

And why would you introduce Lisp in a compiler/interpreter course, to people who are presumably already quite advanced in their knowledge?

Lisp is best as a teaching aid to introduce common high-level language concepts, in a way where it's clear how they all actually work in a familiar syntax- because it's Lisp nearly all the way down. (No black boxes.)

Most other languages suffer from a "trust me" problem, where students are taught what complicated things do but have to take it as gospel because they can't read the implementation, so they end up with high level concepts but no idea what's really going on to make those work, and a vague belief that "underneath" is more complicated and mysterious than it has to be. (Black boxes abound.) Indeed some students struggle to understand high-level concepts until they can see the mechanism.

[tsimionescu]

I think their point was that teaching Lisp in a compilers class is a good way to avoid having to discuss parsing in-depth.

[vngzs]

I'm fairly conflicted about this. While I believe that learning C teaches bad habits - manual memory management tends to account for some absurd percentage (70-80%) of CVEs in modern programs - it's also unquestionably tethered to the history of software, and a majority of the immense foundation of tooling on a Linux system is authored in C.

There is a terrific benefit to learning on a platform where you can not only look up documentation within the system (man pages), but also "dig deep" into the code of any particular piece of the system you are interested in. So in learning C, you gain access to the body of knowledge contained in a Linux system, or contained in a BSD, and when you get curious about something like "These loops and conditionals are all fine and well, but how does a window actually get drawn to my screen?" you have everything at your fingertips to go and answer it.

Is that connection to the machine possible without learning C? You could use a toy operating system written in something else, but you miss out on the honesty that comes from teaching the same system that people are actually using (or at least able to use).

I think Go might not be an unreasonable alternative. It shares C's philosophical heritage, removes the need for manual memory management, and is capable of exposing a student to pointers, creating images, and HTTP communication all within the stdlib and the first chapter of the official book. The only downside, as I see it, is that one would need to additionally learn something like Rust to be able to apply the concepts to things like kernel drivers and close-to-the-metal programming.

[tsimionescu]

Go sounds like the worse of both worlds from a teaching point of view: too high level if you want to understand what the machine is doing; but inheriting almost all of C's bad ideas that the GP was complaining about (except for manual memory management).

[fsckboy]

> learning C teaches bad habits - manual memory management tends to account for some absurd percentage (70-80%) of CVEs in modern programs

this is a garbled thought. The average person may have trouble with manual memory management, and C requires some manual memory management (the stack is automatic), but that's not C teaching bad habits.

You can learn to do manual memory management in C, because C teaches manual memory management.

that doesn't make manual memory management a good idea for the average programmer, but that's not C's fault.

experience with C teaches good manual memory management in the same way that working with sharp knives teaches good knife management. Do professional people get cut with sharp knives? yes. Are sharp knives a good idea? yes. All the time for everybody!? nope

[mytailorisrich]

The point is not to tech "C'isms" but to teach how computers and software work at low level. Even an introduction to an assembly language would be helpful. Higher level languages still perform these tasks but hide them from the user. Even if most people will end up using a high level language, having an understanding of what is going on and of how things work "under the hood" is invaluable.