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
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

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.

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

0 comment threads

3 answers

You are accessing this answer with a direct link, so it's being shown above all other answers regardless of its score. You can return to the normal view.

+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).
History
Why does this post require moderator attention?
You might want to add some details to your flag.

1 comment thread

General comments (4 comments)
+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

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

1 comment thread

Not all compilers produce results targeting specific architectures or OS's (1 comment)
+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.

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

1 comment thread

General comments (1 comment)

Sign up to answer this question »