What is the difference between compiled language for interpreted language?

Question

What difference from compiled language to interpreted language, and what advantages to one another?

Answer 1

Correct terminology

First, there is no such thing as an interpreted or compiled language. Except for some characteristic or specification, all can be interpreted and/or compiled. There are language implementations that can interpret or compile code written in that language.

Of course using these question terms cannot be considered totally wrong since everyone understands its meaning, but it strictly is.

Even so, in these moments we feel the shame of others for having the entries in Wikipedia. And they try to explain the inexplicable. And they do it in a very wrong way. Probably by making it very lay to think that it is true. A more detailed analysis indicates that the definitions proposed there would make other enshrined definitions impossible. Not entirely wrong, but they have important inaccuracies. The Portuguese version is worse.

Summary

To interpretation occurs when the use (commonly the execution) of the code occurs together with the analysis of the same.

To compilation is the process of analysis and possibly transformation of the source code into target code, that is, the use (execution, for example) takes place in a later separate process, although not so later.

So interpreted applications need source code while compiled ones only need target code to work.

Interpreting

Interpretation takes place upon the source code of the written application. There are several ways of interpreting, which is the analysis of the code at the time of execution. This can be done in small parts (lines, for example) or in larger parts, functions or files.

In this process code analysis is done every time it needs to run, and errors are only detected during execution. This is a fundamental difference.

Interpreter

Obviously, to execute interpreted code you need interpreter software. And, astonishingly, it can be interpreted too, even if it is not common.

This interpreting software controls the interpretation workflow and ensures the execution of what is necessary.

It is common for interpretation to involve a compilation step not only for analysis but also for code transformation. This can occur in whole or in parts. But it will occur on demand and it will occur at the discretion of the interpreter. To tell the truth it is not easy to make an interpretation without some form of compilation, even if rudimentary.

In some cases this compilation is often called just-in-time. But it is important to differentiate from the traditional compilation which has a different function. I prefer to consider this more a compilation than an interpretation.

Nebulous area

It is important to understand that interpretation involves a compilation process that can even transform one source code into another target code. The big difference is that after this compilation there is already an action taking place. So even if a transformation occurs, errors are only detected at the time of execution or a few moments before it actually starts, but within the same process.

There are those who think that if there is this process of compiling the source into target code, especially if it is native to the machine that supports the execution, immediately prior to the execution would make it a compiled code. Yes, the target code is compiled, but it is transparent to the whole process, this is discretionary to the interpreter. And this compilation can not devote to optimizing the code otherwise create a higher cost than the gain.

Packaging

It is possible to encapsulate source code in a single file, possibly within an executable, and can compress and even encrypt it, but still have the interpreting process.

Upside

The greatest and most noticeable advantage of interpretation is the ease and speed to start executing the already written code.

Some people cite other advantages of this form of code execution, but that in fact the advantage is collateral or only related, that is, it is common to have the advantage in "interpreted languages" but in fact it is a coincidence and the advantage does not occur by the interpretation itself. Other cases cited are due to ignorance that the compiled form can also have the same advantages. If a normally compiled language does not provide the advantage, it is a problem of it and not of the execution method.

One of these supposed advantages is that it can run on several platforms. Compiled codes can also be compiled if they are not compiled to native code directly. And code interpreted by interpreters that are only available for one platform, doesn’t have this flexibility. The advantage is not a property of the form of execution. So one can talk about trend, but not a guarantee.

From the point of view of language implementation, it is easier to make an interpreter, especially dynamic languages. But I don’t think this is of interest to most people, part of the ease is because you don’t expect too much of languages that are thought out more to work in an interpreted way.

Compilation

The traditional compilation considers larger parts of code always, it is necessary to understand the whole of the code. It does not need to be done in the entire application but in everything that is required in a particular part of the code.

The analysis is done in a similar way to the interpretation, so much so that often the process of interpretation in the background is done by a compiler. Of course the operation of this compiler is a little different in the interpreter. But the lexical analysis, syntactic and semantics that every compiler does is also required in the interpreter.

The big difference between the two is how the result is generated. The interpretation executes the analyzed code. The compilation generates another code that will later be used (executed) by an environment that understands its operation. It can be a virtual machine or a real machine.

Execution

So compiled code (in a target code) usually runs on top of an application that simulates a machine and an operating system or if the code is considered native on top of a real operating system. Although there are cases where compiled code generates binaries capable of running on a machine on its own, the most common is to need software that controls its execution in general (but does not control the instructions), as well as interpreted code. The difference is how the execution occurs.

Compiled codes for native executables can have their code passed directly to the processor. Executable with bytecodes intermediaries can be compiled to native code or executed through a decoding and execution on loops (loops) of the virtual machine, which is similar to an interpretation.

Compilations often generate native machine codes or virtual environments, but not necessarily. They can generate other source code or other ways that they can be used later. Some say there’s only compiled code when it’s native.

There are cases where the compilation process generates an intermediate code that can then be compiled again. The second compilation is usually called just-in-time Pilation made by a Jitter. But this compilation is different.

Compilation does not necessarily need to generate anything, it can be done as a check only or it can generate code that will not be executed.

Packaging

After the compilation there are cases where the linkediting which generates an executable file with everything it needs to run and in a format supported by some operating system. But this is not true in many cases using virtual machines.

Perks

A clear advantage of using compiled codes is that a considerable part of the programming errors can be avoided in the compilation process and never come to execution.

Compiled code is easier to protect intellectual property, especially when only native code is distributed. But it is possible to do the same with codes to be interpreted, depends on implementation. Complete protection does not exist in any case, only the greater facility is an advantage.

Another advantage is that compiled codes usually run faster, since the analysis does not need to be done during execution, and because it analyzes the code in an integral way, it can perform optimizations. Some of these optimizations take time to be performed by the compiler, but as this optimization work will not delay the execution it can be done comfortably and aggressively.

Speed

There is often confusion with the speed gain of some languages. Although the two improvements mentioned above are important for speeding up applications, often a very important factor is that "compiled languages" tend to have their own characteristics that help speed by itself.

For example they use static and non-dynamic typing, as is common in interpreted languages. Of course, the opposite can occur, but since there is a common relationship between these types of languages, there is confusion among the more laity in the subject.

Another important point is that languages that offer lower level access, give better attention to certain details and better control over the code, and therefore offer better performance, are usually compiled, but this is a coincidence not an inherent feature.

Some people will say that the compilation generates native code and because it runs directly there is performance gain. This is true, but it’s a side effect. Assembly It’s not compiled (it’s assembled, as the name says, okay, it’s true that some are even compiled) and it generates native code that’s fast. It is not the build process that makes the code run faster, in this case.

This is usually true, however it is possible to execute code interpreted faster because it offers better context, although it is not easy, it does not always happen.

So it is not possible to run a Python code faster than the same code written in C++, if both are well written and not something done specifically to show a corner case that has no relevance in the real world (I know someone will want to show that there is some crazy way, very specific that Python can be faster). Even if Python code is compiled (and this is possible).

Controversial subject

I’ve never actually found information that would stick to a clear definition of that. I have seen different definitions of this, some putting more criteria to define what is one thing or another. Some making affirmations of what each one is that would make it impossible to give clear definitions of when an application is compiled or interpreted.

If you consider that generating native code is what defines that a code is running compiled, it makes it impossible to describe the term as it is universally known. Compilation cannot be restricted to native code generation. And the simple fact of having a native code does not mean that the process to get there does not have an interpretation. Some will say that there are cases that is not compilation and yes transpilation, that in the background always has a compilation part.

There is also the hybrid process where a code is compiled but the result is something that needs to be interpreted. Remember that compilation can generate any other code in any language that then needs to be compiled or interpreted.

Javascript

Is Javascript interpreted or compiled? I’m not even talking about Rhino or Jscript which are obviously compiled and then executed on top of the JVM and CLR respectively. I’m talking about the code that runs in the browsers.

In my vision, it’s interpreted. Today all good browsers compile the source code in native code, one way or another, but need to do the analysis of the source code, which is obviously necessary, every time before running, and the errors will be checked right at the moment of execution. To me this is interpretation. The transformation into native code is just an optimization.

In general the Engines browsers usually execute code faster than these implementations that compile JS code.

Can anyone say: what if browsers cache native code? Maybe they already do, I don’t know how Engines are operating. I think the cache there is just an interpreter optimization strategy. Native code may disappear, become invalid, etc. It is not the focus and is optional.

But execution is compiled, so using this term is not exactly wrong. But for me the code of your application, strictly speaking, goes through a process of interpretation.

Typescript

Is compiled or interpreted?

There is even a compiler, so there can be no doubt. Typescript compiles for Javascript.

The fact that the target language is interpreted is another problem. And it is by circumstances. One day may not be more (probably won’t be), without affecting Typescript.

Possible errors are checked by the compiler, the language analysis is done all in an isolated process and well before the execution, and some possible optimizations are made in the compilation.

Moon

This is a language that allows you to interpret the source code (although it has an internal build process), allows you to execute a bytecode own that was generated by the compiler and can be interpreted to native code with the Luajit (or dialect?) implementation (What is a Jitter).

Luajit is a curious case because it runs (interpreted) faster than compiled Lua. It was created for this very thing. Who knew that an interpreted code can be faster than a compiled code. And we are talking about the same language. It would be unfair to compare different languages because the speed gains could come from other language features.

Note that Luajit preferred to use source code and not bytecode compiled because this would give better performance. And one of the reasons is that certain parts get slower if they have to be turned into native code.

Java and C#

These languages compile to a bytecode.

Most people consider them as "compiled languages" (I won’t go into the merit that they can alternatively be interpreted as well) but some say they are interpreted since they need a next step to perform.

I consider these languages compiled even. They generate a JVM bytecode or a CIL bytecode. People say they’re interpreted. Well, I see a mistake there. People are saying that these two intermediate languages quoted in this paragraph are interpreted. They are no longer talking about Java and C#.

There was a time when the bytecode JVM language was decoded by the virtual machine and then executed. For me this was not even interpretation, although informally I say it is interpreted. Decoding is a much simpler process. But even accepted in this case. The current JVM or CIL bytecode is also compiled for native code.

Programming errors that were possible have already been detected, heavy optimizations have been done and you do not need an original source code and you need a process of Parsing. For me this is not interpretation.

These languages have compilers. If they are interpreted, these tools are misnamed?

And when running C#REPL, for example? Has a compiler (.NET Compiler Platform) who works for the interpreter, but clearly there is a process of interpretation.

Completion

There are definitions, comparisons, etc. But we can’t even clearly define when a code is being interpreted or compiled. In other words, this is of limited importance. Especially because the interpretation is enormously benefited by the compilation and compiled code may eventually behave as interpreted code, applying the appropriate techniques.

If you take literally some of the definitions found out there, there are virtually no interpreters left.

References

• Two excellent answers, one from a good developer who understands the subject and another from this half-mouth who speaks to you. It’s practically a duplicate question.
• Question here from the website about the JS.
• Compiled languages.
• Interpreted languages.

Answer 2

I was going to write this as a commentary on the other two responses (I started writing this before Maniero posted his reply), but it started getting too big and I realized it would also be an answer.

The compilation process is more or less like a translation. It consists of transforming the code of a language into a code of another language. It can be from C to machine language, from Java to bytecode, etc. And not always the compilation is for something to run, as is the case of compiling Latex to PDF. The compiler is nothing more than a program that has as input a code in the language A and generates as output a code in the language B.

The process of interpretation consists in you taking a code, treating it as if it were a sequence of instructions, operations, commands or something similar and starting to perform the actions that are described in it. The interpreter is the program that does this.

Thus, a compiled language is a language that is not typically executed directly, but one in which the program described in it must be compiled before it can be executed. This contrasts with an interpreted language, where often the commands/operations are executed by the interpreter as they are processed.

Note also that there is a gray area there. Often, interpreters compile the code for some internal representation before executing them. And because of that, it’s also possible to make a typically compiled language into an interpreted one. In many compiled languages, it is also possible to write interpreters that run the code without needing the build step (although it is somewhat difficult).

Finally, machine code, Assembly is a code interpreted by the processor. Hence, even its executable program consists of a sequence of instructions in machine code to be interpreted, and therefore also consists of an interpreted language.

Answer 3

The difference is in the execution process of the programs generated by such languages.

Linguages Interpretas: as the name already suggests, they are interpreted line by line, one at a time, in a structured way, without the need to perform a previous compilation. One of its advantages is that since its environment is on a machine it is possible to execute the same code without adaptations, however the execution of programs made in this type of language can be slower in relation to compiled programs. Examples of interpreted languages are: Python, Ruby, Javascript.

Compiled Languages: are languages in which the code needs to pass previously through a process called compilation, which consists, roughly, in translating the code written in human language into machine language (Os and 1s), this type of language usually performs better in applications than interpreted languages, however the written code must be compiled on the platform to obtain the executable program and it is possible that adaptations are necessary for the desired system. Examples of compiled languages are: C++, Java.

There are many advantages of one over the other, for example compiled languages can find some types of errors during the compilation process. Already interpreted languages due to their dynamism can perform operations in more flexible ways, which make them more flexible and simple to program. But the biggest difference between them is the performance that one has in relation to another, which in a given application can be crucial for the choice of language in the project.

But this all depends on the skill of the programmer in question, given his knowledge it is possible that he writes code in Python as efficient as the same program written in C++.

Answer 4

The compilation translates your code to be executed in a specific environment (for, for example, a particular S.O.).

In the interpretation you write a code to be interpreted by another program that has already been compiled (so it has already been optimized) for, for example, some S.O..

Complementing...

Based on what I said above I can say:

A compiled language will ALWAYS be faster than an interpreted language.

Only that to not cause confusion I need to define what I think about compiled language and interpreted language...

I assume as compiled language the one that has undergone some transformation so that it directly uses the native resources of the environment (basically the S.O.) in which it will be executed.

Interpreted language is one in which we use native resources through an interpreter.

We can run a language interpreted faster than a compiled language?

Yes, we can.

But, this is because the interpreter uses the native resources more efficiently than the compiled language.

It can be through a better implemented algorithm, by taking better advantage of some native resource or by using a resource that the compiled language does not use.

Even so I support the statement I made above, because, I know that, in some cases, the compiled language may be slower, but, it is because it has implemented the use of resources with less efficiency.

As to advantages...

I’ve already said that. The compiled is faster.

Now you have to be careful not to compare precisely the interpreted language that is faster with a compiled, less efficient.

To do this just do small searches or simply open topics, for example here in the stack.