Slashdot Mirror
AppleScript - the Definitive Guide
AppleScript as a language and development environment has some terrible problems, and I applaud Neuburg for not trying to hide them away. Personally I love the power the language can provide, while loathing it for it's "English-like" syntax and the problems inherent in having most of the language defined in differing ways in different applications.
One of Applescript's problems is that it is difficult to teach, as you almost have to understand everything before you can know anything. Unfortunately that problem is reflected in this book. Neuburg constantly finds himself having to resort to the "believe me for now, I'll explain later" strategy throughout the book.
The book is broken up into four sections: "AppleScript Overview," "The AppleScript Language," "AppleScript In Action," and several appendices.
"AppleScript Overview" is a well written look at what AppleScript is, what it is good for and how to use it. Chapter 3, "The AppleScript Experience" is an impressive warts-and-all walk-through of the author developing an AppleScript to solve the problem of renaming files to conform to a particular standard using FrameMaker and the Finder. It is here that the reader will first see the problems inherent with AppleScript as Neuburg battles with incomprehensible dictionaries, unknown object models and uncommunicative error messages to build his script.
Part II, "The Applescript Language," is the 200-page core of this book. Neuburg provides a detailed and comprehensive look at every detail of AppleScript's syntax and semantics. The first chapter of this section, "Introducing AppleScript" contains a marvelous section entitled 'The "English-likeness" Monster' that is a short, sharp (and entirely justified) attack on the problem of AppleScript's attempt to be English-like in syntax.
In the rest of this section Neuburg provides an exceptional survey of the language. I personally appreciated his examination of the intricacies of type coercion and the exotic scoping rules. He has also taken the time to write and elaborate a large number of small pieces of code to demonstrate gotchas and tricks throughout the language.
It is this section that truly separates this book from every other AppleScript book I have previously read -- it is a masterful guide to the language.
Part III is a concrete path towards writing your own scripts. Neuburg starts by examining application dictionaries in depth. The real power of AppleScript lies not in the language itself but in the ability to use language extensions built in to other applications. This also becomes a huge flaw when the only documentation you get is in the application dictionary. As Neuburg puts it "One purpose of the dictionary is to show the human user how to speak AppleScript to a scriptable application in order to drive that application. But a dictionary, by its very nature, is not completely adequate to this task." He then goes on to explain the flaws.
The first appendix is a dump of the AppleScript Suite from AppleScript's 'aeut' resource. This is the core of the language usable everywhere. The second Appendix is a good, useful guide to tools and resources for the AppleScript programmer.
Taken as whole, this is a great book for the AppleScript programmer, both beginner and expert. It has a good writing style, has been well edited and well constructed. Neuburg may be putting in too many forward references, though. Other reviewers, particularly those newer to AppleScript, have called the book frustrating and confusing. I think this may be due to both the high information density in this book and Neuburg's fast introduction to topics that are better explained later in the book. If you are a newcomer to programming and AppleScript then this may be daunting.
If you are new, however, this is still an excellent volume but you may have to force yourself to finish it and then go over at least Part I and II again to truly understand the language. It would probably be a good idea to start trying to build your own scripts after the first read through. I must say, that after taking a good hard look at the way the book has been constructed and ordered I couldn't really come up with a better way that wouldn't have doubled the size of the book.
Visit the O'Reilly web page for the book if you would like to see the Table of Contents or grab an example chapter.
Neuburg has said "My approach is not to rely on documentation, ... but to bang away at the language itself, testing and experimenting, trying to deduce the underlying rules" and this approach has certainly borne fruit in this volume. For all it's minor flaws you cannot say, as may be true of many other tech books, that it is a rewrite of the documentation. He has approached the problem from a different direction and given us a book that offers an excellent guide to the language.
I would recommend it to all Macintosh owners as the perfect way to unleash another powerful aspect of your system. For people who have no AppleScript or programming experience who want to be totally spoon fed this book is probably only a 5, for people with a little AppleScript experience, a fair amount of programming experience and a willingness to stick through to the end this book is probably a 9. It is certainly the best book on AppleScript I have seen.
You can purchase AppleScript - the Definitive Guide from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
AppleScript would rock if people started writing really good AppleScript-aware applications. But they don't. Most everything out there is crap, for one simple reason: almost no one supports recordability.
An AppleScript-recordable application lets you record your interaction with an application and play it back later. But it's more than just keystrokes and mouse-clicks. The events that make up your interaction are recorded at the semantic level, which makes them a whole lot more useful.
It also would address what everybody keeps saying is the chief shortcoming of AppleScript: it's terrible syntax. I agree it's pretty unwieldy in places, but the thing of it is, you shouldn't be writing scripts, you should be recording them! And once you've recorded a script, it's a pretty easy task to go in there and make simple changes if you need to.
The problem is compounded by people releasing software that claims to be recordable but really isn't. BBEdit is an example... they claim to be recordable, but they're not. All they let you do is screw around with window positions and basic UI crap like that. But do they let you actually record your interactions with the text within the document? No. And so people go buy BBEdit, see that the box says it's recordable, try it out and come away thinking that AppleScript sucks. It doesn't. It's BBEdit that sucks.
What's especially frustrating is that the purchase of Next should have helped remedy this situation. One of the reasons so few really good recordable applications are out there is because it's really hard to write a really good recordable application. You have to factor your code with AppleScript foremost in mind, so what was once a single function becomes four or five. And the API is a little convoluted. And you have to create and maintain an object hierarchy that may or may not correspond to the hierarchy of classes used in your code.
Cocoa/Objective-C could've gone a long way towards solving these problems. I detest Objective-C on other grounds, but I do appreciate that it would be a great boon in the creation of AppleScript-recordable applications. Alas, the guys from NeXT who seem to be running the show over there these days have taken a "not invented here" attitude to the language.
That's really too bad. Because you may all think the syntax is absurdly verbose and superficially English-like today, but just wait until we start talking to our computers as a matter of course. AppleScript would rule your desktop.
If I were running Apple, I'd make Python a first-class language, give it access to everything Cocoa and Carbon have access to, and put together a truly awesome AppleScript module that would let developers create AppleScript-recordable applications just as easily as you would, well, write a program in Python.
Sigh. If only.
Is this truly the only Earth I can live on?
This simply isn't true. Perl and Python (and other scripting languages) don't come close to the power that Applescript can provide.
Applescript's power is in its ability to control other, already running applications. Hell, to do this under Linux, the program needs to support it in some strange manner (ala MPlayer's "slave mode," which requires a wrapper written in another language (like Perl))
And now with GUI scripting, Applescript is incredibly useful for a huge number of things, enabling you to script literally everything on your computer.
It's a shame that Apple crippled this ability with an awkward interface (odd, since interfaces are usually what they're known for), but you take what you can get. I, for one, am looking forward to reading this book because it's damn hard to find good AS resources online.
thaen
There isn't a syntactic similarity between Tcl and Applescript, but there are some deeper similarities. In Tcl and the Tk Toolkit John Ousterhout describes Hypercard as an inspiration for Tk for an easy to use to to create graphical applications.
The design of Tcl command extensions is also very similar to the classes and events that an application exposes to Applescript. Tcl statements are in the form "command arg ...". When you extend Tcl, you take libraries, maybe even existing libraries, and add them as new commands to the language. So while Applescript exposes your applications component functions to scripting, Tcl suggests that you decompose your application to components and tie them together with scripting. Tcl's scripting language subroutines also look like additional commands, and base language commands, a library extension's command, and user written subroutines are essentially interchangeable.
That last point about the commands being interchangeable, and Tk's "send" command combine to create something very similar to Applescript. You can send arbitrary Tcl expressions to a Tk application, have it evaluated based on the context of the remote interpreter, and have the result returned to you.
- and
-
may look a bit different, but they seem very similar to me functionally.