Everything is only interpreted, but it depends on what level they're
interpreted. Native executables are interpreted by the processor, while
bytecodes and other intermediate languages are interpreted by the
program (usually the runtime stuff).
The basic difference between scripting languages like Perl, Python and
languages like C is that languages like Perl, Python don't have strict
type-checking functionality, you can use the same variable for storing
strings, later use it to store numbers, etc...
C runtime doesn't interpret the executables, they contain
implementations of common functions like strcpy(), strcat(), etc. You
can easily compile C programs as a static binary (gcc -static), which
doesn't require any runtime for running, but the size purely depends on
the functions you've used in the program.
While languages like VB usually have their own exception handlers, and
stuff embedded in the "native" executables they make, which will throw
you the "VB Runtime Error" dialogs when something unusual happens.
Bytecodes can *never* run faster than native executables (not VB ;-)
Ganesh Swami said the following on 01/06/04 08:35:
"SR" == Sridhar R <sridharinfinity@xxxxxxxxx> writes:
SR> Anand Kumar Saha wrote:
>> How come Visual Basic is a scripting language ? Its compiled
>> ('built', as in VB.NET term) and not interpreted.
SR> VB _is_ a scripting language. Applications deployed in VB
SR> will also include some vb6 runtime dlls. Actually (I think)
SR> that dlls contain the interpreter. You doubt cleanly tells
SR> that VB is an unnecessay scripting language (as it lacks
SR> explicit scripting language features).
C _is_ a scripting language. Applications developed in C will need a
runtime library (called [g]libc). Actually I think libc contains a
interpreter for the C language.
And so on and so forth....NOT !
VB used to compile to p-code in version 5, but from version 6 onwards,
you can compile to native code. Every language with a class library
requires a runtime library (unless you compile static).
p-code must be something like bytecode and that actually blurs the
line between compiled and interpreted languages. I believe bytecodes
run faster than compiled languages because of the JIT.