Compiled vs. interpreted is intended there to mean something a little different than runtime behaviors.
Compiled - source files are run through a compiler which produce some output file that's then run. With C or Java you run the .c or .java file. C compiles to an executable, Java compiles to byte code.
Interpreted - source is fed to an interpreter which typically turns it into some kind of representation that's immediately run with no intermediary step on the part of the user/programmer. Perl, PHP, Ruby, Python, JS, TCL, etc. are typically run this way.
The terms are inherently a little muddy, since you can compile some interpreted languages to bytecode (common in PHP, and how JRuby/Jython are often run), and in theory could write a dynamic loader for C / Java to run them as interpreted - no idea if someone has been so perverse as to do it.
The behavior of a JRE or other runtime in loading bytecode/whatever to execute - JIT, AOT, or whatever has to do with how a runtime handles bytecode that's already been compiled from source and turns it to machine code to execute. The terms show up there also, but have a different meaning.
That's not what people are typically discussing when they talk about a compiled vs. interpreted language, and the author was correctly using the terms when referring to languages to draw the distinction in what a developer does (rather than what a runtime does, which is basically irrelevant to C).
In your explanation you even state "an interpreter which typically...". You talk about compilers and interpreters, which aren't part of the language.
The way you describe it, compiled or interpreted is a transitive property of a language, based on a popular way to utilize it.
If the definitions are "inherently a little muddy", then they're not very useful. Javascript and compile-to-JS languages have a ton of compilers written for them. Does that make them compiled or interpreted languages? How popular does compiling a language have to be for it to become compiled instead of interpreted?
It's no wonder that the parent prefers the strict definitions which lack this ambiguity.
I think the slide was correct in expressing the idea it wanted to express using terms that are commonly used in the sense they used, while the parent was being pointlessly pedantic in wishing the terms had some strict sense that was the only true definition.
Sometimes terms do have very strict definitions that are only correctly used in a limited sense. In the case of compiled vs. interpreted that's not the way things are and criticizing an introductory doc. for not adhering to an arbitrarily selected strict definition is pedantic and counter-productive.
No, seriously. All the lecture had to say to be correct and at least as useful is that C requires a build step unlike a lot of high level languages which don't.
Nothing about compilers vs interperters, none of that is relevant and the fact it's totally - incorrect is just icing.
This is not a terminology debating society, you're welcome to look up the definitions on wikipedia or take an introductory CS course if you're not sure what a compiler is or the difference between a language and a compiler/interpreter for it.
You're right that if the slide said C requires a build step unlike a lot of high level languages it would be correct. The terms "interpreted language" and "compiled language" have a sense in normal usage that I described, and I just verified that Wikipedia doesn't agree with you. There are no standards bodies that define formal definitions for those terms, common usage is how they are defined. All this is pointless pedantic quibbling, though, so it wasn't really worth my time, nor is it worth yours, really.
Compiled - source files are run through a compiler which produce some output file that's then run. With C or Java you run the .c or .java file. C compiles to an executable, Java compiles to byte code.
Interpreted - source is fed to an interpreter which typically turns it into some kind of representation that's immediately run with no intermediary step on the part of the user/programmer. Perl, PHP, Ruby, Python, JS, TCL, etc. are typically run this way.
The terms are inherently a little muddy, since you can compile some interpreted languages to bytecode (common in PHP, and how JRuby/Jython are often run), and in theory could write a dynamic loader for C / Java to run them as interpreted - no idea if someone has been so perverse as to do it.
The behavior of a JRE or other runtime in loading bytecode/whatever to execute - JIT, AOT, or whatever has to do with how a runtime handles bytecode that's already been compiled from source and turns it to machine code to execute. The terms show up there also, but have a different meaning.
That's not what people are typically discussing when they talk about a compiled vs. interpreted language, and the author was correctly using the terms when referring to languages to draw the distinction in what a developer does (rather than what a runtime does, which is basically irrelevant to C).