# A couple of AppleScript topics

Do you mind if I make a suggestion? I think it’d be good for you to cut back on some of the Apple-centric sites you subscribe to or visit regularly. I mean, how many stories about the new iPad and Mike Daisey do you really need to read? Can’t most of them be summarized as new iPad: good; Mike Daisey: bad?

I’m not saying you should stop reading about Apple or the Mac or iOS. Just stop reading the same stuff repackaged again and again and posted on different sites with different “authors.” In its place, start reading original material. It’s a little harder to find because it usually doesn’t appear in the circle jerk of links from the newsnreview sites, but it’s worth the effort.

Here’s an example: Clark’s Tech Blog. Clark Goble is consistently smart, and he doesn’t write about topics just because they’re trending. Last week, he wrote an article about Apple’s growth and quality that’s had me thinking ever since.

Here’s the part I can’t get out of my head.

I still worry about OSX for a few reasons. For one I don’t think they’ve really figured out an OSX strategy against iOS. Clearly most consumers will be getting iPads – especially as iOS matures. And I think Apple’s doing a reasonably good job making iOS and OSX more consistent with each other to novice users. However I think it clear that OSX will be the OS for people whose needs can’t be met with iOS devices. This implies it should end up targeting more power users or near power users. Yet we’ve not seen that focus. If anything we saw the opposite in Lion. I think it undeniable Apple lost focus on Power Users so it’ll be interesting to see what they do next.

The notion that the Mac is for power users and the iPad is for everyone else fits in perfectly with Steve Jobs’s car/truck analogy, but while Steve was laying out the future of iOS and the iPad, Clark is laying out what should be the future of the Mac. A future that Apple has been fumbling around with for the past year or so.

In some ways, Apple is in a difficult spot. They can’t position Macs as the computer for power users, because that goes against the grain of almost 30 years of marketing and OS development. Power users benefit as much as anyone from improvements in ease of use, but we can’t live on three-finger swipes alone. After the scare of sandboxing and the partial relief of Gatekeeper, we’d like some clear signs that Apple is thinking about scripting and interprocess communication and won’t leave us high and dry.

Clark takes the optimistic view that Apple will eventually give us an improved scripting and IPC language. Gabe Weatherhead at Macdrifter,1 on the other hand, envisions a dark, distopian future in which there is no middle ground between Automator workflows and full-blown Objective C development. I’m somewhere in the middle, convinced that Apple will continue to provide AppleScript as its IPC medium for at least a few more years.

If Clark is right, AppleScript will be deprecated in favor of something better, a language I’ll be happy to move to before Apple pulls the plug on AppleScript. If Gabe is right, AppleScript will be deprecated in favor of two existing programming environments, one of which is too simple to accomplish what I need and the other of which is too complicated for me to whip up quick solutions. Is it any wonder I prefer Clark’s future?

But whoever is right, I think it’s safe to say that AppleScript is the IPC scripting language of the next couple of years, and given that the Python appscript library has been abandoned, I’ll have to write in AppleScript if I want to communicate with Mac apps like Address Book, Calendar, Safari, and PDFpenPro.

Which puts me in an awkward position. I’ve written dozens of AppleScripts, and I’ve posted them here as if I know what I’m doing, but I’ve never really learned AppleScript—I’ve just puttered about, grabbing hints from here and there and cobbling together scripts that seem to work most of the time. If I’m going to rely on AppleScript more, I need to know it better. And for me, that means getting a good reference book.

I have the first edition of Matt Neuburg’s AppleScript: The Definitive Guide, which I bought and read a good bit of several years ago. It struck me as really good in its attempt to explain the difficult ins and outs of references and aliases, but weak in specific examples. Maybe my biggest problem was that when I read it, I wasn’t writing enough AppleScripts to make its lessons stick. There’s a second edition of the book, which I’d be willing to try, but it was published in early 2006, before the AppleScript 2.0 update that came with Leopard.

I also have Sal Soghoian and Bill Cheeseman’s monumental AppleScript 1-2-3, which has become my go-to book for pressing dried flowers. Unlike Neuburg’s book, this one strikes me as being entirely a collection of examples with no underlying theory. It’s exhaustive nature actually works against it. I don’t need an example illustrating each variation of display dialog; I need a clear description of all the options and then a few examples showing how to combine the options.

I’ve been thinking about getting Hamish Sanderson and Hanaan Rosenthal’s Learn AppleScript. It’s more recent than the others, and Sanderson was the developer of appscript, so I’m favorably disposed to his work, but I haven’t heard much about this book.2 The table of contents says it has chapters on scripting particular applications, which would be good if more of them were applications I use. There’s also a chapter on Satimage’s Smile, a free AppleScript environment that provides OSAX dictionaries of regular expressions, mathematical functions, and extended file commands.

Apple’s own AppleScript Language Guide comes as both a set of online web pages and a downloadable PDF. It looks to be a little thin on examples, but the price (free) is certainly right. As a Apple product, it won’t include complaints about the language that the others may indulge in. I see that as a minus when trying to ingratiate oneself to the reader.

In some ways, it’s unfair to expect any book to act as a good reference for AppleScript because AppleScript is so very dependent on the dictionaries provided by applications. This is why examples, although essential, can’t teach the language on their own. Without a background in the language’s fundamentals, opening a new library is like learning AppleScript all over again.

If you have any recommendations—regarding these books or others that I’ve missed—I’d love to hear them. I don’t want books that extoll the charms of English-like syntax or that are pitched at new programmers. I’ve written lots of programs in lots of languages over lots of years and don’t need to be told what a variable is or why looping is important. I just want to know how AppleScript implements its set of programming concepts.

1. Another blog you should be reading regularly if you aren’t already.

2. On the other hand, I’ve heard tons of praise for AppleScript 1-2-3, and that turned out to be misplaced.

## 8 Responses to “A couple of AppleScript topics”

1. You should write a book on AppleScript. I’d buy it. There’s nothing out there that would get me to use AppleScript, even though I feel I ought to be using it to make my life simpler in a bunch of ways. I just don’t want to be learning the arcane syntax for every app that does things its own way without some guidance.

2. Ruby is probably one potential solution for Apple, no? I mean it’s practically a first class language in Xcode now, with templates included in the latest releases.

1. Jamie says:

I feel like it is basically impossible to “know” AppleScript. I say that as someone who has written a bunch of it, going back to System 7.

I’ve been learning Python, and am starting to feel, after about a year, that I get it. When I do something I haven’t done before, I generally expect how it will behave, or at least the errors make sense in retrospect. With AppleScript, it is always a game of throwing slightly different things at the compiler and seeing which one works.

I think AppleScript lacks the unofficial grammar that you see in, say Perl (or the general feel of unix), where most IPC is governed by conventions that are fluid and easy to think about on the fly. (I’m thinking pipes, textual output, line-oriented records, pervasive regexes, etc.) Python doesn’t have that as deeply, and has some annoying things that bug me (how many more meanings does the underbar need?), but it is at least cohesive.

If Automator were to fill the gap, I think developers would have to work hard to figure out how to get to that sort of fluent grammar, and I don’t know how that would work. I don’t like it, but recognize that a Unix weenie like me is not a significant part of the market for Apple, and as long as they don’t stop shipping Bash and Perl, I can get by with what I need to do. But it would be great if there were a first class IPC automation tool. Userland Frontier, back ‘when, gave me the tools for saving a magazine from doom. (not being modest, but also not kidding.) I’d be wary of investing a lot of effort in anything not straight up portable unix utilities these days.

2. Clark says:

Personally I’ve never found Applescript terribly good from books - if only because of the nature of the language. Further no two apps seem to do things in quite the same way. The best I’ve found is to just read lots of sample scripts. The language itself is rather…verbose and ambiguous.

I think I’m just sticking with appscript until the relevant code stops working. (I’ve not heard there are any problems under ML although I’ve not tried it myself) I just can’t imagine having to code in Applescript proper.

3. Thanks for pointing me to Clark’s website. I’m definitely going to subscribe to his RSS feed.

As for Apple dropping AppleScript, I wonder if it’d just break too much for them to deprecate it in the near term. Most people wouldn’t notice that it’s gone, but those that do would be really annoyed that all their time saving scripts were broken. Plus, it’d be a huge burden on App Developers to re-implement a scripting interface.

However, I could see Apple dropping AppleScript if they ever move away from Objective-C. The transition would already be painful for everyone, so there’d be no reason not to change to something superior.

4. I’m pretty sure Apple won’t drop AppleScript without giving us plenty of warning. I see it as similar to Carbon—too much investment by too many developers (real developers, not just scripters like us) to act hastily.

5. James says:

I believe MacRuby is a good place to make a retreat. Switching from Python to Ruby isn’t that painful, unless you are addicted to mandatory whitespace. ;-)

The only downside is the scripting bridge seems to be a performance issue as it takes time to load everything before the script runs. This is the bridge to the AppleScript interface.

!/usr/local/bin/macruby

framework "ScriptingBridge"

safari = SBApplication.applicationWithBundleIdentifier("com.apple.Safari")
safari.windows.each {|window| puts window.currentTab.name}

MacRuby can in fact, access the entire Cocoa API so you can build full blown OS X applications in MacRuby instead of ObjectiveC. So you get all the Ruby stuff plus all the OS X API’s. This is very much like Jython & JRuby gives you all the Java API’s and libraries and let’s you run in a Java VM / Server.

6. I really liked Hanaan Rosenthal’s first AppleScript book but it’s old and too basic now: http://www.apress.com/9781590594049

As we discussed on the twitter, his new book looks very good: http://www.apress.com/9781430223610

I mean hell, he even talks about object coercion in AppleScript. Crazy, right? I do wish there was a bit more incorporation of the AppleScript ObjC stuff. You know, to get ready for the script-pocalypse.

7. Clark says:

Scripting Bridge really sucks and there are some things you can do with Applescript or Appscript you can’t do with Scripting Bridge.

I don’t think Apple’s going to move away from Obj-C. They’ll just expand Obj-C until it has the features they want. Clearly they’re moving to making it effectivley a fully managed system only using Clang and LLVM rather than the more Java way that MS went with C#. I’m surprised they’ve been able to do it as well as they have and maintain the tight code the phone requires yet have the power for the Mac.

The big issue with Applescript is that it’s a lousy language (and Scripting Bridge doesn’t make things better). Also fewer and fewer apps (including Apple’s) support it. It also has some security issues.

Honestly neither Applescript nor Apple Events were really that well thought out or planned. It’s just that the underlying idea was a good one. Also oddly more applications used to support scripting on the Mac than on Windows. (This is sadly changed now)