AppleScript_ The Definitive Guide - Matt Neuburg [32]
An application can ask the AppleScript component for a copy of the compiled code in various forms, though; and there are certain occasions when it will wish to do so. A script editor application, for example, immediately after compilation, will ask for a pretty-printed version of the code, for display in the script window. And then there's the problem of extended persistence . The internal memory of an AppleScript scripting component instance, after all, will not persist forever. The lifetime of one of these instances can be no longer than that of the application that summoned it. When that application quits, any of these little component universes that it may have created must also fade away, and all the stuff that a component instance has been remembering escapes like the air from a popped balloon. So if an application asks the AppleScript scripting component to compile a script and then wants the compiled version to persist somehow after the application itself quits, it must take special steps to obtain the compiled version from the AppleScript component and save it to disk. This in fact is just what a script editor application does when you save a compiled script file.
Script
The word "script," like a number of terms associated with AppleScript, is liable to be tossed rather loosely about in a bewildering variety of senses. Some of its meanings are technically important and therefore indispensable, so it will help if we pause to clarify its chief uses explicitly.
Script as Drive
To "script" an application is to automate it, to drive it, to target it. People say, "I'd like to script the Finder to rename some files automatically." There is an implication that the Finder already has the power to do things to files, and that we are merely taking advantage of this power by dictating programmatically a sequence of actions that the Finder should take. This, after all, is why the Finder is said to be "scriptable" in the first place.
This sense of "script" is formalized in the way some sources define a "scripting language." This quotation comes from the ECMAScript Language Specification (http://www.ecma-international.org/publications/standards/ECMA-262.htm):
A scripting language is a programming language that is used to manipulate, customise, and automate the facilities of an existing system. In such systems, useful functionality is already available through a user interface, and the scripting language is a mechanism for exposing that functionality to program control. In this way, the existing system is said to provide a host environment of objects and facilities, which completes the capabilities of the scripting language.
That is a perfect description of AppleScript. It has few powers of its own; it is meant primarily for controlling the powers of existing applications.
Script as Program
The preceding quotation from ECMA continues:
A scripting language is intended for use by both professional and nonprofessional programmers. To accommodate nonprofessional programmers, some aspects of the language may be somewhat less strict.
This leap is common enough, but in my view it is unwarranted. Most languages commonly referred to as scripting languages are full-fledged programming languages, and make no particular concession to informality or inexperience. There is arguably nothing easy, and certainly nothing simplistic, about Tcl, Perl, or Scheme. As far as ease of use is concerned, any distinction between a scripting language and a programming language is a distinction without a difference.
Unfortunately this false distinction has played a major role