Fixing Applescript
Posted on June 3, 2008 by Brian Webster
Filed Under Programming, Development |
After reading Daniel Jalkut’s post about replacing/supplementing Applescript on the Mac with Javascript (or perhaps another scripting language such a Ruby or Python), it got me to thinking about what exactly it is about Applescript that tends to trip people up. Would it be possible to figure out what the problem areas are, and just fix Applescript in those areas? There would be problems to this approach, the most prominent one being backwards compatibility. Some of the problems are fundamental enough that, if you fixed them, it would cause existing scripts to break. I believe Apple actually had plans a few years back of making a “new” Applescript that mostly acted like current Applescript, but was in fact a separate language and made an explicit break with previous versions of the language. Kind of like Carbon, where 80% of the stuff would work fine, but that problematic 20% would need rewriting under the new system.
So, what exactly are the problems that vex Applescripters so? There are quite a few, but here are some of the ones I can think of.
Lack of basic language features
Many modern scripting languages come with a fairly hefty set of built in data types and functions (or classes and methods for OO languages) that support a wide array of built-in functionality. Applescript has its own set of functionality, but for many standard tasks, it frequently either lacks the ability to do so at all or supports things but in a very hard to use or unintuitive way. A few examples include:
- Sorting an array of strings: Javascript has Array.sort(), Applescript has nothing.
- String manipulation, such as splitting strings apart, easily extracting substrings, etc. Some of these things can be done in Applescript, but are much much harder than they should be. (How many people know about “Applescript’s text item delimiters”? OK, both of you can put down your hands now)
- Mutable arrays/lists. Applescript lists support some operations, such as concatenating two together into one, fairly easily, but good luck if you want to do far out things like inserting a new object into the middle of a list, or delete an item from a list. Most of these things involve twisting yourself in a knot, splicing lists apart and back together again.
- Mutable dictionaries/records. See above.
This is just a small sample, I’m sure there are many other things that are pretty standard in other languages that are absent from Applescript, or hidden away in the Standard Additions scripting dictionary somewhere.
File references are the devil
There are at least 5 different ways I can think of to refer to a file using Applescript (alias, POSIX file (a.k.a. file URL), Finder style object specifier, POSIX path, Carbon path). Different applications use different data types in different places, and will often barf back errors if you don’t use just the right kind of file reference. Figuring out how to translate from one kind to another is often maddening. Here’s an example from one of my own scripts, which uses three of the five types in a single line:
set helpFolderPath to POSIX path of ((folder “Help” of folder “en.lproj” of ptFolderAlias) as alias)
Files really need to be treated as first class citizens, with support built in to the language, and without needing to rely on the Finder for all file system access. Or wait, am I supposed to rely on System Events now instead? Or maybe a “do shell script” call to ls on the command line? Oh, the pain.
Scripting dictionaries
This is one of the biggest hurdles that a lot of beginning scripters have with Applescript, is understanding how scripting dictionaries work. Tools like Script Debugger are extremely helpful when it comes to exploring an application’s dictionary (I hardly look at the dictionary anymore these days, and just go right to the explorer pane and start drilling down), but while $199 is a fair price for a developer, most people aren’t going to want to drop that sort of change just to learn Applescript. Script Editor did get a pretty good upgrade in Tiger, but I think it needs more work to help beginning scripters understand how to explore and use scripting dictionaries.
The death of recordability
Another invaluable tool for beginning scripters which is all but dead is application recordability. Back in the OS 9 days, you could hit the “Record” button in Script Editor and go perform operations in other applications, and the equivalent script commands would magically appear in Script Editor. This was a great way to quickly learn the commands to use to do certain things you already knew how to do using the GUI of the application. Since OS X, recording has basically gone away. The only applications I know of that are still recordable are the Finder and BBEdit/TextWrangler. Cocoa has zero support for recordability. Theoretically, you can use the Carbon APIs to do this still. I actually tried once, and gave up after a couple days of banging my head against the wall. I’d love to see recordability come back, with a whole new approach if necessary, with full Cocoa support.
Applescript does have a lot going for it, but is hamstrung by a lot of these types of issues and prevented from reaching its full potential. Replacing it with another language is one way to go, but fixing Applescript also has a lot of potential. This above list is just a sample of some of Applescript’s shortcomings (if you have your own pet peeves, feel free to express them in the comments). The idea of redesigning Applescript from the ground up, with nearly 20 years of experience to build on, is very appealing, but who knows if Apple will ever have resources to devote to a project like that.
Comments
2 Responses to “Fixing Applescript”
Leave a Reply
If you have a support issue that requires a response, please e-mail support@fatcatsoftware.com
RSS 2.0
There are certainly a lot of things wrong with AppleScript, but the real sin that Apple committed was in not following through on the “per-class-of-application” object model.
Consider if there was a standard dictionary that all music-playing applications were told they should implement. Then one single Applescript program could easily control any music player. How about scripting a text editing app? Again, a standard dictionary would give you script portability. (Apple did worse than not implement it on this one–they implemented it part way and then stopped, with the default classes actually broken.)
Yes, I’d dearly love AppleScript to be a better language, but I’d actually rather that the initial focus be on making it more generally useful across multiple applications.
On the bright side, it doesn’t take Apple to do this. Existing developers could band together to publish specs. Compatibility dictionaries could be made for apps from vendors who didn’t play along. I think we’d see a lot more AppleScript development if writing a script didn’t require learning a whole new set of conventions and calls for every single app.
[…] - bookmarked by 2 members originally found by sygenos on July 15, 2008 Fixing Applescript http://www.fatcatsoftware.com/blog/2008/fixing-applescript - bookmarked by 4 members originally […]