Yes, I get that Java is technically "interpreted". But the semantics of the language are not the same as the semantics of Python or other more common "interpreted" languages.
Try to think of it from the perspective of a new developer, who doesn't know the difference between the two. If you tell them that Java is not compiled, then they will be extremely confused when you tell them they have to compile it before using it. That's all I'm trying to say.
While "interpreted" is a part of the underlying infrastructure of Java, it's not a common paradigm of the language, and it does not service to Java to call it interpreted.
Conversely, I don't think it does much to call native languages just compiled, because they are so much more. I think embedded is more accurate for what your describing, helps keep the purity of those native languages, and also keeps the common semantics of "compiled" vs "interpreted" to mean what people typically think of when they hear those words, even if they aren't too knowledgeable of the paradigms/runtime properties themselves.
I'll agree the semantics are different, but the problem is that the misconceptions surrounding "interpreted" and "compiled" are made worse by this sort of pedantry.
When this comes up with Python (again, different...but then we're different from, say, Ruby), we simply define interpreted exactly as I did above, and explicitly separate out all other concerns, including but not limited to...
Performance,
Dependency linking,
Packaging,
...et cetera. The confusion ceases immediately.
Maybe "embedded" would be a better term for C/C++, but then again, maybe not. That brings its own baggage, just as much as "interpreted" and "compiled" does.
In any case, the issue is probably that "compiled" is poorly defined. Maybe we should be referring to source -> bytecode as transpiling? Maybe source->machine code should only be called assembling? Is C an assembled language?
In the least, Java devs would do well to say that they're a "compiled interpreted language," and then take the time to separate out the other concerns.
In the least, Java devs would do well to say that they're a "compiled interpreted language"
I can definitely agree with you here. These terms are murky, and Java is not purely one or the other, like Python or C++ are. Being more explicit about this in casual conversation might help to clear some of this confusion.
Thank you for such a thought-provoking thread and the good discussion!
These terms are murky, and Java is not purely one or the other, like Python or C++ are.
By your logic, Python isn't really "purely" one or the other, either. Compilation does happen. Dependencies are handled differently than Java, but the interpreter doesn't just run the source any more than Java's VM does; it (implicitly) compiles it to bytecode first.
Yeah, I think it's not "interpreted" that's not clear. I think it's "compiled" that's the problem.
Java, as a language, is not interpreted. Byte code is not the written language.
Typescript is mixed because Javascript is valid and not compiled in Typescript. It is more analogous to the C preprocessor, which is referred to as a macro language.
Scripting languages are not well defined, I utilize D as my scripting language, but it is fully compiled to machine code. Then you through in JIT and things get more confusing.
To better understand, it is best to look at the term for the time it was emerging. You had C and Bash, Lisp and Fortran. Languages like perl and php follow closer to the style for bash, these languages start execution at the file entry and don't define a special entry (main).
As for inferiority of scripting over a real language, we need to look at the level of understanding necessary to use the language.
Bash required writing your shell commands to a file then calling bash on it. Similarly languages like visual basic would add container iteration. C required learning pointers and memory layout. While scripts could easily build the description of a task, but would be limited in performance. Today machines are resource abundant and optimization techniques are identified.
C++ was long considered a compiled language, but it wasn't until Walter that the first compiler to build machine code instead of C existed.
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.
Yes, I get that Java is technically "interpreted". But the semantics of the language are not the same as the semantics of Python or other more common "interpreted" languages.
Try to think of it from the perspective of a new developer, who doesn't know the difference between the two. If you tell them that Java is not compiled, then they will be extremely confused when you tell them they have to compile it before using it. That's all I'm trying to say.
While "interpreted" is a part of the underlying infrastructure of Java, it's not a common paradigm of the language, and it does not service to Java to call it interpreted.
Conversely, I don't think it does much to call native languages just compiled, because they are so much more. I think embedded is more accurate for what your describing, helps keep the purity of those native languages, and also keeps the common semantics of "compiled" vs "interpreted" to mean what people typically think of when they hear those words, even if they aren't too knowledgeable of the paradigms/runtime properties themselves.
I'll agree the semantics are different, but the problem is that the misconceptions surrounding "interpreted" and "compiled" are made worse by this sort of pedantry.
When this comes up with Python (again, different...but then we're different from, say, Ruby), we simply define interpreted exactly as I did above, and explicitly separate out all other concerns, including but not limited to...
...et cetera. The confusion ceases immediately.
Maybe "embedded" would be a better term for C/C++, but then again, maybe not. That brings its own baggage, just as much as "interpreted" and "compiled" does.
In any case, the issue is probably that "compiled" is poorly defined. Maybe we should be referring to
source -> bytecodeas transpiling? Maybesource->machine codeshould only be called assembling? Is C an assembled language?In the least, Java devs would do well to say that they're a "compiled interpreted language," and then take the time to separate out the other concerns.
I can definitely agree with you here. These terms are murky, and Java is not purely one or the other, like Python or C++ are. Being more explicit about this in casual conversation might help to clear some of this confusion.
Thank you for such a thought-provoking thread and the good discussion!
Back at you!
By your logic, Python isn't really "purely" one or the other, either. Compilation does happen. Dependencies are handled differently than Java, but the interpreter doesn't just run the source any more than Java's VM does; it (implicitly) compiles it to bytecode first.
Yeah, I think it's not "interpreted" that's not clear. I think it's "compiled" that's the problem.
Pardon my ignorance, I really know very little about Python 😁 I had no idea it converted source to bytecode internally!
Just condense statements you've made.
'Java is an interpreted language, it is compiled'
Really the JIT is a system that confuses the definitions because this would be an accurate statement.
'Javascript is interpreted, the JIT compiles it'
Generally not every line is run through the JIT. You could even say
'D is a compiled language, it is interpreted at compile time'
But I think you are trying to bring Java into the same category as Python so you can use it to back your position that Python is a real language.
Java, as a language, is not interpreted. Byte code is not the written language.
Typescript is mixed because Javascript is valid and not compiled in Typescript. It is more analogous to the C preprocessor, which is referred to as a macro language.
Scripting languages are not well defined, I utilize D as my scripting language, but it is fully compiled to machine code. Then you through in JIT and things get more confusing.
To better understand, it is best to look at the term for the time it was emerging. You had C and Bash, Lisp and Fortran. Languages like perl and php follow closer to the style for bash, these languages start execution at the file entry and don't define a special entry (main).
As for inferiority of scripting over a real language, we need to look at the level of understanding necessary to use the language.
Bash required writing your shell commands to a file then calling bash on it. Similarly languages like visual basic would add container iteration. C required learning pointers and memory layout. While scripts could easily build the description of a task, but would be limited in performance. Today machines are resource abundant and optimization techniques are identified.
C++ was long considered a compiled language, but it wasn't until Walter that the first compiler to build machine code instead of C existed.