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 25 90 11