Compiled and interpreted languages
Video: Compiled and interpreted languagesSo we need 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 luckily, this is not a big decision you have to worry about. Most languages you'll deal with will naturally fall into one or the other, but it is worth knowing the difference. So let's have a simple scenario. Let's say it's just you and me. You have your computer and I have my computer and you're going to write a program that you want me to run.
- Where to go from here
Viewers: in countries Watching now:
Finally, the course compares how code is written in several different languages, the libraries and frameworks that have grown around them, and the reasons to choose each one.
- Writing source code
- Understanding compiled and interpreted languages
- Requesting input
- Working with numbers, characters, strings, and operators
- Writing conditional code
- Making the code modular
- Writing loops
- Finding patterns in strings
- Working with arrays and collections
- Adopting a programming style
- Reading and writing to various locations
- Managing memory usage
- Learning about other languages
Compiled and interpreted languages
So we need 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 luckily, this is not a big decision you have to worry about. Most languages you'll deal with will naturally fall into one or the other, but it is worth knowing the difference. So let's have a simple scenario. Let's say it's just you and me. You have your computer and I have my computer and you're going to write a program that you want me to run.
Now, with a compiled language, what happens is you write your source code and then you have a program called a compiler that will go through that source code and create a separate file that contains the machine code, and you just give me that file. This end result is sometimes referred to as an executable or an executable file because I can directly execute it. I can now just run your program. You keep your 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.
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 bytecode. 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.
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.
Find answers to the most frequently asked questions about Foundations of Programming: Fundamentals .
Here are the FAQs that matched your search "" :
- Q: Using TextEdit with Mac OS 10.9 Mavericks?
Sorry, there are no matches for your search "" —to search again, type in another word or phrase and click search.