I'm a Systems Reliability and DevOps engineer for Netdata Inc. When not working, I enjoy studying linguistics and history, playing video games, and cooking all kinds of international cuisine.
At least two transformations happen for any code to run on your computer, transformation from the source to machine code, and transformation from the machine code to actual state changes internal to the hardware that do what you want.
Some languages add an additional transformation from the source to an intermediary code that then gets translated to machine code (C and FORTRAN translate to assembly before machine code, Java goes to JVM bytecode, C# goes to CIL bytecode, etc), and some hardware adds an extra layer between the CPU instructions and the internal state changes (most modern x86 CPU's translate from the high-level x86 'machine code' to a different lower-level machine code specific to the micro architecture), but both cases still fit that 'two transformations' model at a large scale.
The classical differentiation between compiled and interpreted languages is when the series of transformations from source code to machine code actually happens. For compiled languages, it's done ahead of time. For interpreted languages, it's done at runtime (either while executing, or in a single pass right before execution). Some languages though don't quite fit this concretely (Java - which may be compiled directly to machine code, or might be compiled to JVM byte code which is then transformed to machine code at runtime - is a good example of such a language).
These days though, the primary differentiation most people think of is that interpreted languages have the option of some kind of interactive REPL, while compiled languages usually do not. Pretty much every language can be classified in this manner, though it can be fuzzy here too (see for example: github.com/evmar/c-repl).
Ultimately though, it's largely irrelevant these days unless you're doing cross-builds or porting to a new platform (languages that fit the classical definition of being 'compiled' tend to be easier to use in both cases). Yeah, it has some impact on how you might develop and debug, but that impact isn't anywhere near as binary as the terminology implies, and may even vary by individual workflow.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
At least two transformations happen for any code to run on your computer, transformation from the source to machine code, and transformation from the machine code to actual state changes internal to the hardware that do what you want.
Some languages add an additional transformation from the source to an intermediary code that then gets translated to machine code (C and FORTRAN translate to assembly before machine code, Java goes to JVM bytecode, C# goes to CIL bytecode, etc), and some hardware adds an extra layer between the CPU instructions and the internal state changes (most modern x86 CPU's translate from the high-level x86 'machine code' to a different lower-level machine code specific to the micro architecture), but both cases still fit that 'two transformations' model at a large scale.
The classical differentiation between compiled and interpreted languages is when the series of transformations from source code to machine code actually happens. For compiled languages, it's done ahead of time. For interpreted languages, it's done at runtime (either while executing, or in a single pass right before execution). Some languages though don't quite fit this concretely (Java - which may be compiled directly to machine code, or might be compiled to JVM byte code which is then transformed to machine code at runtime - is a good example of such a language).
These days though, the primary differentiation most people think of is that interpreted languages have the option of some kind of interactive REPL, while compiled languages usually do not. Pretty much every language can be classified in this manner, though it can be fuzzy here too (see for example: github.com/evmar/c-repl).
Ultimately though, it's largely irrelevant these days unless you're doing cross-builds or porting to a new platform (languages that fit the classical definition of being 'compiled' tend to be easier to use in both cases). Yeah, it has some impact on how you might develop and debug, but that impact isn't anywhere near as binary as the terminology implies, and may even vary by individual workflow.