Join Martin Guidry for an in-depth discussion in this video Compiling vs. interpreting, part of Building Your Technology Skills.
- [Voiceover] Welcome back to another edition of Building Your Technology Skills. My name is Martin Guidry. And this week, we're going to talk about compiling and interpreting. Compiling and interpreting are both different ways to execute source code. We'll define source code as human-readable code written in a programming language. So this would be like Java code or C++ or C# code. We'll contrast that to machine code. Machine code is binary code that is executed by a computer.
It's binary, so it's all ones and zeroes. But it's also written in a language, and different processors understand different languages. So the machine code that was written for a specific processor typically will not run on a significantly different processor like a processor from a different manufacturer. The compiling process involves converting from a source language to a target language. So at a very high level, compiling just means converting from one language to another language.
The source language is usually the source code written in something like Java or C++. And the target language is usually machine code, something that will be executed on a specific processor. Typically when compiling, the results are saved to a file, and then that file can be executed over and over again on the machine. Interpreting is slightly different. Interpreting involves a running program that reads and executes the source code.
So we have a program that will run. It will take as one of its inputs the source code written in Java or C#, and it will then execute the commands. It does not create a new file. It just executes the commands as it runs. This process has to be repeated every time the code is executed. So let's look at the way this is actually implemented in some common programming languages. To be clear, any and every language can be compiled or interpreted.
So even with something like C++ that is almost always compiled, it is technically possible, if you try hard enough, that C++ could be run as an interpreted language. So, every language can be run as one or the other. But most commonly, languages follow a particular pattern. And we're going to talk about the common ways to work with the .NET framework languages and Java. So first, the .NET framework languages, so these would be primarily C# and VB.NET, but there's a handful of other .NET languages.
What happens first with these is the source code is compiled into Microsoft intermediate language or MSIL. The MSIL file is distributed to a target machine, so the MSIL code is not specific to a particular processor. We can take the same MSIL file and distribute it to any machine that runs the .NET framework. After the MSIL is distributed, one of two things can happen. The more common way of doing things and the older way in the .NET framework is to use the just-in-time compiler.
It will compile the MSIL into code piece by piece. So it doesn't necessarily compile everything at once. It compiles different parts of the program as they are needed. So when a certain section is about to be run for the first time, that section will be compiled. As pieces are compiled, they are automatically loaded into memory and then run. And once the program has run to completion, the machine deletes the code.
So somewhat different than other compilers, where typically the end result of the compilation is a file that stored. The just-in-time compiler handles it a little differently. It compiles the code, immediately loads it into memory and runs it, and then after that, deletes it. The other option for working with .NET framework code is to use Ngen, the Native Image Generator, which handles a more traditional compilation process.
It will compile the MSIL into machine code specifically for whatever processor is on that machine, and it will save that file to disk. Then we can just run that executable program. Java has some similarities and some differences. The first step with Java is the Java compiler compiles .java source code into bytecode. And that bytecode is stored in a .class file that is machine independent and can be distributed to any machine that will run the Java virtual machine.
Then again, we have two things that can possibly happen. More commonly and the original way Java ran was a program called the Java Virtual Machine interprets and runs the bytecode. It works as a typical compiler, taking the bytecode as an input and executing those statements on whatever processor is available to it. The other way of doing things, the newer way, is a traditional compilation. So the Java Virtual Machine sometimes compiles the bytecode into an executable file that can be run on the particular processor on the machine.
This concludes another edition of Building Your Technology Skills. Thank you for joining me. And remember, this course is about you and your ideas. So if you have any ideas for topics, feel free to tweet them to me by using the hashtag #BYTS.
Have a topic you'd like Martin to cover? Tweet @martinguidry using the hashtag #BYTS.