Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics

Dashboard
Notifications
Mark all as read
Q&A

Interpreted language: What is its benefit for being written in that way ?

+6
−0

Whenever I search in google why a specific language is interpreted language, I get differences between compiled languages and interpreted languages but nowhere the benefit for being interpreted rather compiled. Anyone please shed some light.

Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

0 comments

3 answers

+8
−0

Historically, compiling programs could take a long time. Interpreted languages did not need to be compiled. So if developers wanted to change the program, if it was interpreted they could just tweak a few lines and run the program. If it was compiled, they had to wait until the compiler was done. This slowed down development.

Nowadays compilers are much faster, but even now compiling can take a long time if XKCD is to be believed.

Another advantage is platform-independence, although it comes at a price. The program isn't compiled for a specific architecture, so anyone who has an interpreter for the language can run it. Of course the key phrase is "anyone who has an interpreter for the language", so ironically this platform-independence comes at the price of less portability.

Interpreted languages also tend to come with a REPL, a Read-Eval-Print-Loop. The user can just enter commands and have them executed directly. If the program maintains the values of variables after finishing, the developer can inspect the state after the program has finished.
Note that compiled languages can have REPL's too, but they require some more effort to implement. As the linked Wikipedia article points out: " REPL support for compiled languages is usually achieved by implementing an interpreter on top of a virtual machine which provides an interface to the compiler."

Sources:
Avo, Sethi, Ullman - Compilers: Principles, Techniques, and Tools
http://itinterviewguide.com/interpreted-language/
https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.zappldev/zappldev_85.htm
https://en.wikipedia.org/wiki/Read–eval–print_loop

Why does this post require moderator attention?
You might want to add some details to your flag.

0 comments

+6
−0

Interpreters are easier to write than compilers. For this reason esoteric and toy languages are often implemented by interpretation.

But the dichotomy between interpreted and compiled languages is a false one:

  • a sufficiently popular language which initially has only an interpreter may well later gain a compiler for performance reasons (see: Python vs Cython, pypy, etc; PHP vs HHVM).
  • other popular platforms use hybrid approaches whereby source code is compiled to a bytecode for a virtual machine, and then the bytecode is interpreted or part interpreted and part JIT-compiled (see: Java, .Net).
Why does this post require moderator attention?
You might want to add some details to your flag.

4 comments

+1 for pointing out the false dichtomy. It might be worth adding why interpreters are easier to write; e.g. no need to do register allocation. FractionalRadix‭ 28 days ago

There're some inaccuracies in the examples given. E.g., "Python vs CPython" is incorrect b/c Python is basically a language specification. CPython is not a "compiler" for Python; it's the reference runtime implementation - but it's still an interpreter, not a compiler. Another example includes IronPython, which is a .Net-based runtime. ghost-in-the-zsh‭ 26 days ago

@ghost-in-the-zsh, not CPython, Cython. Peter Taylor‭ 25 days ago

@PeterTaylor: I guess I must've misread that as CPython for some reason. My bad. Also, I didn't get a notification... I just happened to check and see your comment. ghost-in-the-zsh‭ 25 days ago

+4
−0

Some additional advantages of interpreted languages:

  1. Interpreted programs are basically scripts run by the interpreter. The interpreter can be embedded into other applications that want to provide some user-defined logic. As long as this is not expected to get large or require high speed, then interpreting a script as needed has some advantages. It happens "instantly" for the user. It doesn't require the existence of a specific compiler (which is much harder to embed into an application), doesn't have to deal with separate executable files, doesn't have to go thru a compile step, a link step, and doesn't have to have all the runtime and other libraries available.
  2. There is more flexibility about what can be done at run time. While having the symbol table available live at run time could in theory be done with compiled code, it usually isn't. For example, it might be useful to scan the list of symbolic constants of type integer that fit a particular name pattern, and perform operations and generate a table from them.

Could you please give an example for your first statement.

One example is how the computational abilities of the Embed PIC assembler preprocessor were provided. The preprocessor is essentially a full interpreted language that can do arithmetic on several data types, loops, subroutines, various conditionals, etc. These language features were implemented by embedding the Embed Scripter (ESCR) into the preprocessor.

Embedding the scripter in the preprocessor, and extending the scripting language with a few custom commands and functions was relatively easy. The whole unique code of the preprocessor is only 2614 lines (I just checked), and can be seen at https://github.com/EmbedInc/pic. Only the files named prepic*.pas are part of the preprocessor. The generic scripter is at https://github.com/EmbedInc/escr and is 17.4 k lines of code, but just a linkable library from the PIC preprocessor code's point of view.

Now consider the reverse if this had been done with a compiler. First, compilers aren't generally embeddable into other applications as callable libraries. Even if there was such a thing, the preprocessor would still have to strip out the preprocessor code part, compile that, link it (with what exactly?), and run it as a separate EXE. Since this is all to implement a preprocessor, the part of the input file that is just passed to the output would have to be embedded into the compiled program in such a way to cause output. This all gets very messy.

This is a great example of not needing extensive computation power or lots of memory to perform a few arbitrary operations that can be programmed by the user. You wouldn't use something like this for doing heavy image processing over millions of pixels, but interpreters are quite suitable for addressing light weight programming problems like this.

Why does this post require moderator attention?
You might want to add some details to your flag.

1 comment

@Olin Could you please give an example for your first statement. aditya98‭ 24 days ago

Sign up to answer this question »