March 25, 2012 at 7:05 PM by Dr. Drang
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.
There’s also Mark Munro’s AppleScript: Developer Reference, which, like the Sanderson & Rosenthal book, is fairly recent and looks quite comprehensive from its table of contents. I’ve heard nothing good or bad about this book, either.
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.