As we have already seen, AppleScript is English-like. Its vocabulary appears to be made up of English imperative verbs, nouns, prepositional phrases, and even an occasional relative clause.
Whether this English-likeness is a good thing is debatable. It is probably responsible for attracting users who would otherwise be frightened by the rigid-looking pseudo-mathematical terseness of a language like Perl, with its funny variable names, its braces and brackets and semicolons and other impenetrable punctuation. Personally, though, I'm not fond of AppleScript's English-likeness. For one thing, I feel it is misleading. It gives one the sense that one just knows AppleScript because one knows English, but that is not so. It also gives one the sense that AppleScript is highly flexible and accepting of commands expressed just however one cares to phrase them, and that is really not so. This sense is reinforced by AppleScript's abundance of synonyms. For example, instead of saying:
if x <= y
you can say:
if x is less than or equal to y
You are also allowed to use the word "the" wherever it feels natural. And nouns even come with plurals:
get the first word of "hello there" get the words of "hello there"
Nevertheless, none of this is due to AppleScript's knowing any English. AppleScript actually has no natural language intelligence at all. AppleScript is every bit as mathematically structured, rigid, and unforgiving as Perl or any other computer language. If you step outside its rules by a tiny fraction of an inch, AppleScript slaps your hand just as any computer language would. The trouble here, I suggest, is that it was AppleScript's similarity to English that tempted you (subconsciously perhaps) to break the rules in the first place.
For example, later in the book I will have to leap up and down and wave my arms wildly to warn the reader not to confuse these two constructs:
get words 1 thru 4 of "now is the winter of our discontent" get text from word 1 to word 4 of "now is the winter of our discontent"
The natural tendency to meld these two constructs (which do very different things) into an illegal blend such as "get words 1 to 4" or "get text from words 1 thru 4" is almost overwhelming. That's because in English these notions are too similar to one another. If they were represented by harsh mathematical symbols, there would be no danger of confusing them, but because they look like English, the part of one's brain that speaks English takes over and tries to soften the boundaries between these expressions in the same way that the boundary between them is soft in the world of natural language.
Often, too, AppleScript vocabulary looks like a certain English part of speech when it can't in fact be used as that part of speech would be in English. For example, in the
Finder there is an application file property called has scripting terminology
. This phrase looks like a predicate and so naturally one tries to say something like this:
if theApplication has scripting terminology
That won't compile; rather, you have to say this very un-English-like phrase:
if has scripting terminology of theApplication
Another problem with AppleScript's English-likeness is that with so many English words floating around the language, it can be hard to think up a meaningful variable name that isn't already in use for something else. (This is the same point I made at the end of the previous section.) The following lines of code are all illegal:
set name to "Matt" set feet to 7 set count to 9 set center to 1.5
The trouble here is that so much of the English language has been reserved by AppleScript for its own private use.
Then there is the verbosity of English. In most computer languages, you would make a variable x
take on the value 4 by saying something like this:
x = 4
In AppleScript, you must say something wordy like one of these:
copy 4 to x set x to 4
Doubtless not everyone would agree, but I find such expressions tedious to write and hard to read. In my experience, the human mind and eye are very good at parsing simple symbol-based equations and quasimathematical expressions, and I can't help feeling that AppleScript would be much faster to write and easier to read at a glance if it expressed itself in even a slightly more abstract notational style.
Nonetheless, I must reiterate that whenever I put forward these heretical views in a conclave of hard-working AppleScript users, suggesting that we'd all be better off making and sending Apple events in some other less subliminally misleading fashion, I'm invariably greeted with jeers and groans. Users are emotionally (I would say, irrationally) attached to AppleScript's English-likeness; it attracted them to the language in the first place, and they are invested in it now. Those who agree with me, on the other hand, may want to explore the alternatives listed in Appendix B.
Get AppleScript: The Definitive Guide, 2nd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.