AppleScript_ The Definitive Guide - Matt Neuburg [51]
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.
Object-likeness
In many computer languages, values are things that you talk about. In AppleScript, values are things that you talk to. The following is a legal way (though no one in his right mind would actually talk like this) to add 4 and 5 in AppleScript:
tell 4
get it + 5
end tell
The use of tell (we are addressing the number 4), get (we are ordering the number 4 about), and it (which means "whoever I am now addressing") shows the nature of the idiom. To be sure, one can (and will) add 4 and 5 by saying something much simpler:
4 + 5
Yet this second way of talking works only because, behind the scenes, AppleScript is supplying the tell and the get for you, to make your life simpler. In AppleScript, whether you know it or not, you are always talking to some value and telling it to do something.
One might therefore suppose that AppleScript is an object-oriented language and that all values in AppleScript are objects. Perhaps, one thinks, AppleScript will turn out to be like Smalltalk, where "everything is an object." AppleScript also has certain values that are explicitly called "objects," and refers to the datatypes of all values as "classes." Plus, in a couple of areas AppleScript implements a kind of "inheritance" between one object (or class) and another. All of these things add to the impression that AppleScript might be object-oriented. Plus, Apple's own documentation states flatly that it is.
Nonetheless, I remain skeptical. I don't think AppleScript is really object-oriented or even object-based. I've come to think of AppleScript as merely having values with certain object-like aspects. Perhaps the reason for the object-likeness of AppleScript's values has something to do with the fact that AppleScript is all about sending messages (Apple events) to scriptable applications (see "Apple Events" in Chapter 3). Having devised a syntax for representing this message-sending architecture in an English-like way, AppleScript's inventors seem to have generalized this syntax to pervade the language.
LISP-likeness
A number of features of AppleScript seem to suggest that someone on the original AppleScript team was devoted to LISP, or to some LISP dialect such as Scheme. As I myself am fond of Scheme, I rather like these features.
For example, AppleScript has lists, which are ordered collections of any values whatsoever. It provides certain primitive operations for dealing with these lists, such as taking the first element, taking everything but the first element, and joining two lists into one (like Scheme 's car, cdr, and cons). And AppleScript permits recursion (a subroutine calling itself).
Thus, it is possible