Comment by Jason Knight on "Is JavaScript a compiled language or an interpreted language?"

The line between "interpreted" and "VM" is, well... often meaningless if you're talking things like the JVM and/or P-Code. Execution of JavaScript (and PHP works in a similar fashion) is handled by a two stage model, first the code is parsed into an intermediary byte-code, and then the interpreter runs the bytecode.

It is during the byte-code generation stage that hoisting occurs as "labels" (function names, variable names, and so forth) have pointers allocated, something made a bit easier in JavaScript by the fact that deep down everything is an object, so you just create a pointer to a memory block of the size required by the function/variable/whatHaveYou.

That's why whenever they call things like .NET and JAVA "Virtual Machines" I cry BULL-***ING-SHIT! They are interpreters, nothing more nothing less. Compiling to an intermediate bytecode doesn't change that -- if it did most every major ROM Basic from the late '70's and early '80's would in fact be "Virtual Machines" -- when they quite clearly are not.

Hell, by default most ROM Basic's don't even store the code verbosely in RAM as you type it in. They symbols are tokenized whenever you enter a line, and de-tokenized when you run 'list'. That's why default most ROM Basic files -- like GW-BASIC's .bas files -- are binary gibberish anyplace that isn't a string or comment! You have to save the file with a special parameter to force saving as legible ASCII.

In any case, that's what JavaScript engines do. The Engines turn it into an intermediate bytecode first before it even tries to run it. Since the "namespace list" is just an array of pointers with a few flags thrown on top, when an unknown token is encountered it is stored on the list with a null pointer. When it is actually defined that pointer structure is overwritten with the proper value -- and boom, it works even though you defined it after you call it.

If you are actually interested in these types of internals, you might want to go back to the "real source" of pretty much all compiler design. Whilst most 'interpreted' languages aren't properly compiled to native code, more often than not they ARE compiled to an intermediate bytecode -- which is what mostly makes .NET and JAVA nothing 'special' despite the wild claims to the contrary... and that means going to the best (though really old) source about building compilers:

github.com/tpn/pdfs/blob/master/Compiler%20Constr…).pdf

Don't forget, that there is an optimization-compiler, which can do a translation to real machine code with basic variable types. If a code runs a thousand times and a variable is always int, it will ideally be optimized to int instead of using the Number (or even Oddball) class.

Marco Alka True, but I wanted to leave low level optimizations out of the explanation, was getting a bit wordy as-is.

The intermediate bytecode in Java and .NET is further compiled and optimised by their respective runtime engines (which allows them to achieve near-native speeds once the runtime is "warmed up"). V8 uses similar techniques - it just has more steps to go through because it needs to turn the source code into some kind of intermediate representation, when compiled Java is already sort of there.

Chris Armstrong True, but how is that any different at the low-level than having 'functions' that correspond to native code? The monkey wrench thrown in the works by more complex languages is user defined functions and variables of 'whatever name you want'. -- but deep down under the hood they are the same basic concept. They are interpreters; they may be enhanced by JIT compilation, bytecode caching, code order optimization, and so forth. Doesn't change what they REALLY are -- interpreted. The major difference is realtime interpretation of all code, or pre-interpretation for optimization... and if "VM" means the latter, it's not THAT different from how Microsoft BASIC back when we had line-numbers functioned under the hood -- since it did the bytecode step every time you entered a new line of code. More complex semi-compilers like ZBasic weren't called VM's, nor were Pascal's P-Code.

It's just at some point somebody needed some new sick buzzword to slap on it whilst avoiding the negative connotation "interpreted" came to have over the years.

... and I REALLY hate when new names are slapped on old concepts just so some marketing scammer or snake oil doctor can pimp some warez. Dimestore hoodoo, five and ten voodoo. It trips my bullshit alarm, and after four decades of programming my BS sensor has been refined to a razor's edge.

It borders on the same types of nonsense used to perpetuate the idea that programming is "hard" or "something only for smart people" through the use of needlessly cryptic syntax, duplicitous language, obtuse definitions, and disingenuous card stacking of examples. From C's needlessly convoluted syntax, to the marketspeak double-talk of every W3C "specification" its like the industry tries to be as intentionally exclusive as possible.

Particularly when some 'specifications' read like they were written in Finnish, translated to Japanese by a Russian lawyer, then Google translated back to English. See something as moronically simple as HTML and how 90%+ of the people using it have ZERO damned clue what they're doing or what the specification is actually saying! Admittedly if there were a few less jackasses saying "it's not important" or "it's not a real programming language" we'd have a lot less broken bloated inaccessible train wreck laundry lists of how NOT to build a website to deal with; much less nobody would be STUPID enough to use ignorant halfwit mouth-breather specials like bootcrap or jquery.

But in terms of current specs, more than half the garbage out there might as well read:

Glorious sunset of my heart was fading. Soon the super karate monkey death car would park in my space. But Jimmy has fancy plans, and pants to match.

Given the choice of language and constant introduction of new sick buzzwords to "ancient" ideas and methodologies are concerned. That's why most of the time explaining new technology to old-timers is nothing more than an endless steam of similes.

... and no, I did not just mistype smilie.

Although this is starting to verge on to off-topic, I think we can agree, that yes, JavaScript as much as the IL of Java and .NET are all interpreted languages. Its just that IMHO you get value from using a well-designed IL, which can deliver other benefits to the developer. Things such as reducing the need to recompile on each architecture they target, creating opportunities for targeting optimisations to multiple architectures, and still being much quicker to translate to machine code than the high level languages they originated from.

I work primarily in JavaScript (an interpreted language with a huge install base and massive mindshare among developers) but I get value out of compilation steps, such as:

allowing me to write code in one dialect of JavaScript but target disparate interpreter engines
use more heavily typed languages like Reason, TypeScript or Flow to add type safety to my code
JSX -> JS translation, which lets me write in a mini-DSL more easily for things like reactive front-end programming in React or similar frameworks

The end result might be more JavaScript which needs to be interpreted, but I've gained plenty in the process.

Search Hashnode