# Interpretation in scripting languages

Why is pure interpretation more common for scripting languages compared to programming languages?

I mean, why are programs written in a scripting language not converted to machine language and then executed? From what I have read, one of the reasons is speed; for scripting purposes speed is not so important and since interpretation is slower it doesn't matter for scripting languages.

Are there more reasons for using interpretation in scripting?

• In which way is this a computer science problem? What are your thoughts? Are there any language features that would be hard to implement with statically compiled code? – Raphael Nov 19 '15 at 9:12
• @Raphael Disagree. This is a reasonable question. To put it differently, why are interpreters in use at all? In which situations an interpreter is preferred over a compiler, and vice versa? Why are languages like python, ruby and matlab still interpreted although this degrades their performance considerably? – Yuval Filmus Nov 19 '15 at 10:32
• @YuvalFilmus "Why are languages like python, ruby and matlab still interpreted although this degrades their performance considerably?" That sounds entirely a matter of engineering, to me. – David Richerby Nov 19 '15 at 10:41
• I think that this is a computer science question, but it is not well-founded. Those languages aren't interpreted these days, they are usually compiled on-the-fly to bytecode, and heavily optimised, sometimes even jitted. – Dave Clarke Nov 19 '15 at 13:16
• Beside pure learning tools (algo, pure pascal interpreter) and very old still existing ancient engines (even here like VBA in Excel, it takes more passes) there are no existing tools that are interpreters. All engines are taking some initial passes and precompile code, or inform about undefined things. To me assumptions are outdated and development tool used to write some "interpreter" is opinion based. – Evil Nov 19 '15 at 16:18

Scripting languages are a class of programming languages. This class is rather fuzzily defined.

One possible definition is that they're languages that are designed to automate small tasks, rather than to write large, complex programs. Because they are small tasks, the author tends to spend some time tweaking them, so it makes sense to make the path from source code to executable as simple as possible, and it doesn't get simpler than making the source code itself executable. Because they are simple tasks, the end-user might want to tweak them, too, so it makes sense to distribute them as source code. Because the tasks are relatively small and simple, there's little to be gained by static checking and optimization, so there's little value in using a compiler.

Another possible definition is that a scripting language is one in which the source code is executable. In other words, a scripting language is pretty much defined as one that's intended to be interpreted.

Few scripting languages are purely interpreted though. Most at least parse the whole file before starting execution. Many even compile to some form of bytecode that can be saved to disk.

• And then people started using scripting language for big software... :/ Anyway: "a scripting language is one in which the source code is executable" -- isn't that a property of all source code? I don't see a problem with interpreting source code in any language. – Raphael Nov 20 '15 at 8:28
• @Raphael It's possible to write an interpreter for any language, but only in a technical sense. For example interpreting C is pretty weird, that's a language that's very strongly geared towards compilation. Conversely any language with eval is strongly geared towards interpretation. – Gilles 'SO- stop being evil' Nov 20 '15 at 12:12
• "This class is rather fuzzily defined." I think its definition evolves and depending on your personal history you can be more or less attached to one or the other. The, biased, way I see the history, is that the term was first used for extension language of bigger programs. On path of evolution leading to the proliferation of usage is through command interpreters which got rapidly a scripting capability and then programming languages like perl were designed to replace large command interpreter scripts and common utilities. – AProgrammer Nov 25 '15 at 9:49
• The other path is through libraries defined to easily add a scripting language to a program (tcl is a good example) which were then used standalone. From those two sources, scripting languages were more and more associated to all "interpreted" languages and now I've seen people calling scripts any programs (even in languages strongly associated with compilation like C++), they are usually newcomers but it could spread. – AProgrammer Nov 25 '15 at 9:53
• Best description of the otherwise ill-defined notion of a scripting language I have ever seen! Of course this isn't perfect but it's the best description I have seen to date. – Jake Nov 28 '15 at 14:25

Interpreted languages are used because of their simplicity.

A compiler will assemble all the parts and link them together as an executable. If there is a bug in any one of the parts the build will fail and there will not be any executable to run (missing symbols, missing libraries, incompatible libraries, etc). Also compiled programs often need to manage memory allocation themselves, and thus are prone to bug like memory leaks, buffer overruns, null pointers, etc.

Many interpreters will get right to it and run the program with limited requirements (syntax mostly). If there is a bug in the code the program may run until it gets to that bug then stop. New code can be loaded on the fly. Memory is usually managed for you, so you don't need to worry about deleting allocated memory.

Also interpreters can often be run as a command prompt and commands can be typed in, to test different parts of the program or to interact with your program in different ways.

Interpreters are also used in programs to allow you to modify the behavior of the program as it runs, e.g. MS Word macros.

You don't have to stop the program and recompile the code run it again to make a change.

Compiled programs usually run faster, and have access to lower level operations of the internal workings of the computers (registers, memory locations, permissions, etc).

It can be a blurry line, as some interpreted languages need to be compiled to microcode to run (e.g. Java), and some compiled languages have memory management features commonly found in interpreters (e.g. C#).