Kenneth <kdw### [at] gmailcom> wrote:
> The root of my *long-term* basic misconception (of not realizing that source
> code is a simple text file, AND WRITTEN in a text editor) is this: I thought it
> needed to be written in some kind of special 'source-code' program or
> environment--and linked in some way with C/C++ code libraries or some such, to
> make even the writing process work. Admittedly a funny/goofy concept, now that I
> understand what the truth is. (I'm leaving out the compiling or interpreting
> process, that's a different thing.)

There are, in fact, many types of programming languages in this respect.

The two oldest, and most common ones, are compiled languages and interpreted
languages.

A compiled language is (usually) written in ASCII text with a well-defined
syntax, and then a compiler program is used to (basically) convert those
instructions into equivalent machine code, which are bytes that the CPU
directly runs. (The nitty gritty details are actually much more complicated
than this, especially because of how operating systems work, but those are
not very relevant for the purpose of understanding what a compiled language
is.)

An interpreted language is not compiled into anything. Instead, the
"compiler" (which in this case would be called an interpreter) instead
just executes the commands as it parses the source file. (Again, the nitty
gritty details are much more complicated than this, but irrelevant at this
conceptual level.) So-called scripting languages are almost always
interpreted.

Then there's a kind of third category, where a language is actually
compiled, but not to native machine code, but to a more hardware-independent
"byte code", which is then "interpreted" by a runtime environment. (This
is kind of a mix of both techniques. The source code is compiled into
"machine code", but not the machine code of the CPU, but a more abstract
one. This custom "machine code" is then interpreted by a program which,
technically speaking, is an "interpreter". It kind of acts like a CPU,
but rather than being a physical CPU it's a program that "emulates" one.)

Of course it can get even more complicated than this. The most advanced
runtime environments will compile the "custom machine code" into actual
machine code of the CPU on the fly, for speed.

(Why not compile from the source code directly to the target CPU, you
might ask? The advantage of using "custom" machine code is that the exact
same program can be run on any computer that has the proper runtime
environment. Interpreting the custom machine code is much faster than
interpreting the original source code directly.)

-- 
                                                          - Warp

Post a reply to this message