Replacing AppleScript with Ruby
Subject:   Good idea, but...
Date:   2007-02-28 14:07:16
From:   pauls101
the problem with Applescript isn't primarily the language. While I would certainly prefer to work in Ruby, it's not a cure all.

Applescript support is extremely difficult to do well, being very complex and poorly documented; those who try beyond the very basics (what's built into Powerplant, for example) often don't get it right or complete; very few indeed fully test and debug, let alone document beyond the frustratingly useless Dictionary resource. Last time I tried a few years ago, Apple's notoriously buggy Finder drove me to despair: of the 6 ways a given job might logically be accomplished: 2 work correctly most of the time; 3 fail with bogus errors or refuse to compile for no obvious reason; 1 fails "silently" and appears to do nothing. Debugging was limited (as in non-existent) except for a few third party programs that didn't work very well either.

Using Applescript usually means spending a long time learning the idiosyncracies of a target application, with little application elsewhere. A different scripting language might make it easier (I had high hopes for the Javascript OSA system a while back) but it won't fix all the things that make AS suck rocks.

Full Threads Oldest First

Showing messages 1 through 1 of 1.

  • Matt Neuburg photo Good idea, but...
    2007-03-01 07:50:03  Matt Neuburg | O'Reilly AuthorO'Reilly Blogger [View]

    pauls101: Yes, my book is largely about the fact, that the Dictionary is usually frustrating and that AppleScript programming ends up being mostly guesswork. (In fact, my book includes a long Appendix showing me guessing and guessing in order to develop an actual script, and explaining to the reader that this really is how you have to work and think in order to do this stuff.)

    Having said that, though, I must say that I'm of two minds about where Apple should go from here. Would it make sense also to throw out Apple events and the object model of properties and elements? It's an attractive idea emotionally (one thinks, let's just use F-Script or some similar alternative). But logically, there is so much invested in existing scriptable apps, and an Apple event, if used properly, is such a powerful means of communication and query, that one suspects that in reality, as I say in the article, Apple events are not going away any time soon. I've seen some pretty good arguments (including some, I think, from Hamish) as to why Apple events and the object model (and the dictionary) are really not so bad.

    On the other hand, let's go back to your example. Why does the Finder's scriptability suck? It's because adding AppleScript scriptability to an app in such a way that the result doesn't suck is really, really hard - so hard that Apple can't do it right. It always has been hard. So, that's an argument for your view ("let's throw out the bathwater and the baby - please!").