Ruby on Rails Question:

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.