I’ve been coding AppleScript and AppleEvents since what feels like the beginning of time, starting with AE in 1991 and OS7. Revisiting AppleScript has been one of those processes that in 1997 and now in 2004/5 I have dreaded and embraced for various reasons.
The main reason I hate AS so much is the lack of consistency between application implementations of AppleScript support. I also dislike how over time implementations change making old scripts fairly worthless for relearning and aquanting. One of the other things I dislike most is the lack of a good basic introduction to the concepts and specifics of AppleScript. And finally the lack of a fairly all inclusive book or webpage about AS as a tool, AS the language, 3rd party AS tools that are currently supported and a set of generic educational sample scripts.
Now, Pogue Press along with O’reilly in their “Missing Manual Series” and a very bright high school debutant author named Adam Goldstein have put together what I consider to be the best book on AppleScript currently marketed. Thorough, modern and light reading. Adam Goldstein the wonderkid scripter that runs his own website has done us old time and newbie scripters alike a favor filling a much needed gap Apple left in their AS manuals. This 320+ page book was an easy evening read, consumed in less than 7 hours and 2 hours for reflection and revisiting sections of interest.
Some of the most enjoyable things I can mention about this book are… The consistent layout of the text, it is simply a joy to read and hold in my hands. Much like other O’reilly books, this one does not fail to serve well in hand and on desktop next to monitor. Goldstein covers a LOT of territory in 300+ pages, and I found the index useful after the first read for more in depth investigation and details about rather obscure AS topics. To me, a manual of any substance and value is as good as its index. These qualities are alone worth 1/2 the retail of the retail USD $24.95 retail price.
Another thing that impressed me was Goldstein’s breadth of knowledge covering bridge technologies, going from AS to JScript, or RealBASIC to AS, or even JS to AS. Living in the web demands a programmer and designer to know many tools and use the best (or in some cases the only) for the right job. Adam is clear on what AS is good for, and offers a rather complete list of alternatives for various other needs. Adam is an honest writer, something politically not in vogue all the time with writers of technology. I appreciate him being a straight shooter regarding the limitations of AS, where it is most useful, now to maximize its power and leaving it behind for other tools more appropriate. To me these merit the other 1/2 of the retail price.
Covering many application AS interfacing like MS Word, or Adobe PS, the process flow scripter/coder is going to love this up and fast running series of ‘Power User’s Clinic’ box hilites throughout the book. Inclusive are the Workaround sections for solving conflicts and problems with apps that behave or have naming conventions in their AS dictionaries that may result in odd behaviors. For those that want to explore the media aspects of AS programming, there are sections about coding iTunes, Web-Browsers, Commercial Graphic Apps and more.
At least two things lack in my opinion ranking this book high rather than perfectly fitting my personal needs. One is the lack of mentioning a few scripting technologies like FScript, and SenseTalk, both of which are extremely powerful and very complete. The first with true Cocoa objects, and the latter with an AS bridge call via the ‘do AppleScript’ command and the heart of the fully automated and scriptable testing system called Eggplant. Lastly the total lack of AppleScriptable IRC client control is a big oversite. Granted, few will upon utilizing AS spend time coding IRC clients, there is a deep pool of resources online and a webring dedicated to AS IRC scripting useful to the budding and new scripter.
As this book is a Missing Manual release, it is a great launching place for people that want to know the very basics about the tools available for AppleScript like the Script Editor and XCode. This book serves well those that want to get a feel for the tools out there to write more complicated scripts for automation, that of XCode. It does not touch in great detail the use of UI Browser or Smile, two very strong tools that are available fairly cheap to the AS coder. The very last thing that bothers me is the clear lack of commercial experience and focus for AS coding. There is a large market in Publishing for AS Hackers, and it is growing daily. Its apparent this book could use a section or two regarding integration of AS into a business model/work flow, and how to control data flow as part of a configuration management solution. AS is used as part of very complex media production, websites, newspapers, catalogs, libraries, online selling and stores. Yet nothing significant is mentioned about how AS is or could be used in such environments, and this is a sore point for me and this book, missing a great chance to explain how AS can help someone accomplish something useful other than getting iTunes to play folders of music.
Some of the very enjoyable things I can mention about this book are… The consistant layout of the text, it is simply a joy to read and hold in my hands. Much like other ora.com books, this one does not fail to serve well in hand and on desktop next to monitor. Goldstein covers a LOT of territory in 300 or so pages, and I found the index to be very useful after the first read to go back and revisit some topics like the AppleScript Studio coverage that I particularly want to know about, building full blown GUI based AS applications. The simple yet clear coverage of how to construct a simple speech interface to the say command was fantastic, and worth 1/2 the retail of the book alone.
Another thing that impressed me was Goldstein’s breadth of knowledge covering bridge technologies, going from AS to JScript, or BASIC to AS, or even JS to AS. Living in the web demands a programmer and designer to know many tools and use the best (or in some cases the only) for the right job. Adam is clear on what AS is good for, and offers a rather complete list of alternatives for various other needs. Adam is an honest writer, something politically not in vogue all the time with writers of technology. I appreciate him being a straight shooter regarding the limitations of AS, where it is most useful, now to maximize its power and leaving it behind for other tools more appropriate. To me that merits the other 1/2 of the retail price of USD $24.95.
Covering many application interfacing like MS Word, or Adobe PS, the process flow scripter/coder is going to love this up and fast running series of ‘Power User’s Clinic’ box hilites throughout the book. Inclusive are the Workaround sections for solving conflicts and problems with apps that behave or have naming conventions in their AS dictionaries that may result odd behaviours. For those that want to explore the media aspects of AS programming, there are sections about coding iTunes, WebBrowsers, Commercial Graphic Apps and more.
At least two things lack in my opinion making this book a high recommendation rather than a perfect fit for my needs. One of which is the lack of mention of a few scripting technologies out there like FScript and SenseTalk, both of which are extremely powerful and complete, the first with true Cocoa objects, and the latter with an AS bridge call via the ‘do AppleScript’ command.
In all, I give this book a rating of 4.25 out of a potentail 5 rating, for a solid “B” score. A good first edition with a growing list of errata as I revisit sections and notes I made along the margins. I’d recommend it to the starter and intermediate AS programmer. I could see AppleScript: The Missing Manual used by those interested in an overview of AppleScript and how AS techonology could be integrated into an OS X user’s productivity tool arsenal.
Disclosure: One thing I wish most would do is complete disclosure so I would know what kind of motivation and flavoring may occur during a review. To apply to self, I must tell you that I review O’reilly books for payment, in this case a free copy of the book in question. I am also a long time user of HyperSense, SenseTalk and Xmodules writer for SenseTalk dating back to 1990 and the advent of HyperCube the original NeXT/OSX Scripting Media System. However, I have attempted to be fair as well as critical of this book and its author when warranted. Goldstein’s book would have benefited from more years of commercial software and configuration management experience and not hobby or part time scripting practices.
Buy “AppleScript: The Missing Manual“ at Amazon.com |
About the Author:
Todd Nathan is an old hand at new technology. Coding since 6502 ASM for the Apple ][ line of computers in the early 80s, he has seen technologies come and go, mostly go. He enjoys developing Forth compilers in scripting languages for the sheer torture of it all, and ASForth is his latest undertaking. A complete Forth compiler, runtime and interpreter written in AppleScript.
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.
I love AppleScript as much as I hate it. I hate the syntax, but man, I can do some really cool shit with it.
I’m amazed there hasn’t been more effort by the AppleScript community put into getting Apple to replace AppleScript with some other OSA-compliant language. It seems that Apple still hasn’t figured out that the power of AppleScript has nothing to do with the language and everything to do with their Open Scripting Architecture technology.
Worse yet, they seem convinced that the similarity of AppleScript to English is something that makes it easier to learn. Experience has shown me that what it really does is makes it incredibly frustrating to learn because it feels as if there is no formal syntax at all, and it is all but impossible to figure out how to phrase a statement without resorting to guess-and-check. And of course they also completely failed to sweep underlying technical issues under the carpet. Nobody is going to be able to write something even as simple as a script that loops through a set of files and shuffles them around a bit without quickly running headfirst into the distinction between a path to a file and a reference to a file. And all Apple does is make that lesson even harder by giving the programmer no good way to make a distinction between the two (through their sloppy use of terms in all explanations of the language) nor to figure out what they get back from a given function (through just straight up never actually telling you). AppleScript’s approach to making scripting easy makes about as much sense as making the highways safer by dropping the speed limit but removing all the traffic signals and stop signs.
100% agree!!!
I tried learning AS to do backup… what I resorted to was Perl.
AS Feels like they threw a design engineer at the problem of a scripting language.
heck… VBS feels like that as well so I guess System designers are not language designers.
I agree, and prefer perl to AS as well.
I’m still looking forward to how Automator may improve AppleScript creation with it’s GUI and canned solutions.
Nice book review. Thanks for that.
Bah. Automator will improve things, but it’s just so hard lay a fine veneer on a pile of garbage and have it stick. The moment you have to start doing something that’s hard to lay out with the GUI, all the pain will come back quickly enough.
Hello everyone, AppleScript has been around since what, System 7?
How do you script different applications, written by different vendors, with different terminology?
The answer: you don’t.
AppleScript’s fundamental problem stems from the differing models and terms that the applications in question use for their objects and actions. When you enabled you app for AppleScript, you were, to an extent, exposing your internals to the world. When you wrote your dictionary, you used terms that were, well, specific to your application.
Whe you script across applications, you have to be able to figure out (to an extent) what each application called its “thing”, whether that thing is a file, item, reference, whatever.
AS requires a lot of trial and error, because you’re manipulating another application directly. It also has enormous power for people that know what they’re doing.
Writing a backup script in applescript is like writing a graphics and print production workflow in perl. You could, but why bother? And you can’t script quark, illustrator, photoshop, filemaker, etc in perl anyway.
For the joe blow yokels who read os news, perl, shell, etc are appropriate. AS is useful across specific domains – people that need to integrate applications together. For everyone else it’s useless.
There is some really cool stuff you can do with Applescript, that is non-trivial using other languages. But damn, what an ugly syntax it has, crappy error messages and lack of decent documentation.
Now that Python has COCOA bindings, there’s no reason (for me) to code in AS.
I always think “Multi-Platform”, and AS is not.
http://pyobjc.sourceforge.net/index.php
hmmm why do a backup in AS? perhaps because you can manipulate finder with it?
what I hate is that there are not certain features to AS for the OS that it should have… don’t ask me what they were, I cannot recall exactly, all I know is I hated having to find another way to do something because a simple feature was not part of the language functions.
Really? Maybe one of these Mac Minis would be worth the plunge…
Layout is pretty good. I’d rate it 3 out of 4 stars.
When I first took a look at AppleScript when I got my Mac, I was disgusted. Worst. Syntax. Ever. I still don’t like writing it, but omg is it ever powerful. I had to learn ObjC/Cocoa programming to see this.
As for Python replacing AS… I like Python just as much as the next guy, but they serve different purposes. I can’t embed python straight into my ObjC application to talk to iTunes.
is the same problem with most command line programs.
a lack of documentation.
Worse yet, they seem convinced that the similarity of AppleScript to English is something that makes it easier to learn.
It does make it easier to learn – in the beginning. For people who know nothing about programming an english syntax definitely lowers the fear threshold.
Of course, in the long run the syntax tends to get in the way, which is why Frontier saw the light of day.
I’ve used AS off and on since the early 90’s and I’ve done some fairly heavy stuff with it, but I never did enough for long enough to feel confident (when it refuses to work, I never know if it’s my fault or theirs.)
I agree, I despise the syntax. There is a freeware Javascript plugin (the only OSA plugin that exists AFAIK); I’ve never gotten around to learning its object model well enough to try it. Unfortunately, AS inner workings are so poorly/skimpily documented that it looks impossible to write for it; most such things (including that JS plugin) seem to come from companies started by ex-Apple guys.
The biggest problem is uneven support: it is extremely painful to add AS to an application (Powerplant tries to help, but there is still a MAJOR learning curve and a LOT of typing.) The result is that “scriptable” apps are completely unpredictable. Apple’s own Finder is notorious for providing 6 apparently valid ways to do something: 2 don’t work at all (errors like “can’t get the name of file “the_bloody_name_it_can’t_get!””); 2 fail silently and return garbage; 2 actually work. I’ve done some cool things w/ the Finder, though, and it seems like it might be possible to eventually learn its dialect well enough to avoid the problems.
AS was an incredibly brilliant idea. Where people (developers and users) have put in the effort it works wonders (i.e., Quark Express.) But (yechhh) VBScript on Windows is generally easier to use and less troublesome, when supported and documented enough to even try.
For beginners, AppleScript is definitely useful as a “gateway” language. I learned the basics of programming logic from AS, and the basics of GUI programming by developing a few trivial apps with AppleScript Studio. The English syntax definitely lowers the fear factor for beginners, although I understand how someone from a more traditional background would find it aggravating.
I’ve since moved on to Tcl and Python, more robust languages for general programming.
automator doesn’t use applescript for its scripts FYI
Would Python be better to learn than AppleScript?
Off the beaten path, but does anyone else Apple and IBM slow at boosting the speed on the 970 chip. I mean once a year is a little slow. Maybe Apple better go with Intel given the slow turn about on PowerPC upgrades for Apple.
Here is a very good pdf about the new IBM etc. groups new PowerPC based cell processor thats been in the news. This paper gives a very good accessment of the future of the technology. I’m sure Apple will be introducing these, perhaps as soon as later this year.
http://www.mymac.com/fileupload/CellProcessor.pdf
oh cool, thanks!!
spaceboy29: “Would Python be better to learn than AppleScript?”
It’s a much more powerful, robust and logically consistent language, with excellent library and community support. There’s plenty of good documentation and tutorials both online – e.g. [http://www.python.org] [http://www.byteofpython.info] – and in dead-tree format. If you want to learn how to program, it’ll bend your head a lot less than AS will. (If you already know how to program, you probably won’t want to go near AS anyway.:)
As for using Python in place of AppleScript, its application scripting support is pretty much on-par with AppleScript’s: still a little rough around the edges and lacking tutorials, but getting there [http://freespace.virgin.net/hamish.sanderson/appscript.html] (self-link). Its OSA support – needed to attach scripts to applications and edit them in Script Editor – is currently limited though also improving, e.g. see [http://homepage.mac.com/philip_aker/osa/osa.html] for a promising candidate.
HTH