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

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

posted almost 4 years ago

CC BY-SA 4.0

Peter Taylor‭

1302 reputation 7 34 141 7

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

posted almost 4 years ago

CC BY-SA 4.0

4y ago

FractionalRadix‭

409 reputation 7 8 52 22

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.

posted almost 4 years ago

CC BY-SA 4.0

4y ago

Olin Lathrop‭

1069 reputation 1 24 90 11