Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h01/mnt/52932/domains/ on line 472

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h01/mnt/52932/domains/ on line 487

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h01/mnt/52932/domains/ on line 494

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h01/mnt/52932/domains/ on line 530

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h01/mnt/52932/domains/ on line 103

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h01/mnt/52932/domains/ on line 21

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h01/mnt/52932/domains/ on line 623 » AppleScript, my old nemesis…

nerd nouveau

AppleScript, my old nemesis…

When the guy that wrote the guide to AppleScript is himself thrilled to hear that you can fully ditch it for Ruby in the upcoming MacOS 10.5 “Leopard”, it’s a sure sign that there’s something going very wrong with AppleScript, and I think it is, too.

Like most of the other developers that comment on it, I dislike AppleScript because of its weird pseudo-natural-language syntax, its various quirks and inconsistencies as well as for it being one of the few left-over pieces of legacy code in MacOS X. In fact, I rarely ever manage to get the job done nicely in an AppleScript, I usually only use it as a front-end for Perl scripts, using the “do shell script” syntax so that I can access those Perl scripts conveniently from the “Scripts” menu. Even the simple glue code between the lines of Perl sometimes give me useless and irritating error messages that can only be topped by Ocaml’s lapidary “Syntax Error” when fed with a 5000 line piece of code. I’ll ditch AppleScript for Ruby in a second, too.

However, we’re programmers, so we probably expect different properties from a scripting language than, say, my mom does. But AppleScript has originally been targeted at my metaphorical “mom”, i.e. the computer user that isn’t a programmer, the user that’s probably even somewhat intimidated by the idea of programming a computer. Thusly, the natural-language like syntax seems like a good idea, but it’s carried out badly in AppleScript: While some lines of AppleScript really sound completely natural (”tell application “Finder” to select…”), others don’t, and even worse, some language constructs work and some don’t. For example, “in” and “of” have different meanings, so ‘every folder of disk “MacintoshHD”‘ can be a different thing than ‘every folder in disk “MacintoshHD”‘. That’s not very natural, and it’s one of the many reasons why AppleScript fails so badly. Little design 101: If you claim to have made something that’s “completely natural” and there are just really small inconsistencies like this in it, you failed completely at your goal. Choose another paradigm!

Then again, it’s interesting to reason about what could replace AppleScript. Obviously, Ruby (or Python and heck, even Perl) sound like fine ideas from the perspective of us programmers, but what about the ordinary, non-geeky user it has originally been targeted at? Ruby probably isn’t for everyone. I don’t think the average office worker or creative professional would feel comfortable about the concepts of iterators, currying or object-orientation. It’s just too technical.

I’ve been thinking for a while that a PureData or Quartz Composer inspired “data flow” model may be the most appropriate choice. Incidentally, Apple’s Automator, introduced in Tiger, already employs this to a certain extent: There are various actions that can be parametrized and daisy-chained to create quite elaborate workflows. The data flow model may look a bit confusing at first to a programmer, but that’s exactly its strength: It abstracts away so much from the idea of “code” that it becomes much more accessible to people without a programming background than any other scripting language I know of: Thinking of a branch in terms of, well, a branch in the graphical data flow hierarchy is much more intuitive than an if-else-then statement with its brackets, short-circuit evaluation and what not.

I don’t know what’s coming for Automator 2.0 in Leopard (You know, I’m just a poor student and didn’t want to shell out 500 bucks for an ADC Select Membership. I’ve just got a Student Membership and therefore no Leopard Early Starter kit. I’ll upgrade when it expires, though), it maybe won’t be a full, Quartz Composer like data flow, but more flexibility wouldn’t hurt. The one-dimensional way in which Automator currently works, having only a single output and a single input per action, seems to be somewhat limiting, and I’m sure that the general public can handle multiple input or outputs easily as well. In fact, it may even be a lot simpler to think in terms of multiple data flows that mix together later to form the full result rather than in a fully linear fashion: When I call somebody on the phone whose number I don’t know, there’s the “look up phone number in phonebook” part of the task, the “take phone off the hook and dial” part and maybe a “plan what you’re going” to say part. They’re independent until they flow together in the end to actually make the call. I think it’s quite intuitive to employ a similar approach in Automator as well. Constraints can be a good thing to limit complexity, but if people are already starting about how to circumvent the constraints in order to create the Automator workflows they want to, your constraints are working on the wrong level.

I’ve seen people with little to no tech background churn out amazing things in PureData and Quartz Composer, so why not with my imaginary Automator 2.0. I think it’d be a good thing.


Hi, how are you? My name is Georg Kaindl, and I'm a twenty-something from Vienna, Austria. During the day, I'm a CS student at the Vienna University of Technology, but at night, I turn into an independent software developer for the Macintosh platform, social nerd, lazy entrepreneur and intuitive researcher.

I like to write about everything that matters to considerate technology enthusiasts, but humbly retain the right to go off-topic from time to time.

My posts are licensed under a Creative Commons Attribution 3.0 License.


You can reach me by email if you have something to say that's not related to a blog post or that you don't want to have publicly available as a comment to a post.

However, you'll have to prove that you are human! Even though I personally like robots very much, I'm less of fan of SPAM. It's just a simple riddle to solve, but a SPAM bot won't cut it!

To get my email address, take the word before the .com in my domain name first (Hint: The word you are looking for starts with a "g" and ends with an "l"). Next, simply attach to this word.

Boom, there's my email address. Simple, isn't it?

Powered by WordPress

Comments RSS

Entries RSS