appscript on GitHub
Matt Neuburg (via Clark Goble):
Hamish has made it very clear that he isn’t willing to touch this code any further. So it seems obligatory that someone else should put it in a place and form where people can fork it and continue to maintain it. Here it is, then.
There’s no reason in the world, for example, why appscript should stop working just because Hamish insists on using ascr/gdte as a way of fetching an application’s dictionary. There are many other ways to fetch the dictionary that work perfectly well with appscript. The next step, clearly, will be to commit some of those into this repository.
3 Comments RSS · Twitter
Very nice development. I don't share has' pessimism about the future of AppleScript and Apple Events on the Mac. His work is foundational in this field (along with Jonathan Guyer's Tcl work and Chris Nandor's work with Perl), and it's great that Matt has found a home for it. (Hoping to find time to help Chris Nandor update Mac::Glue as it currently doesn't build 64-bit, but time is the rarest commodity I have...)
@Michael: Matt's fork has been around since last summer. I've not tried it myself so cannot comment on the robustness of his SDEF parser. One of the reasons appscript stuck with AETEs is that I found OSACopyScriptingDefinition's AETE->SDEF converter didn't accurately translate all AETEs, creating compatibility problems with some apps that supplied their terminology in AETE format.
@Kevin: The AppleScript stack is legacy technology; anyone can see that. Apple's attempts to Cocoa-ify it (Cocoa Scripting, Scripting Bridge) are painful clunkers; the Carbon APIs are all legacy or deprecated. Its design is arcane and archaic, and painfully predates the multi-user Unix-based OS X, ubiquitous network connectivity, distributed computing, modern security requirements. No part of it has been ported to (or had any design influence on) iOS, which is what dictates the direction of Apple's development plans now.
The future of IPC on iOS and OS X clearly lies with XPC Services: low-level, ad-hoc, task-specific, fine-grained message passing (plus a rehash of Distributed Objects) aimed squarely at app developers only. The OSA component architecture is *dead* (the Carbon Component Manager on which it's built was aggressively deprecated in 10.8).
Apple has lost interest in promoting languages other than Objective-C (painfully demonstrated by their withdrawal of support for MacRuby, a far more popular and developer-friendly platform once slated for inclusion in OS X). The AppleScript language is flawed and weak; too complex and tangled to really be a good end-user programming language; too slow and underpowered to be interest to professional coders. Apple's own desktop applications can't muster more than half-hearted, second-rate support for it: scripting support is moribund in their Carbon-era apps, and sucks to various degrees in their Cocoa apps, or is simply absent altogether. The overall AppleScript ecosystem is stagnant or declining, and its user base much too small to have any influence over Apple's bottom line. The only reason Apple don't pull the plug outright is that they've no need to: they can simply starve it of support and let it quietly fade out in its own time.
Every attempt to make Apple event IPC appeal to developers has ultimately failed: the server-side frameworks an expensive PITA to develop for, the client-side libraries mostly crap to use, and its RPC+relational query model almost universally misunderstood and loathed by OO/Cocoa programmers (not least Apple's own). To be frank, I think a significant percentage of application developers are just too arrogant/ignorant/lazy to accept anything that doesn't fall neatly into their narrow object-oriented mindset. (If you look at web app developers, you see exactly the same sorts of large-scale misconceptions and screwups/rejections of REST, HTTP and the web in general, and the popularity of OO-code-monkey-pandering horrors like Rails and SOAP.)
The AppleScript stack was a great idea, a flawed execution, and utterly not in keeping with either the original or modern Jobs-esque Apple's vision of personal computing as consumption-oriented, mass-market appliances and services. You can assign blame however you like, but the hard fact is it's had its opportunities and it's blown them. I've sunk somewhere between five and ten thousand hours into the platform myself, so when I say I believe it only has another 5-10 years' life left I do not do so lightly, nor do I take any pleasure in it. But I am a pragmatist: change is inevitable, whether for better or worse; you deal and move on.
As far as the long-term future of desktop automation on iOS/OS X goes, the best I think anyone can hope for is embedded JavaScript interpreters manipulating DOM-style object models within individual applications, possibly with some sort of limited gated mechanism for passing messages (or possibly sanitized code blocks) between processes running on a single device or related devices. I would strongly suggest that the handful of Mac developers who do actually care about and genuinely understand what AppleScript was originally trying to achieve devote their attentions to figuring out how to make such a system suck as little as possible. Preferably before Apple decide to have a go and make a balls of it themselves, since open platforms, end-user programming, and anything involving IPC, networks or distributed computing are not amongst their strong points.
