It is a "scripting language," not a "programming language." I often discuss this distinction with others and it seems it is fuzzy, but I would say the following:
* Scripting languages are intended to give the scripter some level of control over a document or environment.* Programming languages are intended to give the programmer control of a machine, either directly or through some intermediate, such as the Jave Virtual Machine.
Not exactly.
A scripting language is what in the old days used to be called an interpreted language. This means that the instructions, whether kept as plain text (BASIC) or translated to some custom byte code (ActionScript, Java), are read and executed by a virtual machine (the Java VM, Flash Player, etc.) The VM takes care of translating the instructions to native functionality. In practical terms, if the computer/device has the VM, it'll run your scripts.
This puts some natural limits on scripting languages:
- Even with something like Just-in-time compilation, instructions still require an extra step before they're actually executed. Often this can take up quite a bit of overhead, so a scripting language will never be as fast as a compiled language.
- Scripting languages are restricted by the width of their ecosystem. That's a fancy way of saying that the language will support the lowest common denominator of any system that the VMs support. For example, there's no native access to the Windows Registry from ActionScript, even from AIR. Since AIR also runs on Android, iOS, OSX, etc. this makes sense -- trying to access the Windows Registry on any of these operating systems would fail miserably (they have no Windows Registry!) A robust language will have enough power to allow developers to work around such limits, but the language can't impose these internally otherwise it will be greatly limited in where/how it can run.
The other type of language is the compiled one (the traditional "programming" model). Here the instructions are translated directly to native machine code; once compiled, the application runs by itself, no VM required. This limits the application to the native hardware and operating system -- something compiled for x86 won't won't run on a mobile device, and even if it will it's likely that a mobile x86 processor will only support a limited subset of one found on the desktop. This is precisely why software often comes out in a Windows version, an OSX version, and so on.
While compiled languages are very limited in where/how they can run, they are considerably more free to really use the power of the machine -- native 3D graphics, for example, can be used much more efficiently. Also, since the language is already compiled, there isn't that extra interpretation overhead so for sheer speed, compiled is about the best you can get besides going pure Assembler / machine language.
The line between the two language types is being blurred (JIT, for example), but that virtual machine vs. real machine aspect is still the fundamental dividing definition.
