There are two general categories of programming languages: compiled, and interpreted.
A program written in a compiled language must first be converted into native machine code to run. This step is called compilation.
A program written in an interpreted language does not need to be converted into native code. The interpreter parses the program and executes it in real-time. It is possible to use the interpreter interactively as a calculator or debugger.
In some cases, the interpreter may store the program in the form of intermediate code in memory and compile parts of it into native code in-real-time in a process called Just-in-time Compilation.
The interpreter may save the intermediate bytecode for faster loading times during future execution as an optimization. Python, for example, saves *.pyc files with compiled bytecode of the imported modules.
Similarly, though technically a compiled language, Java produces *.class files with bytecode. Java is not a strictly interpreted language and is outside of this post’s scope.
An interpreted language is typically a higher-level language. It may explicitly represent data structures, such as lists, tuples, and dictionaries (maps). It may also have higher-level abstractions over algorithms. It does not have to be loosely typed, though most interpreted languages are.
Under most circumstances, a program written in an interpreted language is slower than compiled. However, program performance needs to be balanced against developer productivity. The very purpose of an interpreted language is to hide complex algorithms from the developer and make programs available to run immediately after every change. A program being executed is in the same language that it is written in.
To paraphrase Mel Conway, an interpreted language is an application language, not algorithm (aka platform ) language. Interpreted languages are best used as a “glue” that ties algorithms and APIs together — not to implement algorithms.
There is a reason why many modern interpreted languages are also referred to as “scripting.” Scripting is automating existing APIs and algorithms and combining them into new APIs and algorithms. Scripting is about controlling or orchestrating existing tools, APIs, and algorithms.
A reader may rightfully ask, “Oleg, what are you getting at?”
What makes me think of these things early in the mornings is the proliferation of JavaScript as an enterprise application language. I believe using JS as a hammer to solve every problem will hound enterprise IT for decades.
JavaScript is an interpreted scripting language. It’s a tool for tying things together — DOM objects on a web page and APIs.
I love JavaScript as a tool for quickly building simple apps that tie cloud APIs together.
I’m not too fond of JavaScript for the religion it cultivates among its fans who are in denial about its limitations and feel the need to use it to solve every problem, however inappropriate it might be for the task.
The Dulin Report 