The Unlikely Persistence of AppleScript

I once tried to add support for AppleScript in an application. I quickly discovered bugs with the handling of arrays of objects.

When quickly chatting about these bugs at WWDC with the guy responsible with AppleScript support in Cocoa, it becomes clear there's no motivation at Apple to make it work. I haven't even considered adding support for AppleScript since.

In general, my main hope is that a rethinking of IPC is next in Apple's agenda. Fingers crossed. There are a couple of good episodes on Applescript and IPC in the 'Edge Cases' podcast, with Wolf Rentzsch.

AppleScript is still one of my favorites OS X technologies, and it's my goal to have it in all of my apps. I use libraries by Hamish Sanderson and Jonathan Guyer to implement basic AppleScript support in my own apps; I'm grateful for their work.

@Bob I complain a lot about bugs in the frameworks, but on the whole I’ve found it pretty straightforward to make my applications AppleScriptable. No doubt there are some problem areas, but I don’t think developers should be scared away from it, and I do think it’s worth making apps scriptable. You’re probably right about Apple’s motivation. Many of its own applications still aren’t very scriptable, and some are becoming less scriptable (e.g. Xcode 4). When I was coming out of college in 2002, I looked into the possibility of working on AppleScript at Apple and was essentially told that it was a dead end, a bunch of old guys mostly cut off from the rest of the company.

@Charles In general I really like Edge Cases, but I disagree with some of Rentzsch’s conclusions about AppleScript and IPC. I think using JSTalk and Distributed Objects as an AppleScript substitute is not a good idea from a design perspective and doesn’t work so well in practice, either. (It’s frustrating trying to AppleScript Hibari via JSTalk.)

@Bob: The Cocoa devs have *never* understood AppleScript or Apple events, nor do they wish to. I know AS experts have tried to teach them; they simply aren't interested. I think part of the problem is that Cocoa is very, very object-oriented, whereas Apple events is completely the opposite: semi-RESTful RPC + relational queries.

FWIW, it's not just AS/AE that's widely, egregiously misunderstood. The same problem happens when OO devs try to do web programming (i.e. almost all of them) or work with relational databases. They simply can't think in non-OO terms, don't want to think in non-OO terms, and will resort to all sorts of awful "bridges" and hackery to avoid doing so.

I cringe when I hear an OO developer talking about their cool new "REST API" with its "endpoints" and "methods" and "payloads" and crap, and mostly just want to slap them. (My first attempt to grok REST was like that too, but I quickly got better.) I cannot abide the hubris and arrogance of ignorance that so many modern programmers display. Perhaps it's the schools' fault - so many seem to be little more than Java diploma mills these days - or maybe it's just a fundamental failing in the thinking processes of people themselves.

I think it's telling that OS X's Scripting Bridge was itself designed as an Object-Relational Mapper, presumably in a well meaning but misguided attempt to cater/pander to the great mass of OO putty brains out there. And just like every other ORM it's an 80/20/80 solution: 80% of the time it works, 20% of the time it doesn't, and 80% of the time nobody has any earthly clue why. The road to hell is paved with good intentions and clever-clever "solutions", as any fule kno.

Sometimes I look at AppleScript and am saddened at how much it's been screwed up by programmers who completely misunderstand it. And then I look at how much similar programmers have screwed up the entire web, and am a little consoled that at least AppleScript's blast radius is small.

...

@Michael: FWIW, the Distributed Objects framework is basically defunct, so I can't see that replacing either AppleScript or Apple events (yay). Unfortunately, the new Cocoa API for XPC Services looks determined to be Distributed Objects Mk2. So some sort of low-level, ad-hoc, developer-only slurry pit does seem the most likely successor to AS/AE.

Like I say, if web devs can butcher the WWW and congratulate themselves on their achievements then why shouldn't Cocoa engineers be able to do the same on a more modest scale? The only real worry is that they run out of novel new ways to screw up IPC before they run out of novel new [re-]names for iWeb/iCloud/whatever-it's-called-today.

The great irony is that in the tightly sandboxed, ubiquitously interconnected, highly mobile distributed system which is what personal computing is turning into, IPC is *absolutely everything*. I think Apple's active failure to understand the IPC beast is going to haunt them for years to come.

@has Yes, Apple is acting as if it doesn’t need IPC anymore, but without ad-hoc communication via a shared filesystem, etc., IPC becomes even more important. XPC seems fine for what it is, but my guess is that it’s evidence that Apple is ignoring the bigger picture.

The thing I've always liked about AppleScript was that it was _approachable_; I, with essentially zero programming knowledge (OK, in elementary school I had done some LOGO and BASIC on the Apple IIe, but I'd be hard pressed to remember any of it), could suddenly make my Mac and its programs perform arbitrary tasks that I needed done but which their programmers had not directly supported. Because of this, AppleScript was (and still is) _empowering_ for me, just as it was for Gruber.

And AppleScript was approchable for me because of its English-like syntax; I didn't have to decipher "weird" programmerese syntaxes just to do stuff.

Of course, I eventually ran into AppleScript's bugs, limitations, and the English-likeness monster; they were all frustrating, but for me none of them diminished my love for AppleScript nor its role as my first choice in my utility toolbox.

Once I picked up a _little_ bit of Objective-C and Cocoa and discovered how easy it was to add AppleScript support for things, I started adding all sorts of things to Camino's AppleScript dictionary. Well, I discovered that adding support for _certain_ types of things was easy; places where, either due to requirements of Gecko or 10+-year-old design decisions by a guy just learning Cocoa, our classes and objects deviated from the ideal Cocoa class/object paradigm, adding AppleScript support ranged somewhere between difficult and impossible, so there still are a lot of things I'd like to make scriptable but can't. And, yes, there were the fun bugs, like ones with arrays-of-objects or ambiguities of NSMoveCommand and positional specifiers, that were thorny and aggravating. But these issues were the exception, not the rule (well, too much of Camino has weird Cocoa objects, but most Cocoa apps aren't chimerical like Camino).

I still believe that, for a vast number of applications, adding basic, useable AppleScript support isn't that hard nor that much extra work (and if you've designed your app carefully, a lot of AppleScript support comes nearly free!). If I can do it, surely people who are actually familiar with Cocoa and knowledgeable about programming/Objective-C can do it, too. I'm thankful that there are a number of developers who think the same way and go that short (or long) extra mile to make their apps scriptable.

I definitely worry about the future, though, because I have trouble imagining any possible replacement/solution that's as _approachable_ to me (and especially to the fifteen-year-old me) as AppleScript.

@Michael: "without ad-hoc communication via a shared filesystem, etc., IPC becomes even more important."

+1E10

Locking down the filesystem - at least 'filesystem' in the traditional sense - is absolutely the right thing to do. Though there is a paradox here too, in that the Unix 'filesystem' is really a far richer abstraction than just something that maps to files on a disk. It's a generic namespace encompassing device drivers, IPC endpoints, and a bunch of other stuff too. (See Plan9 for an even more comprehensive approach.) So it would be possible to build the sort of 'interface' that's required on top of the existing filesystem metaphor/abstraction. That'd be one way to tackle it at least, but I wonder how many Cocoa/OO engineers actually grasp Unix philosophy - probably the same number that grok IPC.

"XPC seems fine for what it is, but my guess is that it’s evidence that Apple is ignoring the bigger picture."

They're obviously slowly building it out to do more, and I won't be surprised if it's eventually in a position to supersede the Apple Event Manager. OTOH, it does still seem to be rooted firmly in Apple's traditional desktop/local machine mentality; it's not a design that's going to scale to network level. IOW, it's a backward-looking, not forward-looking, design.

IMO what's really needed is an IPC system that 1. works at the network level but can scale efficiently down to the desktop level and 2. defines a robust, coherent interaction model a-la REST. But I expect you can count the number of Cocoa/OO programmers that grok REST on the same fingers as for AppleScript, and since the average OO developer seems to think the network is something to be abstracted over with OO semantics, I hold out very little hope there.

@Smokey: "If I can do it, surely people who are actually familiar with Cocoa and knowledgeable about programming/Objective-C can do it, too."

Ironically, no. You actually have a big advantage over such developers in having not come to AppleScript or Apple events with any preconceptions, so just take it as it comes. Whereas experienced developers often come with a very rigid, myopic OO mindset which they try to impose on everything they see, be it AppleScript, network programming, relational database interactions, etc.

So while you're bumbling along happily wrangling the minor everyday stupidities of Cocoa Scripting into some sort of functioning solution, they're having raging headaches caused by the high impedance mismatch between their OO mentality and the decidedly non-OO systems they're trying to shoehorn into that mentality. And rather than blame their own crippled mindsets they invariably blame the technology for being 'broken' or 'wrong'.

And even the ones who do persevere are unlikely to produce good solutions because 1. they don't appreciate how a good "AppleScriptable" application ought to look and feel, and 2. they aren't personally invested in producing a good interface design because it isn't something they'll ever use themselves. (I'll spare you the additional rant about how every attempt to address these points has effectively failed, in good part thanks to Apple themselves.)

"And even the ones who do persevere are unlikely to produce good solutions because 1. they don't appreciate how a good "AppleScriptable" application ought to look and feel, and 2. they aren't personally invested in producing a good interface design because it isn't something they'll ever use themselves."

Of course, as a consumer who is proficient with AppleScript, I'm far more likely to purchase software that has a decent AppleScript library.

Devs may think folks like me are few on the ground, which we likely are, but we few probably spend significantly more on software per capita than the non-few. Not to mention that we probably are much more efficient evangelists for a piece of software. So it's probably worth the effort on the part of devs to wrangle it all together.

-----

The Cupertino AppleScript development I've been most disappointed in is the move of AppleScript Studio away from pure scripters like me. For a brief shining moment, I could easily put together simple scripting solutions with a nice UI into apps, but that's all gone now due to Cupertino's lack of interest in doing anything for scripters other than keeping AppleScript together in bare maintenance mode....

@Chucky: "we few probably spend significantly more on software per capita than the non-few ... so it's probably worth the effort on the part of devs to wrangle it all together"

I strongly suspect the App Store sales figures say otherwise. No, it's not how I think user computing should be either (big fan of Papert, Kay and Atkinson, me), but that's how it is in ugly reality.

"the move of AppleScript Studio away from pure scripters like me"

ASS was always a no-budget hack: never a good Cocoa development solution, never a good end-user programming tool (contrast Hypercard/Facespan for that). Its death was inevitable: it wasn't a sustainable model. You should be thankful there was a replacement at all. ASOC is at least a reasonable AS-Cocoa bridge; hardly perfect, but at least usable to those who are willing to meet it on its own - i.e. Cocoa's - terms. In that, it's a huge improvement over every other half-assed AS/Cocoa technology that's come out of Apple.