DEV Community

Discussion on: What common programming concept has the wrong name?

Collapse
 
codemouse92 profile image
Jason C. McDonald • Edited

Apparently, "compiled language". Nearly all languages are compiled in many situations to something, so it's a meaningless phrase.

"Interpreted language" (final result executed via some form of a software interpreter) vs. "assembled language" (final result executed directly by the CPU as machine code) is more useful. Python and Java are examples of interpreted languages, although both are compiled in some fashion. C++ and FORTRAN are examples of assembled languages.

And yes, the designations are murky. Interpreters exist for typically assembled languages, and (generally impractical) means exist to assemble typically interpreted languages to machine code.

EDIT: Based on this thread, I'll add one more: an interactive language is one that is primarily run through a REPL (interactive shell).

This should not be confused with an interpreted language, which simply has a software layer between the shipped files (sometimes, bytecode that was compiled to) and direct execution.

Also, dependencies don't even enter into this discussion; any language has to resolve them somehow on the target machine.

EDIT 2: This thread (and related conversations) led to this...

Collapse
 
sinewalker profile image
Mike Lockhart

Even machine code is interpreted by the processor's microcode, which is exchangeable on some processors and FPGAs. The machine executes nano-code on most processors these days, even RISC ones.

Collapse
 
chrisgseaton profile image
Chris Seaton

Python and Java are examples of interpreted languages ... and (generally impractical) means exist to assemble typically interpreted languages to machine code

But Java is assembled to machine code at runtime, and it's extremely practical. I'd say interpreting Java is impractically slow!

Collapse
 
elmuerte profile image
Michiel Hendriks • Edited

I'd say interpreting Java is impractically slow!

Which is true and why they created the JIT Compiler in Java 2.

Now days in a standard JVM process a lot of byte code is assembled to machine code. And a large part will be heavily optimized and recompiled to better machine code at runtime. That's why a JVM program quite often outperforms "native" languages, unless they are optimized by hand. (or after gathering enough trace information).

But calling Java an interpreted language is wrong. A common characteristic of interpreted languages is executing part of the code before running into a compile error.

Thread Thread
 
codemouse92 profile image
Jason C. McDonald • Edited

Sigh

I've been in this conversation about a dozen plus times now. Every person tries to make the same claim, "Java isn't interpreted," but then they have to move the targets and shuffle the definitions around to prove it.

If Java were an assembled language, the end result of your compilation would be a standalone executable binary consisting purely of machine code, which could be run by itself on any machine of the matching architecture. Java doesn't do this; end users have to have some sort of runtime on their machine which executes the .JAR file they shipped. Either the process was made arbitrarily more complex than it needs to be, or Java is not an assembled language. (Please pick one.)

It's a compiled-interpreted, purely on merit that it isn't an assembled language. Just because its compile/interpret process is so complicated that practically every Java developer has their own unique understanding, doesn't mean that it isn't compiled-interpreted.

And, it's worth mentioning, interpreted does NOT mean slow, bad, or unprofessional! I think a lot of people are afraid if they admit that Java is compiled-interpreted, they'd be admitting it's somehow "bad," but that is most assuredly not the case.

A common characteristic of interpreted languages is executing part of the code before running into a compile error.

Nope. That's an interactive language...so, I guess that's another entry to this list?

Thread Thread
 
elmuerte profile image
Michiel Hendriks

If your claim was that an assembled language has as shippable artefact hardware machine code, then I would not make a big point out of it. But...

C and C++ programs also depend on a common runtime. They do not work without it.

You can include the Java runtime with Java application if you want.

The runtime for .Net applications is included with Windows these days, so can ship your compiled C# program without users needing to get a runtime. By your definition is it then an assembled language or an interpreted language.

Sun made hardware which natively runs Java bytecode. It was nog a big success, but it could run your .jar directly on the CPU. So it's an assembled language after all.

Thread Thread
 
codemouse92 profile image
Jason C. McDonald • Edited

The runtime for .Net applications is included with Windows these days, so can ship your compiled C# program without users needing to get a runtime. By your definition is it then an assembled language or an interpreted language.

C#, C++, and C are three different languages, btw.

As to C++ and C, they often rely on dynamically linked libraries, but dependencies are an unrelated issue for any language. You'll note I never brought it into the Java discussion; going into dependencies is another moving-the-target distraction tactic (don't worry, I won't blame you for inventing it...it's been in use for a while.)

C++ and C can produce binaries which require no dependencies, simply by avoiding the standard library.

That said, I will admit to using the wrong term a moment ago; runtime is a dependency library, whereas what I'm referring to with Java is the software responsible for executing the bytecode on the target machine.

Dependencies shouldn't enter into this discussion, all languages (practically speaking) have to be able to resolve dependencies.


Sun made hardware which natively runs Java bytecode.

Also a case of moving-the-target. I already stated earlier that there were impractical means by which virtually any assembled languages can be interpreted, and virtually any interpreted/interpreted-compiled languages can be assembled. This does not count because it has no bearing on standard deployment.


The inescapable point: Java is, for all practical intents and purposes, never assembled to a machine code binary file, such that it can be shipped to an end-user (w/ or w/o dependency libraries compiled to the same), and executed directly on a standard Intel, AMD, or ARM processor without needing an additional program to interpret (or, if you want to get pedantic, AOT/JIT-compile) the (byte)code.

An interpreted language has a software layer between the final, shipped result of compilation and its ultimate execution on the target machine.

Ergo, Java is compiled-interpreted. It is NOT assembled. It is also NOT interactive. (But, yes, it's still a real language.)

Collapse
 
codemouse92 profile image
Jason C. McDonald • Edited

No, Java is not assembled to machine code at any point, except in extraordinary implementations. It is compiled to bytecode, which is what is run through the interpreter, often the JVM.

EDIT: I omitted two words by mistake: at any point before shipping. JIT-compiling is pretty typical for interpreted languages; it doesn't make it an assembled language. So, yes, runtime still counts (towards interpreted.) My bad.

This was discussed and rehashed in some detail here:

Thread Thread
 
chrisgseaton profile image
Chris Seaton • Edited

Java is not assembled to machine code at any point, except in extraordinary implementations

No, common implementations do it. Run Java with -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly to see it assemble your Java code to machine code.

Here's the assembler in HotSpot for example github.com/AdoptOpenJDK/openjdk-jd....

And see this blog post about how another Java compiler compiles and assembles Java to machine code chrisseaton.com/truffleruby/jokerc....

I used to work at Oracle on compilers and assemblers for Java and other languages.

Thread Thread
 
badrecordlength profile image
Henry 👨‍💻 • Edited

Java is not assembled to machine code at any point

I'm sorry, but this is just plainly incorrect. Even an interpreter compiles down to machine code before execution, it just does so line by line as it executes instead of before execution starts and all at once. Do you think a CPU can understand bytecode?

Thread Thread
 
codemouse92 profile image
Jason C. McDonald

That's a misinterpretation of "compiles". The interpreter executes the bytecode, but it is not producing an actual standalone executable binary of assembly code. If it did, why on earth would Java deployment always involve the added trouble of ensuring the Java interpreter were installed on target machines, and then have the interpreter execute the .JAR?

"Runtime 'compiling'" is called "interpreting," and it really shouldn't be confused with compiling.

Thread Thread
 
badrecordlength profile image
Henry 👨‍💻 • Edited

Definition of compile:

Convert (a program) into a machine-code or lower-level form in which the program can be executed.

That's its quite literal definition, so any language which eventually is executed by a CPU (so all of them), are compiled at some stage. The topic of "Compiled VS Interpreted" languages is really about how they are compiled, generally "compiled" languages are compiled before execution and "interpreted" as they are executed.

This doesn't take away from the fact that saying "Java is never assembled to machine code" is wrong because Java wouldn't be able to be executed by the CPU at all if it wasn't. I don't mean for this to come across as combative (if that's how its been ahem interpreted), I think healthy and reasoned debate on such topics is good.

I'll end by quoting a blog post already posted in this thread where former Oracle compiler dev Chris Seaton explains how Java compiles bytecode to machine code:

To run your Java program then the JVM interprets the bytecode. Interpreters are often a lot slower than native code running on a real processor, so the JVM at runtime can also run another compiler, this time compiling your bytecode to the machine code that your processor can actually run.

Thread Thread
 
codemouse92 profile image
Jason C. McDonald • Edited

Curious for your source. Here's the one most people work off now.

A compiler is a computer program that translates computer code written in one programming language (the source language) into another language (the target language).

I chose to specifically use the term assemble for compiling to machine code, since "compiling to bytecode is still compiling!" is a favorite distraction technique employed in the Java debate.

This doesn't take away from the fact that saying "Java is never assembled to machine code" is wrong because Java wouldn't be able to be executed by the CPU at all if it wasn't.

EDIT: Okay, some confusion may have resulted from an unintentional omission on my part: earlier, I meant to type Java is not compiled to machine code at any point before shipping, which if you look at context, is what I've been saying all along. Just correcting that here.

All an interpreter ever does is to covert to machine instructions in some fashion or another, either just before execution (AOT-compiler), as it executes (JIT-compiler or traditional interpreter, depending on implementation). It's still relying on that software layer. That's all I've been claiming.

If you read my posts again, I've been repeatedly making the point that an assembled language ships a binary of machine code. If it has to be AOT/JIT-compiled (interpreted) on the end-user's machine, it's an interpreted language.

Also, to requote Chris Seaton...

To run your Java program then the JVM interprets the bytecode. Interpreters are often a lot slower than native code running on a real processor, so the JVM at runtime can also run another compiler, this time compiling your bytecode to the machine code that your processor can actually run. (Emphasis mine.)

Ergo, interpreted. Thanks for providing an official source to prove my point all along.

No wonder so many people are confused by "interpreted," "compiled," "assembled," "machine code," et al. The terms keep getting changed (esp. by various Java devs I've spoken to over the years) to dodge the obvious. :(

Thread Thread
 
codemouse92 profile image
Jason C. McDonald • Edited

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.

Thread Thread
 
badrecordlength profile image
Henry 👨‍💻

Here's my source
defintion of compile
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.

Thread Thread
 
codemouse92 profile image
Jason C. McDonald • Edited

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.

Thread Thread
 
natonathan profile image
Nathan Tamez

Put simply, do you ship machine code?
Yes: it's compiled
No: it's interpreted

Thread Thread
 
codemouse92 profile image
Jason C. McDonald • Edited

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.

Thread Thread
 
natonathan profile image
Nathan Tamez

Just bear in mind the most in academia use the term Compiled, as the term assembled, means to assemble assembly to machine code.

Thread Thread
 
codemouse92 profile image
Jason C. McDonald • Edited

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.