Update: So, reading over the thread again, I had to put in a couple of edits to my posts. I missed a couple of words in reading, and also in writing. My mistake. So, apologies to @chrisgseaton
for missing his point.
Java is (sometimes/often) compiled to machine code on the end-user computer. This is referred to as Ahead-Of-Time (AOT) Compiled. Under other circumstances, it may be Just-In-Time (JIT) Compiled. This technically contrasts with a "traditional" interpreter, which will execute the bytecode directly; however, the difference between a JIT Compiler and a "traditional" interpreter often come down to implementation; it may be hard to distinguish without knowing implementation details.
In any case, as I said originally, an interpreted language still places a software layer between the shipped end result and the machine code; an AOT-compiler, JIT-compiler, and "traditional" interpreter all fulfill this requirement, which clearly marks Java as an interpreted (granted, interpreted-compiled) language.
This is still in contrast to assembled languages, say, C and C++, in which the executable machine code file is the shipped end result.
The difference all comes down to what is shipped to the end-user.
(Reminder: runtime dependency resolution is irrelevant to this topic.)
Interpreted (or interpreted-compiled) languages are not implicitly inferior nor superior to assembled languages. They are merely different.
Here's my source
I'd be curious as to where you got the data that "most people" use the first sentence of the wikipedia page for compiler as the definition. Also, the second sentence on that very same page is almost verbatim the definition I gave anyway:
The name compiler is primarily used for programs that translate source code from a high-level programming language to a lower level language (e.g., assembly language, object code, or machine code) to create an executable program.
So I think arguing about that is a bit silly. From the tone of your response it seems as though you think that I'm some kind of Java fanboy trying to obfuscate the truth using technicalities, far from it. In fact, my favourite language to use day-to-day is Python. It is however an unavoidable fact that Java is almost always faster than Python at runtime, due in big part to the way that it is compiled.
Saying "HAH! The quote you gave me has the word interpreter in it, I win!" is not really a productive way of having a sensible discussion. I was only ever trying to correct you on the omission that you have since edited into the last response, Java is in fact compiled/assembled to machine code before execution.
It feels like you have misinterpreted my intentions greatly, I'd rather not have this discussion devolve into petty "my language is better than your language" mudslinging, in which I have no interest in partaking.
I'd be curious as to where you got the data that "most people" use the first sentence of the wikipedia page for compiler as the definition.
From mass usage of the term. Ironically some of them are well-meaning Java devs who assert that compiling to bytecode implicitly makes the language "compiled" in the same way that assembling to machine code makes the language "compiled". Thus why I avoid the term "compiled language".
Compiled has come to mean many things. Typescript is compiled to Javascript. Python is compiled to Python bytecode. Java is compiled to Java bytecode, which is compiled (assembled) to machine code later. C++ is compiled to object code, which is compiled (assembled) to machine code. You see where this gets confusing? That's why I took the care to use "assembled," from the C and C++ term for the part of the compilation toolchain that converts object code to machine code.
You can compile to anything, but you can only assemble to machine code. I'm using "assembled" to unobfuscate the difference, instead of trying to unring the bell wherein the old definition of "compiled" became wholly antiquated.
From the tone of your response it seems as though you think that I'm some kind of Java fanboy trying to obfuscate the truth using technicalities, far from it.
I'm just rather worn out by the sheer mass of Java developers who have a knee-jerk "but but but" to the obvious point that Java is an interpreted language by my initial definition (JIT-compiled still qualifies). There seems to be an insecurity many Java devs have, that somehow their language is "terrible", so they have to find ways to defend its validity to themselves. (Which is unnecessary - it was already valid, and not terrible.)
You may well have been correcting the mis-point I produced with my omission, and I mistook it for the usual "but but but." It read the same to me, but if that's not your goal, I concede as such.
I'd rather not have this discussion devolve into petty "my language is better than your language" mudslinging, in which I have no interest in partaking.
Happily, as I've said all along, interpreted is not inherently inferior to anything. I'm a Python and C++ developer. I never even implied that Java is inferior, merely that it is not assembled. (I'm not even a fan of Java, as it were, but I feel no need to decry it; it serves its purpose well, regardless of my personal preferences.)
It is however an unavoidable fact that Java is almost always faster than Python at runtime, due in big part to the way that it is compiled.
Unrelatedly, I'd be curious what the benchmark between AOT-compiled Java and pre-compiled (to bytecode) Pypy would be. CPython usually loses benchmarks.
Compiled is really, really confusing, because of the varying usage. As I said, you can compile to another language, to bytecode, to object code, to machine code...but you can only assemble to machine code.
I'm getting this distinction from the conventional compilation toolchain, btw. We compile first to some form of intermediary code, and then we assemble to the machine code.
Oh, I'm well aware. I've historically used it the same...in fact, I'd prefer if that's all it meant.
Unfortunately, that distinction is lost on most...and sadly, part of that is from communities surrounding some interpreted languages misusing the term "compiled" for so long to dodge the fact their language is interpreted.
That, in turn, is because "interpreted" has been used in an almost derogatory manner for so long.
Language evolves, and not always for the better. Trying to cram the linguistic refrigerator biscuit dough back in the tube is a losing fight.
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.
Update: So, reading over the thread again, I had to put in a couple of edits to my posts. I missed a couple of words in reading, and also in writing. My mistake. So, apologies to @chrisgseaton for missing his point.
Java is (sometimes/often) compiled to machine code on the end-user computer. This is referred to as Ahead-Of-Time (AOT) Compiled. Under other circumstances, it may be Just-In-Time (JIT) Compiled. This technically contrasts with a "traditional" interpreter, which will execute the bytecode directly; however, the difference between a JIT Compiler and a "traditional" interpreter often come down to implementation; it may be hard to distinguish without knowing implementation details.
In any case, as I said originally, an interpreted language still places a software layer between the shipped end result and the machine code; an AOT-compiler, JIT-compiler, and "traditional" interpreter all fulfill this requirement, which clearly marks Java as an interpreted (granted, interpreted-compiled) language.
This is still in contrast to assembled languages, say, C and C++, in which the executable machine code file is the shipped end result.
The difference all comes down to what is shipped to the end-user.
(Reminder: runtime dependency resolution is irrelevant to this topic.)
Interpreted (or interpreted-compiled) languages are not implicitly inferior nor superior to assembled languages. They are merely different.
Here's my source
I'd be curious as to where you got the data that "most people" use the first sentence of the wikipedia page for compiler as the definition. Also, the second sentence on that very same page is almost verbatim the definition I gave anyway:
So I think arguing about that is a bit silly. From the tone of your response it seems as though you think that I'm some kind of Java fanboy trying to obfuscate the truth using technicalities, far from it. In fact, my favourite language to use day-to-day is Python. It is however an unavoidable fact that Java is almost always faster than Python at runtime, due in big part to the way that it is compiled.
Saying "HAH! The quote you gave me has the word interpreter in it, I win!" is not really a productive way of having a sensible discussion. I was only ever trying to correct you on the omission that you have since edited into the last response, Java is in fact compiled/assembled to machine code before execution.
It feels like you have misinterpreted my intentions greatly, I'd rather not have this discussion devolve into petty "my language is better than your language" mudslinging, in which I have no interest in partaking.
From mass usage of the term. Ironically some of them are well-meaning Java devs who assert that compiling to bytecode implicitly makes the language "compiled" in the same way that assembling to machine code makes the language "compiled". Thus why I avoid the term "compiled language".
Compiled has come to mean many things. Typescript is compiled to Javascript. Python is compiled to Python bytecode. Java is compiled to Java bytecode, which is compiled (assembled) to machine code later. C++ is compiled to object code, which is compiled (assembled) to machine code. You see where this gets confusing? That's why I took the care to use "assembled," from the C and C++ term for the part of the compilation toolchain that converts object code to machine code.
You can compile to anything, but you can only assemble to machine code. I'm using "assembled" to unobfuscate the difference, instead of trying to unring the bell wherein the old definition of "compiled" became wholly antiquated.
I'm just rather worn out by the sheer mass of Java developers who have a knee-jerk "but but but" to the obvious point that Java is an interpreted language by my initial definition (JIT-compiled still qualifies). There seems to be an insecurity many Java devs have, that somehow their language is "terrible", so they have to find ways to defend its validity to themselves. (Which is unnecessary - it was already valid, and not terrible.)
You may well have been correcting the mis-point I produced with my omission, and I mistook it for the usual "but but but." It read the same to me, but if that's not your goal, I concede as such.
Happily, as I've said all along, interpreted is not inherently inferior to anything. I'm a Python and C++ developer. I never even implied that Java is inferior, merely that it is not assembled. (I'm not even a fan of Java, as it were, but I feel no need to decry it; it serves its purpose well, regardless of my personal preferences.)
Unrelatedly, I'd be curious what the benchmark between AOT-compiled Java and pre-compiled (to bytecode) Pypy would be. CPython usually loses benchmarks.
Put simply, do you ship machine code?
Yes: it's compiled
No: it's interpreted
I'd say,
Yes: it's assembled.Compiled is really, really confusing, because of the varying usage. As I said, you can compile to another language, to bytecode, to object code, to machine code...but you can only assemble to machine code.
I'm getting this distinction from the conventional compilation toolchain, btw. We compile first to some form of intermediary code, and then we assemble to the machine code.
Just bear in mind the most in academia use the term Compiled, as the term assembled, means to assemble assembly to machine code.
Oh, I'm well aware. I've historically used it the same...in fact, I'd prefer if that's all it meant.
Unfortunately, that distinction is lost on most...and sadly, part of that is from communities surrounding some interpreted languages misusing the term "compiled" for so long to dodge the fact their language is interpreted.
That, in turn, is because "interpreted" has been used in an almost derogatory manner for so long.
Language evolves, and not always for the better. Trying to cram the linguistic refrigerator biscuit dough back in the tube is a losing fight.