Compiled and interpreted languages

When we are programming it is very essential to get our source code converted into machine code somehow before it can run and there are two main ways of doing this: what's called compiling the source code and what's called interpreting the source code.

Now, fortunately, it's not a decision you have to worry. Most languages that will address naturally fall into one or the other, but it pays to know the difference. So let's take a simple scenario.

Say it's just you and me. You have your own computer and I have my computer, and you will write a program that you want me to run.

Now, with a compiled language, the thing is to write the source code and then you have a program called a compiler to go through the source code and create a separate file that contains the machine code, and give me that file.

This end result is sometimes referred to as an executable file or an executable file that can do it directly. Now I can just run the program, you keep the source code and I never see it.

Now, with an interpreted language on the other hand, you don't compile your source code beforehand. You just give me a copy of it. So I'll need my machine to interpret it whenever I want to run your program.

Now, interpreter is different to a compiler. It does this on-the-fly. We can think of it as going through your source code line by line and processing it on the spot. It does not save it as a separate machine code file.

Now, you've used interpreted languages even if you don't know it. Whenever you've looked at a webpage with JavaScript, which if you've surfed the web for more than two minutes in your lifetime you have, this is what's been happening.

The JavaScript has been sent to you over the web along with a bunch of other files like webpages and images and it's been sent as source code onto your machine, and your web browser has just interpreted that JavaScript so it can run that code.

So which one is best? Well, they both have their good and their bad points.

Benefits of compiled code

Once it's compiled, it's immediately ready to run and you could send it to 100 or 1,000 or 100,000 different people. It's ready to go. It can be optimized for a CPU, so it can actually be faster and you don't have to send your source code to everybody, which might be a good thing.

However, the downsides are if I compile it on a PC, that executable file won't work on a Mac. In fact, it often needs to be compiled separately for different kinds of CPU even on the same platform, and when you're writing code to compile is an extra step that you have to take every time you want to test your program.

Now, with interpreted code

The big benefits are I don't really care what kind of machine is on the other end, because we don't provide machine code, we just send the source code and we let the other side take care of it. So it can be more portable and more flexible across platforms. It's also a little easier when testing because you just write your source code and then run it, letting the interpreter take care of converting it. There is no in-between compile step. It can be easier to debug when things go wrong because you always have access to all the source code.

However, it has its down sides too, because everyone who needs to run that program on their machine has to have an interpreter for that language on their machine. It also can be slower because you have to interpret it every time the program is run, and the source code is effectively public because you're sending it to everyone who needs to run that program.

Now, because there are good things about compiled languages and good things about interpreted languages, there is also a third way of doing this which is a bit of both. Instead of the compiled model where all the work is done upfront but can be a little bit inflexible or the interpreted model where all the work is done on the receiving end but can be a little bit slower, we kind of do half-and-half.

Upfront, we compile it part of the way to what's called an intermediate language, which takes it as far along the way to machine code as it can get while still being portable often across platforms. You then distribute this, sending it to the people who need to run it, and each person who runs it takes it the last step to take it to machine code on their computers.

This is sometimes referred to as Just-In-Time or JIT compilation. Now, this intermediate language sometimes also goes by the name of byte code.

C, C++, Objective-C are Compiled languages

PHP, JavaScript are Interpreted languages

Java, C#, Python, VB.net are Hybrid languages

So this process has to happen somehow. It's just how much of it happens on your machine and how much of it happens on mine. Now, while theoretically all computer languages could use any of these methods, the normal usage of any one language tends to be one or the other. So for example, C, C++, and Objective-C, these are typically found as compiled languages, so you need a compiler.

Now the compiler can be downloaded for free but they're often built into integrated development environment applications. Now, languages like PHP and JavaScript and indeed most languages with the word script at the end are usually interpreted, and languages like Java, C#, VB.NET, and Python use this intermediate hybrid approach.

Now, whether a language is compiled or interpreted or somewhere in-between is rarely a reason by itself to choose a language, but it can be something that you take into account. If one main priority of your program is absolute maximum speed running on one single platform, you'll probably look at a compiled language.

If you're more interested in easily moving your code across multiple platforms, you're probably more interested in an interpreted one. But more usually, you're driven more by what you need to do.

You need to build iPhone apps or Windows desktop apps or dynamic website, or, in our case, just learn the fundamentals of programming, and you let that decision drive the language choice and the language choice will determine whether you are compiled, interpreted, or somewhere in the middle.