Talk:Interpreted language

From Wikipedia, the free encyclopedia

Contents

[edit] 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)

[edit] 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

[edit] 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

[edit] 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.

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:

  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 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

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

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.

[edit] 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)

[edit] 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)