AppleScript_ The Definitive Guide - Matt Neuburg [49]
And the purpose of AppleScript, after all, was to tell other programs to do things. Thus AppleScript itself could afford to be so minimal as to have little or no power of its own. AppleScript has minimal string-munging and number-crunching facilities, but then AppleScript is not intended for munging strings or crunching numbers—it's made for driving applications, and they can munge the strings and crunch the numbers if need be.
So is AppleScript's littleness a virtue? Probably not—at least, not any more. Thanks to Moore's Law and the passage of time, we no longer need AppleScript to be so tiny. Its small size certainly makes it easier to learn than, say, Perl (a language so big and so full of options and functions it can make your head swim), but it is not an easy language at all; on the contrary, it's tricky and quirky and needs a big book like this one to explain it. And if you're used to a full-fledged scripting language, AppleScript comes as something of a disappointment. Perl, for example, has some hundreds of built-in functions; AppleScript has about a dozen, and seems to be missing some extremely basic functionality. Perl has built-in support for powerful string manipulation, regular expressions, and trigonometry; AppleScript doesn't. Just as you don't miss the water until the well runs dry, the "little language" philosophy seems very cute just until you actually need to get something done. On the other hand, if you don't try to misuse it, AppleScript seems quite adequate, especially since it can now (under Mac OS X) avail itself directly of the power of Perl and other built-in Unix tools. As I said in Chapter 1, success may be simply a question of combining specialities appropriately.
Extensibility and Its Perils
As part and parcel of its power to communicate with other applications, AppleScript concedes to those applications an ability to extend the language. Such linguistic extensions appear temporarily to be part of AppleScript, only while your program is talking to the application that provides them. We thus have a language that grows and shrinks and mutates depending on what application it is talking to. For example, AppleScript itself knows nothing of a disk or a folder, but the Finder does. So as long as your AppleScript code is talking to the Finder, it can speak of a disk or a folder. The moment it is no longer talking to the Finder, it can't.
This architecture, as we saw in Chapter 3, has its practical consequences. An AppleScript program that talks to a particular application can be severely hampered by the absence of that application. Even if you know all about BBEdit and how it extends the AppleScript language, you can't compile a script that talks to BBEdit unless you have BBEdit present on your machine at the time. If you send your friend a compiled script file that talks to BBEdit and your friend doesn't have BBEdit, your friend can't even read the script, let alone run it.
For the programmer, the main consequence of AppleScript's extensibility is that it is not one language but many—as many as there are applications to which you might wish to speak. (You can see this consequence in action in Appendix A, where all my knowledge of AppleScript is as nothing compared to my ignorance of how to talk to one particular application.) Thus the AppleScript programmer, no matter how expert, remains something of a perpetual neophyte. Even the most AppleScript-savvy programmer I know has said to me, "I hate trying to figure out the scripting quirks of every app." AppleScript thus displays some tendency to discourage its most devoted users from doing the very thing it was intended to do.
Perhaps even worse than all of this is the everlasting conflict between the