Talk:Interpreted language

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

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.

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.

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

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

compiled to machine code (or assembly)
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 feature, though not desirable in good language design, 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

So by your definition, a just-in-time compiler is an interpreter ? --FvdP

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)