Just a reminder that java and JVM were both made be years before Jazelle or anything like it came about.
This is why most people take Java to be interpreted, and it was designed to be interpreted.
Doesn't matter. Like even a little. There exists a hardware spec.
Anyway, here bud, user perspective.
Interpreted: code executes from human readable project.
Compiled: user compiles project, then runs output file.
From a user perspective it's that extra step that matters.
FYI "most people" is quite a stretch. I'll grant you that it's a debated topic. But the actual issue of this topic and why we're discussing it. Is that "interpreted" is actually not well defined, as people seem to think.
Some people consider vm languages like Java and C# interpreted because they typically run in vms, but there's really no reason they can't run on baremetal; we in fact proved Java can.
For me, this makes the most clear definition of the two, the user perspective I posited before. Because I can create an environment that all languages are interpreted based on the vm/emulator situation. You could certainly compile anything down if you try hard enough, as you stated before.
So from a user perspective. How do your execute your code. Does your human readable code get compiled down to lower level code, and then you get to run it? It's compiled.
Do you send your human readable code directly to an interpreter? Interpreted.
I find your tone off-putting. There's no reason to be abrasive.
To the point people are making, they are correct. The fact an application is distributed in a way that's human readable is a minor distinction. That means more to the humans than the computer. They are all loading an application which does not contain native machine code and jitting it by the time it is executing. Node and Python are no more interpreted than Java is.
The major distinction is whether a language runtime needs to be preinstalled or distributed with an application. In that regard, c/c++/golang are in one category, and python/node/java/c# are in another
Well again. There exists a hardware spec for Java, you can run it natively with the correct hardware. So that goes back to my point of emulators. Just because you are virtualizing that hardware in most cases, does not mean you don't need to compile it down for that hardware.
In that regard c and Java are effectively the same. You just happen to have the hardware to run what gcc will shit out.
I believe you misinterpreted my human readable distinction. I was trying to explain what you pass through for the actual execution.
With traditionally accepted interpreted languages, you don't preform any extra steps to execute your code. Just throw it through the interpreter.
With non interpreted, you have to compile it down before the code will execute. That's how Java works. I also accept that some people claim Java to be interpreted, but in that regard you have a very gray area on what "interpreted" actually means.
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.
Just a reminder that java and JVM were both made be years before Jazelle or anything like it came about.
This is why most people take Java to be interpreted, and it was designed to be interpreted.
Doesn't matter. Like even a little. There exists a hardware spec.
Anyway, here bud, user perspective.
Interpreted: code executes from human readable project.
Compiled: user compiles project, then runs output file.
From a user perspective it's that extra step that matters.
FYI "most people" is quite a stretch. I'll grant you that it's a debated topic. But the actual issue of this topic and why we're discussing it. Is that "interpreted" is actually not well defined, as people seem to think.
Some people consider vm languages like Java and C# interpreted because they typically run in vms, but there's really no reason they can't run on baremetal; we in fact proved Java can.
For me, this makes the most clear definition of the two, the user perspective I posited before. Because I can create an environment that all languages are interpreted based on the vm/emulator situation. You could certainly compile anything down if you try hard enough, as you stated before.
So from a user perspective. How do your execute your code. Does your human readable code get compiled down to lower level code, and then you get to run it? It's compiled.
Do you send your human readable code directly to an interpreter? Interpreted.
Basically, 2 step vs 1 step process.
I find your tone off-putting. There's no reason to be abrasive.
To the point people are making, they are correct. The fact an application is distributed in a way that's human readable is a minor distinction. That means more to the humans than the computer. They are all loading an application which does not contain native machine code and jitting it by the time it is executing. Node and Python are no more interpreted than Java is.
The major distinction is whether a language runtime needs to be preinstalled or distributed with an application. In that regard, c/c++/golang are in one category, and python/node/java/c# are in another
Well again. There exists a hardware spec for Java, you can run it natively with the correct hardware. So that goes back to my point of emulators. Just because you are virtualizing that hardware in most cases, does not mean you don't need to compile it down for that hardware.
In that regard c and Java are effectively the same. You just happen to have the hardware to run what gcc will shit out.
I believe you misinterpreted my human readable distinction. I was trying to explain what you pass through for the actual execution.
With traditionally accepted interpreted languages, you don't preform any extra steps to execute your code. Just throw it through the interpreter.
With non interpreted, you have to compile it down before the code will execute. That's how Java works. I also accept that some people claim Java to be interpreted, but in that regard you have a very gray area on what "interpreted" actually means.
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.