As a programmer of any type, you know the code you write isn’t directly acted on in the form you write it by the computer your program runs on. There are several different methods to take your lines of code and turn them into something the computer can run (machine code). One of those methods involves a kind of programming language called an interpreted language.
With an interpreted language, the program runs directly from the actual source code. One common advantage of an interpreted language is its platform independence. The source code you write and distribute is platform independent; the interpreter that executes the program will handle any platform-specific issues.
Some of the most common interpreted languages are most BASIC versions (including older Microsoft Visual Basic implementations), JavaScript, PHP, and Ruby. Shell scripts and batch files are other examples of even simpler interpreted languages.
There are varying degrees of adherence to pure interpreted language concepts. Shell scripts and batch files stick close to the complete pure definition of interpretation by just executing one line of code at a time. Other interpreted languages do some preprocessing and optimization of the raw code before interpreting them to speed up overall execution.
Another interpreted language advantage comes in debugging errors at run time. When you run a compiled program, if it creates an error, it can be hard to pinpoint the error to a specific line of code because in the compiled program, lines of code no longer exist. With an interpreted language, when you run the application, the source code is still intact and any errors should be traced easily to a specific line. However, the flip side of this issue is that with a compiled language, the compiler will check for many potential errors when you compile the code, giving you the chance to fix errors before run time. A purely interpreted language doesn’t give you that compile time option to catch errors before running the application, making debugging a more laborious trial and error process. Most interpreted languages, though, aren’t pure interpreted languages and if you are working in a IDE, there is usually some debugging support prior to actual run time. Languages such as scripting languages for Web browsers (JavaScript) generally give you little or no IDE support for debugging.
In a variation on interpreted languages, some languages use an intermediate step. Java is one of the best-known examples of this type of language. In this case, the Java compiler outputs bytecode (which is still supposed to be platform independent) that then is run by a bytecode interpreter (known as the Java Virtual Machine (JVM)) on each platform. Other languages using this method are Python and Perl. Microsoft’s Common Language Runtime (CLR) is the functional equivalent of Java’s JVM in the .NET versions of Microsoft’s languages. The CLR interprets the Microsoft Intermediate Language (MSIL) code the compiler creates when you compile VB.NET, C#, and the other .NET languages.
A disadvantage of interpreted languages is that the computer you will be running the program on needs to have not only the program on it to be run, but it also has to have the language interpreter. Anyone who has ever used Windows in the 90s probably had an experience trying to run a VB program on a computer that was missing the VBrun interpreter or had the wrong version of the VBrun interpreter. With the popularity of Java and the wars between Java implementations particularly on Windows, the Java bytecode interpreter has become another frequent headache for users and programmers alike.
Another disadvantage of interpreted languages is execution speed. When a language is compiled, all of the code is analyzed and processed efficiently, before the programmer distributes the application. With an interpreted language, the computer running the program has to analyze and interpret the code (through the interpreter) before it can be executed, resulting in slower processing performance.
In a future article, I’ll look more at the alternative to interpreted languages, compiled languages.
About the Author
Jim Minatel is a freelance writer for Developer.com in addition to working with Wiley and WROX publishing. He maintains a blog at http://wroxblog.typepad.com.
