The FooDoo Lounge

Index of Rants

Learning AppleScript

I started learning AS in 1996, a year or so after I got my first computer. My first project was a backup script which I updated many times and used every day until I migrated to OS X full time.

I found the whole scripting thing quite alien at first - "If this is like English, then I must be, like, Klingon..." - though I was completely taken with the idea of making my LC475 do exactly what I wanted it to do. It started to make sense after a while, particularly once I'd had a few things explained to me, though all I succeeded in doing initially was crash a lot. I had no experience of any other languages then and still really only know AS. I can hear perl calling my name, but I'm trying to resist.

There are quite a few good AS books - I've read The Tao of AppleScript and Goodman's Complete AS Handbook - but I really only found them useful at a point that was almost, but not quite, exactly when I no longer needed them. I don't know why that is - probably just me.

The other major resource is the much maligned AppleScript Language Guide. People often complain about the lack of documentation for AS and some of those who read the ASLG still complain, but it is the primary reference and I find it both comprehensive and well written. It won't tell you anything at all about scripting any particular application (including the Finder), nor does it describe Scripting Addition commands, but it does contain probably everything you will ever want to know about the language itself. Like the other AS books I've seen, it wasn't all that helpful to me when I was trying to get started, though I now recognise it as a good reference and use it regularly for this purpose.

More recently, I studied a book called The Pragmatic Programmer, which I found to be exceptionally useful. Apart from the fact that they don't seem to have heard of the Mac, I think these guys really know where their towels are.

The two main AS lists - AppleScript Users and MACSCRPT - are both an excellent source of knowledge and tend to be frequented by many of the brighter lights of AS. Members of the AppleScript team, mainly Chris Nebel, contribute to AS Users regularly.

I've seen a number of people on these lists complain that AS is hard to learn. Most of these comments seem to come from people who know something else about programming. The fact that developers of apps and osaxen determine their own terminology to a large degree, and with varying degrees of skill, means that the scripting can be very different from one program to another.

This flexibility is, I think, one of the language's strengths, but it means that every developer has the option of creating a poor, or even just quirky, AppleScript implementation. It seems to me that very few of them are done by people who understand what AS is about and lots of heavily scripted apps are notoriously difficult to learn. That's not entirely a fault in the language though. I got very used to experimenting when I started - it was the only way I could work some things out - so this characteristic wasn't obvious to me. It seems to really irritate some people though.

One of the things I think is important in learning AS is to know who you're talking to. In other words - scope. For example, scripting addition commands are best outside of explicit tell blocks to applications. Having a clear idea of whose terminology space you're operating in makes life much easier, but working this out takes a bit of effort.

People often start out thinking that the Finder is AppleScript, but it's just an app that is scriptable that happens to do file management on the computer. The Finder knows quite a lot of things about files and folders, yet the 'info for' command is provided by the Standard Additions osax. Confused? You're not alone.

The partial solution is to study the dictionaries of the things you wish to control. If you don't know who handles what, then, at very least, take a look at the Finder and Standard Additions dictionaries by dropping their icons onto your favourite script editor, or by choosing "Open Dictionary..." from within the editor. See the ASLG, page 34, for more info.

How I code

My focus is on producing code that is reliable, fast, and hopefully even elegant on occasion. In roughly that order.

I use Script Editor mainly and tend, or at least try, to start things with a succinct plan - maybe just a one line description - which goes at the top of the script. I progressively fill in the details of that, and then write the code to do it. More or less, anyway. ;-)

I use libraries (ASLG, page 287) wherever possible and have a core set of about 30 handlers - baseLib - which I load into scripts to provide all the basic services I use frequently. This lib contains generalised handlers and some higher level services I use often. It is updated as infrequently as possible and I try to test things ruthlessly before I put them into baseLib.

I do tend to document things these days, which I know a lot of people hate doing, but it's a great planning tool apart from anything else, and it really helps me keep track of all the different stuff I do. I figure that it's worth spending some time documenting a project when I'm working on it, because that's when I understand it best.

The work on this site

Most of the kiteWare projects here have been refined over time and contain stability and speed tweaks that may not be all that obvious at first glance. The Dialog Director scripts may be of interest to others who use, or would like to use, this powerful tool.

I try to make everything as modular as possible and I hope the code is well organised and clear. I subscribe to the "don't comment the obvious" school of thought, so the scripts don't tend to be full of them, but it does vary. Some of these projects are a few years old now and that stuff tends to be more verbose. The scripting tools are more heavily commented.

Not all the source code is included, though all the scripts themselves are editable. Libraries, where used, are loaded at compile time, though copies (some editable, some not) are included in case something needs recompiling.

I am really happy for scripters to learn from my experience as I have done from others, so be my guest - look at the editable code, make a copy to pull apart, test it, see what it's really doing: Play with it!


The FooDoo Lounge is Copyright © Richard Morton 2002-2005

|| url:
|| created: 12-Nov-03, 1:09 PM; updated: 24-Aug-04, 1:06 PM
|| size: 18745 bytes