Comment by hhas01

Yeah, it’s a great, incredibly insightful paper, written by one of AppleScript’s original designers.

It’s only a pity it wasn’t published a decade earlier, back when classic Mac OS developers were attempting to build Apple event bridges for languages like Perl, Python, and JavaScript. All of those popular programmer-friendly languages had their own native Apple event bridges from very early on. And all of those bridges sucked.

Not because they’re technically hard to write, but because no-one ever explained how.

And since (with the exception of Perl and Frontier) all those third-party devs were coming at the problem from a strongly OOP background, they all promptyl fell into the ORM trap: trying to make Apple events behave like the host language’s native OO, instead of vice-versa. ’Cos if you think creating an Object-Relational Mapper over half-a-dozen similiar SQL-speaking RDBMSes results in a crippled dumbed-down API that fights you more than it helps, imagine trying to create one that works fully and correctly over hundreds of wildly differing targets with no common dialect at all.

(Perl’s Mac::Glue did avoid the ORM trap, but—being Perl—ran into impedance mismatches of its own. Only Frontier got it more or less right… right in time for Dave Winer to throw his toys out the pram and sulk off.)

Thus AppleScript never won because it was good. It won because all of its alternatives were even worse.

Even the first Python appscript, which I wrote way back in 2003, was a stinker; although it did get better eventually (after I threw it out and redesigned and rewrote it from scratch). Bloodly lovely bit of kit in the end, never equalled before or since—and I say that as its most rabidly demanding and intolerant user.:) Still kicking myself for blowing the one chance to get it bundled in Mac OS X itself; Apple Automation would be in a very different place today if it had.