Who’s in-between? Compilation vs Interpretation

James Ardery
Apr 10 · 5 min read

This week in learning more about code I am going to be focusing on languages. As a new bootcamp grad I am worried about what new languages I should learn!? Typescript or Python? Go or Java? This is a trap that we all fall into and the way that I have tried to avoid this is by learning more about languages in general. When I took a step back to get a broader perspective on all languages an attribute began to emerge. Is the language in question compiled or interpreted? At Flatiron the stacks taught were Ruby on Rails, Javascript and React. All three of these languages, as well as many others, are often compiled. Part of being a developer is looking at error messages constantly and while the errors differed one constant remained for me.

Failed to Compile

While I can easily fix the above syntax error I was curious what my computer was telling me with the word “compile”.

All programming languages can either be interpreted or compiled. There are pros and cons to both approaches. To compile or interpret is to choose how you application translates from the language it was written in (Python, React, Go) to the machine code (binary 0’s and 1’s) that computer hardware can run.

To compile is to pile together all of your application code at once and hand the whole shebang over as an executable file to the computer to run. Now the compiler is proprietary to the language you are using. Languages that are most commonly compiled are C, C++, and Objective C. The compiler is a program that will go through your entire application and convert all of the source code to binary.

To interpret is to convert your source code one line at a time into binary. Inter by definition means between and therefor an interpreter is always in-between your source code and the machine code it is generating. Languages that are commonly interpreted are PHP, Javascript, Java and Python. An interpreter consists of two parts. First is a parser which processes the code first by breaking a line of your program into language components to form an abstract syntax tree (AST) of the line of code.

Second is an evaluator that uses the AST to execute the program. The tree is a vital data structure at the heart of any interpreter. Depending on the tree structure used a parser can have larger or smaller call stacks which will affect the run time of a parser => interpreter => your program. These very “low level” decisions can have larger impacts depending on the type of program you are running. To learn more about ASTs and Parse trees please check out this dense but awesome blog.

Taking a step back to look at the broader picture what are the pros and cons between a Compiler vs Interpreter? In my research the three factors arise. Speed, code privacy, and cross platform compatibility. A compiler is always going to be faster, because even though it takes extra prep time up front to covert your application program language to machine language(binary), once that is done the machine can take off with all of your code rather than processing one line at a time. A compiler is also going to keep your original source code private because it compiles on your device and just sends an executable file of machine code to the other device running your app. An interpreter is much better for cross platform compatibility because it does not have to create a different executable file for every type of platform and CPU.



  • Extra preparation time before starting
  • If there is an error in your code it crashes the whole app (failed to compile) so there is there is then the extra step of having to recompile when you need to debug your program (this is a security plus!)
  • Have to create specific compilations (binary machine code) for specific platforms (Windows, Mac, Linux) and then create CPU specific binaries within those platform builds


  • Runs very fast after initial compilation
  • Original source code is kept private because compiler is on your computer and your computer makes a machine code file that is sent to the other device running your program



- Interpreter runs slowly because it interprets and runs program line by line

- Your original source code is public because it is sent line by line to the device that is running your program which then interprets it to render the app on that device (think sending javascript, img, script tags etc)


  • Starts right away
  • Lets you see your results in real time because one task is executed at a time (EASIER TO DEBUG)
  • cross platform so the interpreter program does the heavy lifting of compiling for different platforms etc

That leaves compilers with two out of the three categories but the race is not over. Today many engineers are working to speed up the interpretation process. C# and Java use an Intermediate Language(IL), bytecode is most common example, and a Just In Time Compiler (JiT). This actually allows the programmer to have their original source code kept private because it is just translated to an (IL) which is converted into binary machine code. The machine code is then compiled in the (JiT) which can speed things up and optimize the IL/bytecode even further before it is run as binary on the computer.

Who knows what the future holds as far as coding languages are concerned but I can only see things getting more efficient and complicated from here :)