Wait. Who? Sal Soghoian is Product Manager of Automation Technologies at Apple. That basically means he has been the motivating force behind AppleScript, Automator, application scriptability and the technologies that underly them. He’s been doing it for the last 20 years, and I don’t think most Mac users understand how important his influence has been to the platform we use and love. He’ll be leaving Apple on December 1, as his position has been “eliminated for business reasons.”
While I’ve met Sal several times, I don’t know him on a personal level. I’ve seen him speak numerous times, and like many long-time Mac developers, have benefited from his passion and consistent evangelism of system-level scriptability.
Why do I care? Indeed – why do we care about this? Well, let’s rewind a bit and set some groundwork for why Sal’s contributions matter so much.
Interoperability – from Copy/Paste to AppleScript. We all take copy and paste for granted – of course I can copy an image out of Photoshop and paste it into Mail, right? Well, it didn’t always work so easily – the Mac was the first major platform that standardized that by providing system-level support for standard image types and an extensible way to move them between applications. The key was that it was natively supported by the system, so developers could add it to their apps and it worked the same way, with the same basic data formats, in all applications. You could copy and paste between any applications.
Like copy and paste, in 1993 Apple added system-level support for scripting. Instead of every developer inventing their own custom scripting language that only worked in their application, Apple created AppleScript – and more crucially, AppleEvents beneath it that provided a rich way to send commands and data from one application to another. Many applications have scripting dictionaries built into them, letting you, or any application, send commands to do useful stuff.
Anyone can create simple or hugely complicated AppleScripts to do all sorts of things – from changing the format of all image files in a folder to automating email handling to batch-processing audio and video clips for movies. You can use all the best-of-breed tools on the Mac and string them into workflows that meet your specific needs. That’s always been one of the Mac’s big advantages – you can combine applications to accomplish more than any of the individual apps can do themselves. Apple’s Automator application even tried to make this accessible to everyone – with varying levels of success, depending on who you talk to.
But I don’t use AppleScript. So I don’t care, right? You may not directly use AppleScript, but many applications use AppleScript or AppleEvents in lots of little ways. iTunes, for example, lets you pause, play, go forward and backward a track, change playlists, add properties to songs, and a zillion other things. Those little iTunes controller apps that live in your menubar or dock? They use AppleScript to talk to iTunes. The ones that add lyrics to the currently playing song at the push of a button? Yup, AppleScript. Applications that grab the current page from your browser? AppleScript. The “contact us” button in an app that automatically creates an email in Mail with a subject and the To: address filled in? AppleScript. There’s probably something on your Mac that uses AppleScript or AppleEvents, even though you’re not aware of it.
So where does Sal come in? Sal is the guy at Apple who has kept this whole vision alive. He prodded developers to add AppleScript capabilities to their applications. He kept system-level scripting a priority – or at least on the radar – at Apple. He spoke at WWDC and numerous other conferences, showing how powerful the technology was. He explained to developers how a little work on their end could yield huge benefits for scripting-aware users.
My fear is that with Sal’s departure, Apple’s waning interest in scripting, and application interoperability in general, will be gone for good.
Losing interoperability. So if system-level scriptability disappears, what do we lose? For starters, it makes it harder for one application to talk to another or to use another application’s capabilities. Those iTunes controllers wouldn’t be able to talk to iTunes. My own product, Default Folder X, tracks your recently-used folders and then lets you go back to one of them in the Finder, Path Finder or Terminal. The latter two wouldn’t be possible (or would be much harder) without AppleScript. And when someone tweeted me that they wanted to use iTerm2 instead of Terminal, I could add that in 10 minutes because iTerm2 supports AppleScript.
Yes, those are little things, but sometimes they’re the little things that separate an acceptable application from an awesome one. I’ve always felt that the interoperability between Mac applications was one of the things that distinguished the Mac from other platforms like Windows. Even when you can get the same applications on both OS’s, everything is just tied together better on the Mac. I hope that doesn’t change.
Oh, and if you do use AppleScript? Yeah, this sucks even more.
[…] Jon Gotow: […]
[…] as Brent says (and as I detailed in an earlier post), many Mac apps use Apple events to directly integrate with other applications. They tie everything […]
[…] as Brent says (and as I detailed in an earlier post), many Mac apps use Apple events to directly integrate with other applications. They tie everything […]