This is an exhaustive reference manual for AppleScript, a scripting language included with all Macintoshes. It is not a tutorial, but if you have some programming experience of any kind you will be able to use this manual to construct AppleScripts. The book was published in January 2006 and is up-to-date through Tiger (Mac OS X 10.4). It includes a little coverage of Automator. There is some description of other helpful tools such as Script Debugger, a third-party replacement for Apple's Script Editor that provides a lot of additional capability.

I did some work in AppleScript about ten years ago to automate a nightly build process. AppleScript was the right tool for the job, but getting it to work was a lot of aggravation and I didn't look at AppleScript again. Recently I was asked to prepare some AppleScript demos for my local computer user group, and I got this book as a reference. AppleScript is still as aggravating as ever, but I was able to answer all my questions and complete the demos by using this book and its wonderful index.

AppleScript has evolved a lot in the past ten years, in particular by adding a number of object-oriented ideas and by increasing its interoperability with other programming systems (for example, Python, JavaScript, Perl, Ruby, Carbon and Cocoa based applications). Neuburg does a good job of explaining all these features, and he is particularly good on strategy issues. AppleScript can be used by itself but hardly ever is; you should always be thinking of combining it with existing applications and systems to solve your problem.

The major challenge in AppleScript was and remains figuring out the data types and operations supported by a particular application. Neuburg is honest about this, and recommends extensive experimentation and test scripts to figure out how the applications work.

Is AppleScript worth knowing? Neuburg doesn't really make a strong case for this, although his Chapter 1 is a good try. He works through an impressive example in Appendix A, including all the roadblocks and wrong turns. But the example is to clean up a book manuscript prepared in FrameMaker to meet the publisher's standards before turning it in. I think this is a good job for AppleScript, but how many people would need to do this job? I think AppleScript is still a niche language, but if you work in that niche this is an excellent reference.

We wouldn't know something, especially certain technology very well until we know its limitations (or exceptions).

The extensive explorations in this book chart out the boundaries of AppleScript.

If one needs to consult "dictionaries" to acquire AppleScript vocabulary, this book is definitely the grammar book for speaking the language correct-ly.

No, don't start with "AppleScript: The Definitive Guide." Although I was highly motivated, diligent, and intelligent (if I may say so), Neuburg's exigent, articulate, and idiosyncratic "guide" defeated me, and I had to buy and work all the exercises in another book (Kochan's "Beginning Applescript") to obtain the background needed to appreciate this one.
The highly praised chapter in the first edition about conquering FrameMaker has been moved to an Appendix in the 2nd Edition, but since Neuberg sends the reader there on page 75, it is still useful and timely. It would have been more useful had he chosen a scriptable application that is on every Macintosh, or one, at least, that is shipped with Tiger, so that readers could follow his adventure rather than simply read about it. The worst that would have happened is that a newer modification of the application might have come out, in which case, as with FrameMaker, the reader could read about, but not experience, the process.
'Introductory' books in the liberal arts ("The Discarded Image" by C.S. Lewis comes to mind) are larded with quotations in Greek, Latin, French, and German, not to mention others. In exactly the same spirit, Neuburg shifts shamelessly from AppleScript to Perl, especially, but also to Unix, Objective-C, Python, and JavaScript, not to mention others. If you can't follow such examples -- he tells you that is all right -- you get the point that AppleScript is compatible with these and more, and he has the chutzpah to mention his own JavaScript book if that is your deficiency.
The effectiveness of good programming books diminishes as you move away from the computer. Programming is learnt at the keyboard, not in the lecture hall. That said, this book has an astonishing amount to offer to someone perusing it in an easy chair and mulling things over, rather than trying a succession of incorrect guesses at the keyboard. Kochan's book taught me, quickly and easily, how to move a Finder window around the screen, but when I decided that the window I wanted to move was the one holding the AppleScript program, Kochan left me without a clue. The "Oh, yeah" that finally got it moving occurred to me over a sausage biscuit in a fast food place with Neuburg's book in front of me. He didn't tell me what to do, but his dictionary exposition got me to where I could figure it out for myself.
As other reviewers have pointed out, Neuburg's emphases are upon the obscure, the contradictory, and the difficult. To explain these, he has not bothered with the obvious, the consistent, and the easy. They do not interest him, and he pays us the high (too high) compliment of implying that the obvious, the easy, and the consistent need not be explained at all.
If you wish to learn AppleScript and must learn it on your own, begin with a book (Kochan's, for example) that will make you reasonably competent in a hurry (three months, in my case). Then, when you have discovered that AppleScript is not as easy as you thought, you are ready for Neuburg to confirm your worst suspicions about its intricacies, devastate your casual assumptions about obvious solutions, and give you pride in beginning to learn AppleScript.
If you buy this book, you must read it several times, or you will not learn much of what it has to say.

Matt Neuburg's AppleScript book is an excellent overview of AppleScript. Alas, it is limited, as all such books are, by AppleScript's peculiar nature.

The problem is that AppleScript is primarily useful when it interacts with scriptable Applications; this means that many important commands one may think of as belonging to AppleScript belong to Applications instead [2]. If you working to extend an existing script, and decide to research a command in the excellent book index Matt built himself [1], you'll often be frustrated. The command, you see, belongs to the Application, not to AppleScript.

On the other hand, there's a good chance Matt used in the command in one or more examples. In the absence of a companion book entitled "AppleScript for Applications" [3] you'd like to find those examples. Alas, that's where you want a full text search engine.

The good news is, there are two. The even better news is that O'Reilly could make their engine much more visible and useful, with advantages for everyone.

Consider the case of the 'Duplicate' command, which is supported by iTunes (among others) and the Finder (in slightly different ways, no doubt). When I tried Amazon's "search within the book" I discovered several illuminating references. Similarly, O'Reilly allows one to search within the book as a promotion for its Safari eBook library.

The Safari search works well, but they don't want to give away too much for free. You can only read a snippet of information in the search results. A snippet that doesn't, currently, include the page or section number. If you click further you get to the 'buy safari' screen, but you also get to see the section number. Now, you can return to the book and read the information.

O'Reilly could make all of us (and themselves) happy by keeping Safari just as closed as it is today, but merely adding a section reference to the search results they freely expose already.

Here's the win-win for O'Reilly, Matt, Amazon and us:

1. Include the section reference in the initial search results screen.
2. Promote the search facility in every published O'Reilly book and explain how to use it on the O'Reilly book page.
3. If need be, request readers register to obtain this service. O'Reilly doesn't do spam, but they can suggest email subscriptions, RSS feeds, etc during the registration process.

Let us count the wins:

1. Matt's book is suddenly a better book. Readers get more value from it. They use it more. They like it and O'Reilly more.

2. O'Reilly gets ongoing visits from its customers.

3. O'Reilly gets free, regular, promotion of Safari services.

4. Amazon sells more books.

5. O'Reilly does not reduce the value of Safari, they enhance it by introducing users to it without giving it away.

It's a win-win for everyone. I just hope someone at O'Reilly can see the profit in it for them.

john

[1] In my real life I'm a knowledge representation/informatics geek. I have a lot of respect for the unrecognized intellectual labor that goes into producing a truly excellent index. In this case Matt did the work himself!

[2] Many applications may use the same string to refer to somewhat similar functions with slightly different syntax and semantics. This "ontologic dilemma" is a kind of uncontrolled overloading, and it makes AppleScript very challenging to use.

[3] If Matt decides to sell an "AppleScript for Applications" as a Tidbits eBook I'll pay for mine in advance!

It seems like key pieces of information have been left out of this book, which is very atypical for any of the Definitive Guide series from O'Reilly, and of O'Reilly books in general. I picked up this book because it was the most recently published on the topic, and I'm still confused even after reading it. The first three chapters were on very basic subjects such as why you would want to use Applescript in general, where you would want to use it, and basic concepts. Next, part two is all about the syntax of Applescript, piece by piece. This is all very nice, and it probably is complete and correct, but it is like handing someone a maintenance manual on a washing machine who has never seen one before. Now that I know how to fix a broken one, what do I do with the actual machine itself? Part 3, "Applescript in Action", at first looked promising, but actually it just tells you how to fine tune your applications and shows some advanced features without ever really showing you specific problems that Applescript could solve and then solving them using the language. This is probably a good reference for someone who already is an experienced Applescript programmer, but I didn't find it helpful. I've ordered "Beginning Applescript" by Kochan to try to get some more remedial help on the subject. Hopefully, between these two books I can really learn Applescript, rather than just dabbling in it, which is what I've been doing for some time.