I tend to separate languages in 4 classes:

* Binary: Assembler. Self explanatory.

* Native: Compiled directly to machine code. (C, C++, Pascal, FORTRAN, etc.)

* Scripting languages: Compiled from text files at runtime. (Ruby, Python, JavaScript, VBScript, F#, Lua, etc.)

* Virtual machines: Compiled to intermediate bytecode and interpreted by a virtual machine at runtime. (Java, C#, VB.NET, J#.)

Quoted for truth. Although I would remove the first class, and talk about the last 3 as classes of high level languages.

For low level languages, it's a bit more complicated than just saying they're all binary. There's assembler. There's machine code. There's the internal instruction set that CISC machine code is translated to. That instruction set might have a human readable version too, used by CPU developers. Then while in the domain of CPU developers, you might as well talk about hardware description languages that the CPU developers code in. "Binary" isn't even descriptive of low level languages; VM byte-code, machine code, and internal RISC code could all be described as binary, the others listed can't.

* Virtual machines: Compiled to intermediate bytecode and interpreted by a virtual machine at runtime. (Java, C#, VB.NET, J#.)

C# is not interpreted by a virtual machine, and most implementations of Java are not either. Nor is VB.NET. I can't comment on J#, since I don't know it.

These languages are JIT. Yes, they're compiled into intermediate bytecode, but when you actually launch it, they are compiled into native machine code and run. They're not interpreted at runtime by a virtual machine.

I would still call that being interpreted. A JIT is an implementation detail of an interpreter.

Also, there are compilers for Python and many other "scripting" languages (so they're actually compiled straight to machine code). It's okay to point out that these scripting languages are often interpreted from a text file at runtime, but it's also important, given this thread's context, to point out that this isn't always the case, and there's nothing limiting these languages from being compiled into native machine code (well, the only limitation is that someone has to take the time to write such a compiler).

Indeed. And there are interpreters for compiled/native languages like C and C++. Like Cling. However, I would still call C and c++ native languages, and python an interpreted scripting language.