In general, programming languages fall into one of two

categories: they're either compiled languages or scripting

languages. Let's explore what each of those terms means, and

understand the differences between them.

Compiled Languages: The language in which you write an

application is not actually something that your computer

understands. Your code needs to be translated into bits and

bytes that can be executed by your computer. This process of

translation is called compilation, and any language that

requires compilation is referred to as a compiled language.

Examples of compiled languages include C, C#, and Java.

For a compiled language, the actual compilation is the final

step in the development process. You invoke a compiler --

the software program that translates your final

hand-written, human-readable code into machine-readable code

-- and the compiler creates an executable file. This final

product is then able to execute independently of the

original source code.

Thus, if you make changes to your code, and you want those

changes to be incorporated into the application, you must

stop the running application, recompile it, then start the

application again.

Scripting Languages: On the other hand, a scripting language

such as Ruby, PHP, or Python, relies upon an application's

source code all of the time. Scripting languages don't have

a compiler or a compilation phase per se; instead, they use

an interpreter -- a program that runs on the web server --

to translate hand-written code into machine-executable code

on the fly. The link between the running application and

your hand-crafted code is never severed, because that

scripting code is translated every time it is invoked -- in

other words, for every web page that your application renders.

As you might have gathered from the name, the use of an

interpreter rather than a compiler is the major difference

between a scripting language and a compiled language.

The Great Performance Debate: If you've come from a

compiled-language background, you might be concerned by all

this talk of translating code on the fly -- how does it

affect the application's performance?

These concerns are valid -- translating code on the web

server every time it's needed is certainly more expensive,

performance-wise, than executing pre-compiled code, as it

requires more effort on the part of your machine's

processor. The good news is that there are ways to speed up

scripted languages, including techniques such as code

caching and persistent interpreters. However, both topics

are beyond the scope of this book.

There's also an upside to scripted languages in terms of

performance -- namely, your performance while developing an

application.

Imagine that you've just compiled a shiny new Java

application, and launched it for the first time ... and then

you notice a typo on the welcome screen. To fix it, you have

to stop your application, go back to the source code, fix

the typo, wait for the code to recompile, and restart your

application to confirm that it is fixed. And if you find

another typo, you'll need to repeat that process again.

Lather, rinse, repeat.

In a scripting language, you can fix the typo and just

reload the page in your browser -- no restart, no recompile,

no nothing. It's as simple as that.