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.
A book on a language can be wonderful but that doesn't help when the language is flawed. Perhaps in the days of Mac OS =9 people would have use it. Now, with Mac so close to Unix (via BSD) I would have thought that it won't be long until a Glade or QT Designer style program with C or C++ will be the driving force in compiled programming and ports of Perl and Python in interpretted languages.
Is there a case for Applescript to answer?
I am not trying to start and argument, and I do not think OS evolution will irradicate a language, maybe just reduce it's use. After all a system (Mac) dependent language is not a useful as multiplatform code.
...this sounds pretty interesting (for an Apple story, anyway, haha. j/k :-)). From what little I know, AppleScript bears some resemblance to Tcl/Tk but has more Macintosh-specific keywords/functions. Are there any good open source applications out there that I can take a look at, just so I can get an idea of the language? It sounds pretty interesting, and would be easier than purchasing a $25 book. (Especially since I live in the UK!) What's the closest equivalent to AppleScript on a Linux system, also? Is it more like Perl, Python or bash shell scripts? Judging by the sounds of things, it sounds like an even higher level version of bash.
FloodMT: crapflood Movab
Damn good point; I was working for a couple weeks on an iTunes appleScript that would have been so much easier to figure out if the script recording could have generated some code for me to modify. Ahh well.
Paul Lenhart writes words!
Not to be a complete fanboy, but Matt Neuberg is a truly amazing tech writer. I've pursued AS syntax for years now, and as soon as I heard he was doing a Definitive Guide, was really thrilled (Best book prior to this on AS was Danny Goodman's book from what, 1991?). Have not been disappointed- Like his other works, you've gotta read each chapter about 12 times, but when it finally sinks in, it is worth it..
Even Apple don't mention AppleScript, I think they realise that the UNIX utils/languages have suceeded it. and Mac OS X Panther lets you script with your choice of languages: Perl, PHP, Python, Rexx, Scheme, Tcl and more.
See, you're missing the point. Despite the name, Apple doesn't really consider AppleScript to be a Scripting Language, per se. They consider it to be a root language. Check out the AppleScript Developer Page. To quote, "A peer to the Aqua GUI, AppleScript is the language interface for Mac OS X." There's even a handy little chart that shows AppleScript and Aqua at the top, with Cocoa, Java, Carbon, and Classic underneath, etc.
To Apple, AppleScript is no longer a scripting language so much as it is the underpinnings of the Operating System. It's a different way to communicate with Applications, rather than just through the Aqua interface.
=Brian
There is nothing so good that someone, somewhere, will not hate it.
BTW - I think you misunderstand what the author meant by "semantic level." Instead of buttons or menus you deal directly with what those represent. i.e. instead of doing "click the button OK" you'd do something like "start indexing my_folder". The latter is much easier to read and understand. Dealing with the GUI is dealing with often ambiguous representations of underlying processes. Apple added GUI scripting primarily so you could script everything including those programs that didn't support Applescript.
One problem that many have mentioned (and which brought this about) is that Apple itself has only halfhearted support for Applescript in most of its applications. Mail in particular, while supporting it, has glaring ommissions that still haven't been resolved.
As one of the original designers of AppleScript, I feel compelled to mention that the syntax issue is a complete red herring. The language was originally designed to have replaceable syntax, and it could switch, in real time, between dialects with radically different syntax. The same routine would display in different language localizations, or different syntax forms, depending on user preference.
Apple had a Japanese dialect and a C-like dialect built during the development phase. These were never tested enough to release, primarily because of a management decision to shift a lot of the team over to work on OpenDoc after AppleScript's first release.
However, that said, it can be terribly frustrating to figure out the syntax of the current system. This is because a number of language extensions have been built through a mechanism known as OSAX extensions, over the years. The language elements which come from applications work pretty well, because there's a block structure which wraps them into easily detectable blocks. OSAXen, though, tend to interact globally with the syntax of everything, and a lot of the OSAXen have really gnarly syntax that causes all sorts of unforeseen interactions. Unfortunately, the core language was missing some important features, and OSAXen were the easy way to add some of that back, so it got completely out of hand rather early on.
The original team never imagined that the current syntax would be the only one. Quite the contrary, we viewed it as a syntax that HyperCard users would find familiar, but many other folks would find rather verbose.
This is a tad offtopic, but I think some people will find this useful.
StepTalk is a scripting environment for GNUstep applications (this is why I remembered to mention it: AppleScript -> OSX -> NeXTSTEP -> GNUstep -> Scripting -> AppleScript...). The level of integration with GNUstep apps and the possibilities are enormous, and since Objective-C OO paradigm was based in SmallTalk it feels very natural.
Now that GNUstep is having more and more applications be sure to give StepTalk a look.
cheers
A few objections on your post, at least from my standpoint.
:)
I really like the AppleScript system in the Mac OS. I have always found that most apps support AS scripting decently. However, I have no idea if support for recording is lacking in some apps- I only record a macro *very* rarely.
What I like about the OSA- Open Scripting Archtecture, of which AppleScript is the default language- is the ability is using it to call into apps that otherwise are isolated from my program. I like to be able to eval a line of AppleScript and get a string with the returned value; or, in Perl, Ruby, Tcl, JavaScript and others, I can call into those commands directly.
See, AppleScript is but one language in the OSA. Any language can hook into it, giving it AppleScript's powers, without the need to ever touch AppleScript. I love the OSA and what AppleScript provides, but the language itself is not my style.
Why should I be recording my scripts? A lot of what I do with AppleScript isn't neccesarily accessible with a straight-forward button or other GUI action. Which is why I access the Apple event directly.
A Python-Objective C bridge has been around since OpenStep days.
If you think AppleScript/OSA lack supporting-apps, it's good you don't use Windows with the WSH.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
Possibly because so few applications thoroughly support recordability? So the first time you try, you see it isn't there, and the next time, and so on, until finally you just give up and code it manually.
Nope. The reason I only rarely record my AppleScript is that I often can't record what I want to do. And not because the poor support you claim, rather because there often isn't a way to do it in the GUI. It's the wrong style, at least for what I'm usually trying to do.
For instance, one way I have used AppleScript is to make a little window/app switcher for Squeak Smalltalk, a language that doesn't use the Carbon or Cocoa APIs in its GUI, other than to use as a fancy framebuffer. Squeak has its own windowing system. Anywho, I want to be able to switch to the "real" Mac apps I have running, so I wrote a ditty that brings up a menu with the apps running in Squeak and in Mac OS, and when selected switches to it. The AppleScript used involves asking the Finder what apps are running, and what windows are a part of those apps, information about apps and windows, switching to them, etc etc. Those actions are not the sort of thing I really could record, nor would I want to. This example is pretty representative of what I do with AppleScript. I call out to AppleScript and get a return value, which I may or may not parse and use in my program.
But let's say I just had a task I wanted to be done over and over again. I may record parts of it, and then edit the code, put it in the loop, etc etc. I have never had a problem with doing things this way- no matter if the OSA has any idea about the semantics of what I'm doing. I don't care that it knows what I am doing in the end, just as long as it does it for me.
It isn't accessible because the application has poor support for recording. Ideally, *everything* that you do with an application would be recordable.
Sounds like a fine dream, but not one that makes a whole lot of sense for some actions. Using my example, how do you think AppleScript or the app should support those kinds of things? Have some far more elaborate system of visual programming? Or just have all of those more programmatic actions be in a list that I can get in a menu? If so, why not just use the Dictionary?
Yeah, but I was talking about first-class support, with tools that are installed with the OS and/or developer tools CD, and with docs that are aimed at Python coders, and so I can release a distributable and not make a half-million Mac users try to figure out how to install Python and PyObjC and so forth.
I haven't used 10.3 that much, but in 10.2 you got Perl, Python and Ruby installed by default. What's so hard about having your users install a framework first, and then double-clicking your app? After all, this is OS X, not Linux or Windows. One should be able to drag PyObjC.framework to the frameworks folder, either the local user's frameworks folder or the system-wide one. Or, you could put it in your app's bundle, then they wouldn't have to ever see it. You don't even need to use an installer script.
Everyone wishes their favorite pet language had full first-class support in their favorite OS. There really isn't an answer to this. The other guy wants perl. Other folks want Ruby. I wish Smalltalk runtimes shipped at OS X's core. I mean, Objective-C is just C plus Smalltalk- a natural fit! If that's what you want, do it; OS X opens up a lot of ways to give your users what they want and do it easily.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
And if this isn't enough for your typical Unix geek, just pipe your AppleScripts to the BSD command line with scripts like do shell script "ps -auxwww" and voila.
That is a nice feature - I hadn't played around with Applescript before this week, but in an evening I was able to create a small GUI for checking, starting and stopping a MySQL server, and I could see a lot of scope for easily adding functionality to it. Not revolutionary, but it works and saves me a little time - and more importantly, demonstrates to me the potential of wrapping shell scripts (not to mention interactions with iTunes et al) in easily constructed Cocoa GUIs. Aqua + Perl + iPhoto = cheap, easy fun. Scriptable Bluetooth is promising, too...
You never really had the opportunity to use it in the first place, so how can you credibly claim it to be an option you've rejected?
;)
:) And in this case, the amount of work is rather slim- Python is already there, and adding the PyObjC stuff is a few MB of an install. The community already seems to do a decent job at supporting it. Even if Apple shipped an objc bridge with OS X, it is unlikely they'd provide the level of support you seem to want, at least, not unless you had some expensive support contract with them.
Read the post, man. I said I rarely use the recording funcitonality, usually doing things programatically. I have made recorded AppleScripts- usually to do repetitive interaction with a few apps so I don't have to, often moving data between them. I didn't say that I rejected this method, nor did I say that I have never used it.
Any "position" I have regarding this is based on my experience and my uses. I don't claim that my usage of AS/OSA represents what everyone does, but unlike you, I am not saying that everyone should do things my way or that I have discovered the one true way to do things.
But my questions remains- how do you propose to replace programatic use of AppleScript in the ways I've described? I have presented concrete examples and valid questions, but you just tell me that I've never done it the "right" way, which puts me in a poor position to have an opinion. That doesn't make any sense, man.
That's one example only, and a fairly bizarre one at that. I didn't say that there weren't uses that precluded recordability, and I'm not sure I would describe you as being in AppleScript's target audience in any case.
I am not claiming that that example is representative of what most joe-espresso mac user is doing. I could list more examples of times where you are pulling data out of one app and pushing it into another, examples of scripts that do no interaction with the GUI.
Are you saying they should take that out of AppleScript just so that you can stick to some concept of recording purity?
Again, your example is atypical and not particularly relevant here.
How is it atypical? What is typical and relevant? Let me guess- it happens to be the way that *you* use AppleScript? My example was one of many similar ways I have used AppleScript programatically. I am not saying most Mac users are writing code to customize their computing environment with AppleScript, but it is an example that doesn't make sense to be recorded.
Python only comes with the Developer Tools CD, IIRC.
Python 2.3 comes with 10.3, not on the dev tools CD. I just checked on my girlfriend's iBook, who doesn't have the dev tools installed. I don't have access to a 10.2 machine, so I can't say for sure, but I'm pretty sure it was there without the dev tools- I did some scripting for someone with a few 10.2 machines who wouldn't even know what the developer tools are.
I guess nothing. It's not first-class support for the language though, which was my only point. I may not want to support issues Apple may or may not have with Python/PyXML/whatever. Maybe you're interested in doing that, but I am not.
Ah, the classic open source dilemma!
You want it all, but aren't willing to do a lick of work to get it.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad