The unlikely persistence of AppleScript

First, a little history:

Apple acquired NeXT at the end of 1996, with the plan of using that company’s OpenStep operating system as the foundation for the future of Mac OS. The first plan for that OS was called Rhapsody, and the basic idea was that it was OpenStep with a Mac-like appearance.

The idea was to keep all the NeXT stuff and throw out all the Mac stuff. That idea did not fly—particularly with existing Mac developers. This forced Apple into a new plan, Mac OS X, which was a hybrid of NeXT and Mac technologies. That plan was more complicated and took significantly more time to implement—Mac OS X 10.0 didn’t ship until March 2001, and arguably wasn’t truly usable until 10.2 in May 2002—but it garnered the support of developers and Mac users.

Over the course of the intervening years, though, Mac OS X has evolved in a decidedly NeXT-skewed direction. Mac OS X technologies that began life at NeXT (such as Cocoa and Services) have thrived; technologies from the classic Mac OS (such as Carbon) have been deprecated and eliminated.

AppleScript, however, is an exception to that evolutionary pattern—and, in many regards, an exceptionally surprising one.

Not the only one

AppleScript first appeared in System 7.1 in October 1993, as the first and eventually canonical Open Scripting Architecture (OSA) scripting language. The idea was that OSA would provide a low-level architecture for both inter- and intra-application scripting—in other words, a consistent, system-wide mechanism for multiple applications to communicate and exchange data with each other, and for users to automate tasks within any scriptable application. Instead of each application creating its own incompatible macro language, there’d be one universal way for Mac apps to be automated.

AppleScript was not originally intended to be the only OSA scripting language, but it was. The idea was that OSA was language-agnostic, and the plan was for there to be several of them eventually. AppleScript was the friendly language, derived from HyperCard’s HyperTalk (therein another story entirely) and intended for use by non-programmers. The theory being that a programming language that looked like prose rather than code might enable a broad swath of “non-programmers” to, well, program.

The idea was that eventually there might be a more traditional OSA scripting language (something that looked, syntactically, more like a language like C or Pascal) for advanced users. That dream never really took hold. There were a few obscure exceptions (developer Mark Alldritt created a version of JavaScript that worked as an OSA scripting language, for example), but AppleScript was the only OSA language that ever had support from Apple or traction among users.

A foreign language

What makes it so surprising that AppleScript survived and remains a fully-supported-by-Apple technology today (including in OS X Mountain Lion) is that it was never loved by anyone. It was a fine theory and noble experiment, but it turns out that an English-like programming language didn’t really enable a large number of users to become programmers. And conversely, AppleScript’s English-like syntax often made (and to this day continues to make) things more difficult and confusing for scripters, not less.

Put simply, the number of programmers in the world who consider AppleScript their favorite language could fit in a very small car, or perhaps even share a bicycle. But, as noted, AppleScript was the only OSA scripting language that ever gained any traction.

Making the odds even longer, OSA-scriptability required low-level architectural support from application developers. Developers couldn’t just flip a switch in the compiler to make their apps scriptable by AppleScript; they needed to add scripting support manually, through very hard work. And Cocoa, the application framework from NeXT, was not originally designed with AppleScript in mind.

Still alive and well

To recap: Decidedly old-school-Apple/pre-NeXT technology. A programming language syntax that frustrated experts and failed to achieve its intended goal of empowering non-programmers to program. A technical mismatch with the Cocoa application framework. You need this historical context to understand how unlikely AppleScript’s long-term success was. Someone with access to a time machine could make a lot of money by going back to Apple’s Worldwide Developers Conference 1998 and accepting wagers that AppleScript would be alive and well in the year 2012.

But alive and well it is.

I’ve had, from the outset, a more decidedly bifurcated love/hate relationship with AppleScript than with any Apple technology ever. I despise the syntax of the language—its ambiguity, its propensity for hard-to-spot terminology conflicts between different scopes, its general verbosity. But I love what AppleScript enables me to do. The automation of oft-repeated tasks. Creating my own small little features within my most-used and most-depended-upon apps.

I’m writing this article in BBEdit, an app for which I began writing AppleScripts over 15 years ago. I use some of those 15-plus-year-old scripts today and every day. I write new scripts all the time. The details of what I use it for don’t matter so much as the bottom line, which is that AppleScript allows me to add my own features to the apps I use most—features that may well not make sense for the typical user but which save me time and aggravation.

And in a very real sense, modern AppleScript has quietly achieved its original goal of enabling non-programmers to create their own software—not through AppleScript scripting but instead through Automator, which is built on the same underlying technology and is arguably more popular than its predecessor.

AppleScript has survived and remained relevant during a turbulent decade-long transition, despite its unbeloved language syntax and technical hurdles, for the simple reason that it solves real-world problems in a way that no other OS X technology does. In theory, AppleScript could be much better; in practice, though, it’s the best thing we have that works. It exemplifies the Mac’s advantages over iOS for tinkerers and advanced users.