Talk:Interpreted language

Interpreted Language is a meaningless misnomer

There is not actually a concept of an interpreted language to any meaningful degree. I believe this page is propagating a lot of misinformation. Instead of critiquing every little phrase I'll just explain the disconnect here.

There a programming languages, there are interpreters, and there are compilers. Programming languages need to be turned in to executable programs somehow. The two most popular ways are interpreting them and compiling them (see the respective pages for an explanation as to what the differences are.) The fact that you interpret the code or compile the code, however, is not a language-specific property at all.

Many languages have both. There are also often many compilers for one language. What is an interpreted language then? A programming language for which no one has yet to write a compiler? Show me that language and I'll write you a compiler for it. That language is no longer an interpreted language. This phrase just does not have meaning despite it being a very common phrase in the programming language community. I think we should stop perpetuating the myth that a language is either compiled or interpreted by removing this page. -MM — Preceding unsigned comment added by 209.6.55.158 (talk) 22:58, 21 June 2013 (UTC)

That's right, the term is just a misnomer used informally. Being interpreted or compiled is not a property of programming languages because, as stated above, on a theoretical level, every "interpreted" programming language can be compiled. Accappona La Pelle (talk) 13:58, 23 October 2020 (UTC)

Languages which modify the structure of code at runtime, can only work as interpreted languages. The only way to compile them is to embed the interpreter within them, and thus there is still interpreting going on. — Preceding unsigned comment added by Shkaboinka (talk • contribs) 20:44, 17 November 2017 (UTC)

It is not true that languages which modify the structure of code at runtime can only work as interpreted, please refer to the Wikipedia page about self-modifying code for an example. It may be true that the only way to compile some programs, written in languages that are usually interpreted, is to embed some parts of the interpreter within them, that's because those parts are part of the program itself. Accappona La Pelle (talk) 13:44, 23 October 2020 (UTC)

Change definition

The entire first paragraph never says what an interpreted language is and neither does the interpreter page. All the content in there was incomprehensible to a non comp sci person like me. Could someone please simplify this and say what the interpreted language means in the first 2-3 sentences...Truetyper 03:44, 18 May 2007 (UTC)

Compiled v. Interpreted

In an interpreted language your source code is read in command by command by a software tool, which is called the Interpreter and executed.

What ? Command-by-command ? No interpreter is using such crappy technique nowadays. --Taw

I'm afraid you're incorrect: MatLab uses this technique, sadly. --wlievens

As an example of how outdated the above claim (the "line by line" claim) is, you need only look at a few of the pages on wikipedia detailing some of the ancient BASIC systems. As a single cite, see the Applesoft BASIC page. 205.250.157.193 (talk) 00:56, 21 January 2009 (UTC) tim rowledge

From Interpreted Language/Talk

some languages (like Perl) are compiled at runtime

Could you elaborate ? --Taw

Every time a perl script is run, Perl compiles it and then runs the compiled code. At least, this is the usual way of using perl, although it's not the only way. --Zundark, 2001 Dec 15

You mean compile to syntactic tree or compile to machine code ? --Taw

I believe it's compiled to bytecode, much like Java. As of perl 5.6 (version?), it's possible to produce a bytecode version of a perl program to save the compilation step. I think the bytecode can be converted back to full source as well, but I'm not as sure about that. Indigo Perl (http://www.indigoperl.com) produces a perl compiler that produces a machine executable, but I think the resulting executable consists of both the actual bytecode and enough of the perl engine to run the bytecode, so they tend to be rather large. Their advantage is being able to deploy the code to machines that don't necessarily have the Perl interpreter installed. They have versions for both Windows and Unix-ish platforms. --Wesley

Old Interpreted Language article

An interpreted language is a type of programming language that is not compiled into machine code, but is interpreted at run-time by the computer, and translated into machine understandable code as required.

Then how is that any different from JIT compilation? --Cowlinator

It is often a mistake to refer to a language as either "interpreted" or "compiled", because most languages can be implemented in either way, and some languages (like Perl) are compiled at runtime but behave as if they were interpreted. Other languages, like Java, may be partially compiled into an intermediate form which is then interpreted (although that, too, might be compiled). Some languages, though, are specifically designed to favor interpretation.

An example of an interpreted language is JavaScript.

But more modern implementations are usually JIT compiled. I'm of the opinion that the whole compiled/interpreted separation is very vague at best.

---

Is Java interpreted, or what?

The Java programming language article says:

"The first implementations of the language used an interpreted virtual machine to achieve portability, and many implementations still do. These implementations produce programs that run more slowly than the fully-compiled programs created by the typical C++ compiler and some later Java language compilers, so the language suffered a reputation for producing slow programs. More recent implementations of the Java VM produce programs that run much faster, using multiple techniques."

---

The Java language is compiled, always. It is designed as a compiled language, and is implemented as a compiled language. It is often compiled into bytecode, which is then interpreted (with a virtual machine). I think the Java language article is correct, but maybe it could be worded better. --LDC

Yes, and you can also compile Jave straight down to machine code if you like. The above claim that it is a mistake to differentiate between interpreted and compiled languages is IMHO incorrect; every language that has an "eval" statement which lets you construct and evaluate statements on the fly can never be cleanly compiled down to machine code; you will always have to embed an interpreter in your compiled code. --AxelBoldt

But "eval" doesn't necessarily need to interpret the code, it might as well compile it to machine or bytecode (which might in turn get JITted to machine code).

---

Way too much mess here has been caused by lack of clear definition of "compiling". It is used in two distinct meanings, as in:

1. compiled to machine code (or assembly)
2. compiled to byte code/parse tree/some other internal representation

I think it's wrong to call languages that use the second way "compiled". In such case there would be virtually no interpreted language in use - no language uses line-by-line parsing nowadays, all "compile" source to some form of internal representation.

Quote from FOLDOC:

    Compiler

    A program that converts another program
    from some {source language} (or {programming language}) to
    {machine language} (object code).  Some compilers output
    {assembly language} which is then converted to {machine
    language} by a separate {assembler}.
    ...

---

A more precise statement would be that a compiler translates from one form to another (either native code, bytecode, or even another high-level langauge), but does the translation all at once, before the program is run. An interpreter is a program that starts executing while some or all of the original program is still in source format, and that does translation on-the-fly. The source format and destination format are irrelevant to these distinctions. Stoustrup's original "cfront", for example, compiled C++ into C, which was then compiled again into native code. Contrary to the above assertion, most compilers do in fact compile to native code rather than an intermediate form, with the minority exceptions of Java and Microsoft BASIC. --LDC

---

I removed this paragraph:

One distinction of interpreted language from compiled language is the late binding of the addresses to the variables and labels.

Late binding may allow some interpreted languages to change the logic of the program by modifying its own code at run time. Such a feature cannot be achieved in any compiled language.

For one, it's in broken English and I'm not sure I understand what it's trying to say, and what I think it says isn't true. Late binding has nothing to do with self-modifying code, and compiled languages can pull some sneaky tricks to allow both anyway. If the author of this paragraph can explain to me what he's trying to say and that it makes sense, I'll be happy to edit it and put it back. --Lee Daniel Crocker

---

The article seems to overemphasise the difficulty of eval in a compiled system. I understand this may be difficult in some systems I am not familiar with, but in a compiled Common Lisp system, once you have implemented the compile function that converts functions into machine code, eval is a one-liner: (defun eval (expr) (funcall (compile `(lambda () ,expr)))).

---

I think this article is complete nonsense and should be removed. There is no such thing as 'interpreted language' or 'compiled language'; there're languages, which may or may not have compilers and/or interpreters. All the issues stated in the article that separate 'compiled' languages from 'interpreted' ones are fairly artificial. Every language can be compiled. Every language can be interpreted. Python is listed as an interpreted language and there's not a single Python interpreter in existance. Etc, etc. --Lament

While every language can be interpreted and complied, it is also true really almost all C programs are complied and Perl programs are interpreted (though Perl code are compilied internally). It is not a bad idea to talk about genral cases. -- Taku 00:41 Jan 24, 2003 (UTC)

Oh well. I'm removing the mentions of Python, because there really are no Python interpreters. --Lament

---

I'm also removing this paragraph:

Many languages have both interpreters and compilers, but usually one method of use is dominant based on the language's design. For example, many interpreted languages have a command such as Perl's eval, which takes programming language text as data (which can be created at runtime) and executes it, something that requires a language interpreter at runtime. Languages designed for compilation, on the other hand, may have features like allowing inline assembly. Neither of these features provides a strict requirement for distinguishing "interpreted languages" as such, however, since eval can alternatively be implemented by invoking a compiler and dynamic linker at run-time and assembly can be emulated or invoked from within an interpreter...

It's just ... wrong. And I see no way to cure it. Neither of those features has anything to do with being 'interpreted' - it even says so in the paragraph itself. Lisps are most commonly compiled, and all have eval. Nothing stops anyone from treating inline assembly as a part of the language syntax, and interpret it (or even compile it, while interpreting the rest of the program!). I don't see how this paragraph is useful for anything other than confusing people. --Lament

Right. The part you removed cannot be right above all. I rewrote entirely and it seems better now. The problem is writing not the existence of an article -- Taku 20:52 Jan 24, 2003 (UTC)

---

From the article:

Interpreted languages give programs certain flexibility in run-time over compiled languages. While it is theoritically possible that compiled-type language supports them, in practice the language has to be interpreted in some way in rum-time. Such a feature may include (but not limited to)

   * platform independece (Java's byte code, for example)
   * dynamic evaluation of code (e.g. eval function)
   * ease of debugging
   * small program size (Since interpreted languages have flexibility to choose instruction code)
   * interactivity 

This is still wrong. C is quite portable, and compiled. Lisp has eval, and is compiled. Smalltalk has good debugging, and is compiled. Assembly has small program size, and is compiled. The term "interactivity" is semantically void.

---

Of course, it is generally speaking. Don't you agree it is easier to achive features above by interpretation? -- Taku 21:14 Jan 24, 2003 (UTC)

I agree with that. I disagree that "While it is theoritically possible that compiled-type language supports them, in practice the language has to be interpreted in some way in rum-time". None of the languages I listed are particularly impractical, and all implement the required features while being compiled. If we define "interpreted" as "being easier to interpret than to compile", then most languages are interpreted, anyway.

It seems to me that the problem is a definition. I will rewrite again. See it then give me a comment. I think we should have this article because people use interpreted language in conversation, therefore we have to cover it. -- Taku 21:22 Jan 24, 2003 (UTC)

I think it's much better now, but I'm removing this sentence: "The term is vague due to the fact that the terms compilation and interpretation are vague." (they aren't). Thanks. -- Lament

Really? I think the terms compilation and interpretation are used vaguely. For example, syntax analysis (or parsing) is a part of compilation or a part of both compilation and interpretation? I think the reason why it is difficult to differentiate interpreted language and compiled language is that is not clear that what is compilation and what is interpretation. For example, some compiled language may interpret regular expression in run-time. But it may cache the result like a compilation. What do you think? It may be interesting to mention about this kind of point. -- Taku 01:04 Jan 25, 2003 (UTC)

A compiler converts a program in one language into a semantically equivalent (well, mostly) program in another language, which can be executed repeatedly. An interpreter executes a program. That's all there is to it. Parsing is effectively compilation, but it is as internal stage that we're not interested in. Regular expressions are a sub-language; what matters is that the whole program is converted into another language. -- Lament

Right. Your definition seems concise and correct. Thanks -- Taku 01:15 Jan 25, 2003 (UTC)

So by your (Lament's) definition, a just-in-time compiler is an interpreter ? --FvdP

Yes. (Lament)

The confusion comes perhaps from the fact that no program is truly interpreted. Almost every language (except perhaps Javascript) is converted to an intermediate form before being executed. That conversion may be mere tokenization (Applesoft Basic ?), native-code compilation, or anything in-between... Plus, what's the difference between interpretation and just-in-time compilation ? Frontiers are blurred. In that sense I concur with Taku. But I agree with Lament's main argument: the notion of interpreted language doesn't make sense. An implementation can be an interpretor. --FvdP

About this:

Nowadays, many languages are compiled at run-time, before the start of execution. Examples include Perl, and Ruby. Some languages are compiled to bytecode, which is executed by a bytecode interpreter; examples include Python and Java.

I disagree. I don't see the difference between Perl and Python. As I wrote in an edit comment, the Perl article states that Perl is compiled to bytecode (at least, up to Perl 5). That's no different from Python. And I guess Ruby works the same. --FvdP 01:13 Jan 25, 2003 (UTC)

From what I know about Perl, it is compiled to bytecode anew at every execution. Python, like Java, is not. I might be wrong about Perl. -- Lament

OK, I had not read the "at run-time" in your text, sorry, so I got the whole interpretation wrong (thinking you were saying that Perl was more "compiled" than Python). To continue with the concept clarification process, you appear to count the syntax-tree-building process of Ruby (described by Taku hereunder) as a compilation process, right ?

That was my point, what is the border between compilation and interpretation. But I think Lament's definition perfectly makes sense. Syntax tree is not an another language, but bytecode can be seen as an rudimental language. So I believe Ruby is not a hibrid but a true interpreted language -- Taku 01:41 Jan 25, 2003 (UTC)

Perhaps you mean that Perl modules are compiled once for all, while Python modules are compiled when loaded ? That's only partly true. Once compiled, a Python module is not recompiled unless it changed. And Perl scripts may also be compiled on the fly, I guess. --FvdP 01:18 Jan 25, 2003 (UTC)

About Perl you are right, but you are wrong about Ruby. Ruby code is never converted into bytecode but merely a syntax tree. I am good at the source code of Ruby interpreter, so I am pretty sure. Sorry but this is just a simple clarification. -- Taku 01:19 Jan 25, 2003 (UTC)

---

I removed the following sentence because I can't any sense of it. Could somebody please clarify?

On the other hand, some languages took advantage of interpretation. For example, Smalltalk are designed to be interpreted in run-time. It allows the structure called object in programs dynamically interact each other, which is so-called Object Oriented Programming.

I've done my best to reinterpret it-- please see the article-- though I'm not sure I really hit the nail on the head.

Also, what's dynamic scooping? Is this supposed to be Dynamic scoping? Dachshund

---

Added Java to the list of commonly interpreted languages. What determines whether a language is interpreted is whether it requires a VM or not. If it does, it's interpreted (by the VM). In the case of Java, what's interpreted is bytecode, but it's still interpreted. If someone wants to call it compiled because of the creation of bytecode, that's fine by me, but it is always interpreted. --BK

The above paragraph is false. The fact that a VM is required cannot possibly define a so called "interpreted language". Many, many interpreters are written in a host language (not a VM). Take Racket for example. Further more just because what Java compiles to is interpreted doesn't mean it's interpreted. After all x86 machine code is interpreted by the chip. Is C, therefor interpreted? No. Machine language and bytecode are. Java and C are not. At least not in these examples. Could you write a Java interpreter? Probably. But all of these misunderstandings people are having here is further evidence that the phrase is meaningless and perpetuating misunderstandings. -MM

Ok. Java is compliled. into Java bytecodes, that is. Java bytecode is an instruction set for an imaginary processor. this processor is actually a piece of software called a virtual machine and this virtual machine is the only thing that runs directly on the hardware. An interpreter is simple becuase it is just a loop that retrieves a bytecode then ececutes the sequence of native instructions to accomplish the bytecode's task. it retrieves the next one and so and so forth. interpreters are slow because they have to execute the looping and retrieving and bookeeping in addition to executing the bytecode equivalent instructions. They average roughly around 1/10th the speed of an eqivalent program running directly on the cpu. Nowadays, most big-scale java virual machines improve upon the speed of interpreters by compiling the bytecodes directly to navite instructions and then executing those navtive instruction sequences. those are JIT virtual machines. they have a greater overhead in that they have to act like a compiler but once they translate the bytecodes, it runs much faster. Sun's HotSpot JVM is a hybrid VM cause it has both a JIT compiler and an interpreter. It is supposed to combine the best of both worlds. It interprets everything the first time it gets executed but then on subsequent passes, it JITs the bytecodes. Methods that are very seldom if ever run dont waste the JVM's time by getting JIT'ed. Only if the method, or piece of code, that gets executed more than a few times gets JIT'ed. HotSpot even counts how often a particular method gets run and optimizes it more and more as it runs more and more. In other words, the java program actually becomes more optimized and faster as time passes. After many exectuions, a method can, as Sun claims, become as fast and effecient as an equvalent program in C. Perl, on the other hand, i have no idea.

A few good cites

These might be good to incorporate into the definition: A nuanced definition of interpreted [1] and an argument that languages are interpreted unless they compile to assembly code [2] Antonrojo 17:13, 26 April 2006 (UTC)

ActionScript

I think we should set a few things straight about ActionScript here.

ActionScript has always been some kind of a strange breed when it comes to the distinction of interpreted an compiled languages, since it always had to be compiled first to be run. For as long as there's been ActionScript, there has always been an Actionscript Virtual Machine in the Flash Player.

In ActionScript 1 and 2, code was translated to the prototype-based ActionScript 1 anyway and compiled dynamically, and thus I consider labeling ActionScript as interpreted language as precise enough, though the list item should be renamed to "ActionScript 1.0/2.0".

With the advent of ActionScript 3.0, though, ActionScript is compiled into a different kind of bytecode (although it is still jammed into a file with the .swf extension) which is JIT-compiled by the Flash Player AVM2.

IMO this qualifies ActionScript, although by definition still based on ECMAScript, to be mentioned alongside Java in the section "Languages usually compiled to a virtual machine code".

Best regards, Cathness (talk) 06:22, 5 April 2008 (UTC)

PHP

PHP is certainly not compiled to bytecode before execution. It is parsed,compiled, and executed at runtime by the php interpreter. I assume that "Languages usually compiled to a virtual machine code" means at compile time. there is no such thing compile time in php. see (http://www.derickrethans.nl/files/internals.pdf) for description of php internals.YoCmos (talk) 11:29, 17 October 2008 (UTC)

Poor description

This article gives a very poor description of what an interpreted language is. In fact, you could easily gain the impression from reading it that an interpreted language and a compiled language are the same thing!

It really needs a major rewrite IMO. Gatoclass (talk) 13:07, 10 January 2009 (UTC)

I did a small rewrite to the definition. Certainly a definition of type "is a language whose implementation is ..." is not descriptive enough.YoCmos (talk) 16:12, 7 August 2009 (UTC)

Definition

I combined these two defintions to make it readable for readers who are not familiar with high level terminology. Although the old defintion is technically more precise, the new one is more descriptive. A person who doesn't know what the phrase "main language implementaion" means, will never understand the subject. Pages where this defintion was used: [[3]] [[4]] YoCmos (talk) 10:34, 11 September 2009 (UTC)

Merge into Programming language implementation

I don't know if there's a talk page concerning this but both this and Compiled Language really should be moved to Programming language implementation.

It's not a very useful approximation to consider a language "compiled" or "interpreted" and as this talk page exhibits, it seems to confuse more often than not. Compilation or Interpretation are properties of a languages implementation, not usually a property of the language.

I propose Taking both Interpreted Language and Compiled Language and moving them to sections of Programming language implementation (which is currently quite smile) and having the links redirect to sections there.72.71.243.114 (talk) 22:55, 6 November 2010 (UTC)

Why not to merge with Executable in the first place? Executable and interpreted are one and the same thing, after all. --Javalenok (talk) 10:21, 22 July 2013 (UTC)

COBOL

COBOL as a rule is not interpreted. You may find some implementations, but these do not represent the 99.99% of the lines of code in production today. COBOL is compiled, pure and simple, and enjoys easy integration with C and C++ for precisely that reason. — Preceding unsigned comment added by 91.176.80.245 (talk) 07:23, 16 October 2011 (UTC)

I agree: when I search for COBOL interpreters, I cannot find any. Who added COBOL to the list of compiled languages? I am taking it off. Just in case anybody wants to complain about it: I took COBOL off the list. You can argue with me about COBOL being an interpreted language, or about atheism being scientifically accurate, whatever suits you. DonaldET3 (talk) 04:06, 28 December 2011 (UTC)

List Merge Needed

There already exists a list of interpreted languages in List of programming languages by type. The corresponding section should be merged, then deleted and replaced with the link here in either the end of the intro or the "see also" section. There are complications, however. That page does not include sub-bullets to indicate the ancestry of languages. Furthermore, the list is not alphabetical, which will be a pain. I will post this note on the other page. AllenZh (talk) 01:12, 18 March 2012 (UTC)

Directly/Indirectly

The article starts with the words

is a programming language in which programs are 'indirectly' executed ("interpreted") by an interpreter program. This can be contrasted with a compiled language which is converted into machine code and then 'directly' executed by the host CPU.

Contrary to this definition, interpreted programs are executed directly, without any intermediate compilation. Might be you are looking from the target machine point of view. But, why not the original program perspective? Interpreters interpret the original program, not machine code, after all. I can think of a machine that executes the program directly, without any compilation. Interpreter is actually such a machine. Though normally virtual, you can always make it phisical. Actually, any physical machine executes instructions immediately. The machine language interpreter is a basic interpreter, therefore, as it does not involve any compilation (only little men in the processor know how to execute an instruction). So, interpreter executes instructions directly. Which indirectness are you talking about? --Javalenok (talk) 15:08, 4 January 2013 (UTC)

Java, bytecode, C#, CIL

I read the following:

While Java is translated to a form that is intended to be interpreted, just-in-time compilation is often used to generate machine code. The Microsoft .NET Framework languages always compile to Common Intermediate Language (CIL) which is then just-in-time compiled into native machine code.

This has appeared in the [edit], which seems ok. Now, the first part is also ok. It says that Java workflow consists of compilation, followed by interpretation. The latter may be optimized with second compilation. Nothing mentions bytecode, despite we have the "interpreted languages" title. This creates an impression that it is java, which is interpreted, which is wrong. Java language was designed with the bytecode to be compiled into. Secondly, they say that .NET is different because it (always) compiles into CIL. That is, Micorsoft workflow is different because it is the same! Might be you suppose that the difference is in the bytecode interpretation: Sun designed bytecode for interpretation whereas MS targets JIT-compilation? It is not clear at all and cannot be true because microsoft has nothing to do at all with our topic, interpretation. Might be, by introducing such unimportant details in such entangled manner, somebody wants to hide the fact that .Net is MS's clone of Java. Replaing C# with ".Net multilanguage" marketing hype confirms that. But actually we know that both Java and C# both languages are always compiled into IL (aka bytecode). It is this language that may be interpreted or JIT-compiled. And, there are more languages compiled into java bytecode than into CIL. You cannot say that Java bytecode is Java-limited after that, right? So, I just revert this edit. Furthermore, see in the Interpreter (computing) that interpreter can have the

translate source code into some efficient intermediate representation and immediately execute this

strategy. This is the strategy used by CIL and it is therefore nonsense to say that it CIL is compiled rather than interpreted. --Javalenok (talk) 19:40, 4 January 2013 (UTC)

ASP is not a language

ASP is not a language but a framework by Microsoft where the two languages VBScript and jScript can be used. Other compliant frameworks exist where other languages are also supported. --DotnetCarpenter (talk) 12:27, 7 February 2014 (UTC)

Authentic Definitions

An interpreted language is one whose ORIGINAL design is meant to be run without the need of compilation. Python, Ruby, Javascript and the like are designed like this. The programmer did not need to "compile" any code to run them, even if such is possible now. "Compiled" languages, on the other hand, refer to those languages that were ORIGINALLY designed to be converted to some intermediate form before running. This includes C, C++, Java, Rust, etc. The fact that we can compile any of these languages or run them in a virtual machine is meaningless in comparison with the original intent. You might as well say an image file is a software program simply because you can write an interpreter for its bits. By looking at the original intent of the design of the language (which is usually (but not always) apparent based on its syntax), you can easily classify these languages. VastNova (talk) —Preceding undated comment added 22:17, 8 October 2016 (UTC)

Can we get a source for this? Plokmijnuhby (talk) 10:45, 6 August 2019 (UTC)