Comments on: Apple’s Script Official blog of Red Sweater Software Fri, 09 Oct 2015 20:11:22 +0000 hourly 1 By: Sang Coplen Fri, 22 Jul 2011 17:29:19 +0000 This web site is really a walk-through for all of the info you wanted about this and didn鈥檛 know who to ask. Glimpse here, and you鈥檒l definitely discover it.

By: Austin Fri, 03 Jul 2009 06:13:19 +0000 The issue I have with AppleScript is that it looks like English, but it’s really a very limited form of pidgen English. This makes simple things (such as “telling” one application to do a list of things) very simple, but more complex things (such as taking data from one application and putting it in another) a little confusing, as you can’t refer to two applications at once. Although “the first word of the first paragraph of the first document” may be more readable, documents[0].paragraphs[0].words[0] makes it possible to use an object-browser type interface for point-and-shoot coding rather than relying on people to read the sometimes inaccurate “dictionaries”.

AppleScript also has little or no innate functionality. The standard way of formatting a number with leading zeroes (so that files sort correctly) is to add the number to 10000000000 and take the rightmost digits.

It’s also full of barnacles from long dead OS’s. OS-X uses slashes to separate file paths, but AS defaults to colons (you inevitably have to say “the posix path of ..” to talk to most applications)

By: Pongpong Thu, 18 Jun 2009 21:44:09 +0000 Why does Python, Ruby, Bash have better tool and feature when it uses a low level language interface that was meant to be used by applescript? And why does those languages have better documentation on existing mac applications than applescript?

If you wish for a programmer’s language, why not just go straight Carbon instead of scripting?

The only case I can think applescript got outdone is in Adobe API where Javascript is far less buggy and more documented. Even in that case Javascript only works on application level, Applescript still got the bigger advantage on the larger scope because it can interface with other application such as terminal and system events while controlling the Adobe API.

By: ian parker Sun, 17 May 2009 11:11:48 +0000 i’ve said it on another site discussing the same issue. AS is one of the few languages that can pass muster in terms of writing, reading and saying. yes, saying. How many computer languages are designed to be spoken by a human or for that matter read (out aloud) making it comprehensible as spoken. What would you do if you wanted the computer to understand a script in say JS or C++ as spoken?

if you consider this requirement you might as well ditch 99% of all languages that exist to day- good, bad, fast, compiled etc. But of course you would be correct in saying that they are not meant to be spoken. Who would try? Precisely!

I want to communicate with computers in a language like English, not something called C++ etc. AS I think was designed with direct human-computer interaction in mind, that is why it does not look like binary, assembler or other so called high level languages. It might be called one of the first higher level languages. To see how far this can go look at the INFORM 7 site. If you delve deeper, the way it handles phrases and objects is not like most computing languages. What’s the result of a phrase like in FORTRAN? Of course the closest is something like LISP or Scheme (and for good reason).

And “just one more thing” (that’s already been discussed) – it is the only inter-application communication language, as far as I know, in any significant operating system. AS treats big and small applications like engines designed to process instructions. Think of some how telling Excel to generate 1000 random numbers, then plot the result.

Telling as in “Go to cell…” put in the cell a formula to generate a random number between 0 and 100. Copy the contents of that cell downward 1000 times. Plot the result. This approach is not that far removed from what you do in AS. This is closer to most people’s understanding of the process, than say expressing the same thing in Java.

I would rank it (or more appropriately, AppleEvents) as one of the most powerful real (as in you can use it now) technologies in computing technology. My only criticism (that echoes some of the comments above) is that the writers of the AS dictionaries really should have had some guide for writing based on grammar and syntax. That’s it’s only fault as far as I can see, but then again it makes life interesting in the same way SMS messages (supposedly written in English) or Tweets (supposedly written in English) mangle the English language.

By: Eric Fri, 13 Jun 2008 03:08:43 +0000 Extendscript needs to grow up! A world without autoformat is a world of pain! ;)

By: Patrick Geiller Fri, 06 Jun 2008 18:08:27 +0000 Here’s to do it in RubyCocoa with the RubyConsole sample :

include OSX
require_framework ‘ScriptingBridge’
iTunes = SBApplication.applicationWithBundleIdentifier(“”)

If you want to do it in Javascript, I think using JavascriptCore and some Cocoa code to bridge SBApplication in would be the way to go.

By: has Thu, 05 Jun 2008 03:09:01 +0000 Sal: “AppleScript is about exploratory programming. It’s trivial to write AppleScripts, particularly if existing scripts for similar purposes exist. ”

Um, Python, Ruby, Bash, et-al are about exploratory programming too, and rather better at it than AppleScript too given their far better tool and feature support.

What AppleScript is really about is offering non-programmers (such as myself, once upon a time) the chance to control their Macs without having to spend months or years slogging away on CS courses just to do so. Although in practice it’s really a bit of a bait-n-switch, since AppleScript’s wonderful high-level readability (i.e any non-programmer can look at AS code and immediately get the gist of what it does), is not matched by its low-level readability (i.e. following the actual mechanics involved, which AS’s ambiguous syntax actually obfuscates) or writeability (which requires an understanding of both high-level and low-level aspects). Still, the state of the art in end-user programming has moved on quite a bit since 1993, however (e.g. c.f. the aforementioned Alice, Scratch, and not to forget Apple’s own recent recons: Automator and Quartz Compositor), so maybe you can take another stab at the problem one of these days. “Write one to throw away”, as they say.

Sal: “Although AppleScript is the native scripting language of the OS, other languages such as Ruby or Python have access to the same Apple event interfaces of applications through the use of the Scripting Bridge introduced in Leopard. If you want to write your scripts in Python, there are no barriers to doing so. ”

…apart from Scripting Bridge sucking, and appscript requiring separate installation, that is. Also the lack of a fully capable OSA version of Python (or Ruby), which means attachability is largely out. And the relative shortage of community-based resources and knowledge. I wish it was as easy as you make out, Sal, I really do, but I’ve been beating at the problem for nearing five years now and others (e.g. Chris Nandor) even longer, and while some progress has been made we’re still a long way from Python, Ruby, ObjC, etc. being true peers to AppleScript.

If anything, SB has knocked things back as, aside from being rough and buggy in its implementation, its clumsy, smart-alec attempts to dress up Apple event IPC (which is RPC+queries) as something it’s not (Cocoa OOP) only creates even more confusion amongst users about what is going on, and makes transition between AppleScript and SB even more painful since there is now two layers of obfuscation (AS’s and SB’s) for nascent switchers to navigate through.

Y’know, if SB’s design says anything about Apple’s own feelings on its current IPC setup, it’s that you’d really like to see the back of it too. This is nothing to be ashamed of, mind, and any time you’d like to discuss a potential successor I’m sure there’ll be no shortage of application developers, scripters, and bridge designers who’d be delighted to offer what suggestions, criticisms, knowledge and experience they can.

By: has Thu, 05 Jun 2008 02:35:40 +0000 “Apple should make JavaScript its default scripting language.”

A few comments:

There are two orthogonal issues here:

1. End-user programming

2. Mac IPC.

#1 is a major essay, not to mention challenge, in itself, and I don’t really fancy going into it here beyond by pointing interested folks towards Carnegie Mellon’s Alice and MIT’s Scratch environments for some inspiration. Obviously, their presentation is geared towards a younger audience, but they should still give some idea of where AppleScript as an end-user language should be at: providing novice users with guided, structured input that makes writing code (AppleScript’s great weakness) as easy as reading it (AppleScript’s great strength).

As for #2, any language can cater to this need if provided with suitable bridging; AppleScript’s status as the popular choice is _solely_ down to it 1. being the only platform between early Frontier and late appscript that didn’t suck at Mac IPC to some degree, and 2. being bundled by default with the Mac OS for users’ convenience. Once the publishing folks started to build their workflows on it, for better or worse its place in OS X was assured.

So where do we go from here?

Leopard introduces Scripting Bridge, of course, but to be brutally honest it kinda rolls things back to the ‘sucks to some degree’ stage due to being both more obfuscated and less reliable than AppleScript, and its only real advantage is being bundled with the OS by default. How much it may improve remains to be seen: its design is such that it’ll never work as reliably as AppleScript short with today’s applications, which developers have spent the last decade designing, testing (or not, as the case may be) and deploying purely against AppleScript, its bugs, quirks, particular ways of doing things, and all. It also treats Python and Ruby users as second-class citizens compared to AppleScript, deeming them not sufficiently worthy to merit native APIs (SB syntax is especially ugly in Python, though a number of Rubyists I’ve spoken to have expressed their dislike of it there as well).

Appscript works better (very nearly as well as AppleScript, and occasionally even better), but lacks the official Apple blessing and bundling that prevent it being a shoe-in for a lot of folk (public distribution of appscript-dependent scripts being the main hassle). Also, while appscript has slowly built up a reasonable user base over the years, it’s still nowhere near the level needed for it to be completely self-sustaining – which means that anyone using appscript today still has to learn some AppleScript in order to understand existing application documentation and sample scripts (which are almost always written for AppleScript), to ask application-scripting-related questions (since most of the shared user-to-user knowledge still lies in the AppleScript community).

As for introducing other languages to the mix, specifically JavaScript…

Well, the main disadvantage of JavaScript is that while it’s popular in web programming it has very little desktop presence, which means it’s severely lacking in general purpose libraries and tools compared to other established languages such as Python and Ruby.

OTOH, the main advantage of JavaScript is that it’s designed from the get-go to be easily embedded in potentially hostile environments. This is a significant advantage over Python and Ruby when it comes to creating full OSA-aware languages – which you need in order to write scripts that can be invoked from within applications via the language-agnostic OSA API (folder actions, Mail rules, etc). This is one area where JavaScriptOSA, for all its other faults (flawed, incomplete application scripting API; lack of updates for OS X; lack of popular support), still ranks over all other third-party options. The closest I’ve got is with PyOSA, which is my second attempt at a solution, and is unlikely to make it past developer release status (see its included documentation for a list of problems in OSA-ifying Python and Ruby). And no language can claim to be a *100%* replacement for AppleScript unless it’s available in fully featured OSA component form.

So while JavaScript isn’t an ideal choice, it might still be the best bet as far as a successful implementation is concerned – although whether or not it can gain a sufficiently large userbase to be self-sustaining is another question.

However, there is one other possibility that nobody’s touched on: relegate the current Apple Event Object Model and OSA component architectures to legacy status, and introduce new successor technologies designed specifically for the modern OS X environment. Now, on the face of it, this sounds like crazy talk: toss existing, established technologies for something new and unknown. However, while it certainly would be a radical move, I think in the long run it would be the best for users, developers and Apple alike.

Here is the problem: the current AEOM technology was designed for a wildly different environment: slow 20-40MHz hardware and an OS with frankly abysmal multitasking support (until OS X, Macs were limited to 60 very expensive context switches per second). To try to work around this limit, AppleScript’s original designers – who were basically working from a blank slate – pulled all sorts of heroic manoeuvres in their design that basically meant shoving an huge and unrealistic burden of complexity on application developers. The resulting design was then hopelessly under-documented, and then tossed out to developers to sink or swim on their own as the AppleScript team was broken up and the technology left to stagnate for the next several years.

The result is that it is effectively impossible for developers to implement a completely reliable scripting interfaces in there apps as there are far too many complex/corner cases to account for. Even Apple’s own Cocoa Scripting framework is still riddled with bugs, quirks and deficiencies after several years of trying to make it work right – and if Apple can’t make their own technologies work properly, then what hope for anyone else? Therefore, ditch it, and replace it with a simple and dumb, but fast and reliable alternative; Mac OS X’s multitasking performance is easily good enough that users can afford to send a larger number of simpler events to achieve the same ends as the AEOM promises, but all too often fails to deliver, in fewer, more complex messages. (BTW, William Cook’s HOPL paper on AppleScript discusses fine-vs-coarse messaging and their tradeoffs, and basically comes down on the side of fine messaging for the deskop as well.)

As for ditching the OSA API, well, its old and gnarly Carbon whereas the current hawtness if Cocoa, so on marketing grounds alone, the less seen of it, the better. However, my main argument against it is that, while it claims to be language agnostic, in practice it is completely designed around and for AppleScript, and the assumptions it makes on AppleScript’s behalf – such as the assumption that scripts will all live and execute within the host process – are a real pain when it comes to creating OSA versions of popular languages such as Python and Ruby. A replacement language plugin system using the modern CF/NSBundle APIs would be a much easier sell amongst application and language developers. Attachability has such huge potential for the Mac desktop – easily as much as Apple event IPC – yet the number of applications that use it is small, and the number that use it for anything non-trivial vanishingly so. The concept of allowing users to extend and modify their desktop applications is a wonderful one – it’s just the current execution that sucks.

By: Kevin Purcell Thu, 05 Jun 2008 02:32:19 +0000 Is Daniel’s version better than this transliteration in AppleScript (should be roughly right … it’s years since I did AppleScript) with nested tells

tell application “MarsEdit”
make new document
tell document 0
set the title to “Hello from AppleScript”
set the body to “I sure like writing this post from Script Editor.”
set category names to {“Articles”, “AppleScript”}
send post to weblog
end tell
end tell

Seems self-explanatory and doesn’t look like Frontier or have extra document[0] cruft.

BTW, AppleScript does have an object system and protypical inheritance. Really!

One of it’s weaknesses (aside from people not groking the OSA … see Sal above) the other was missing some language features (e.g. hashes or associative lists) and more libaries for regex work (and the like, I know OSAXs can do this but they were never standardized).

Another was a decent development environment (you want a debugger? That’s a third party opportunity!)

Late Night Software have an OSA Javascript component so you can do this today. As well as a decent debugger.

Another thing missing from the OSA system was a place to keep data in some structured way. HyperTalk had HyperCards cards but again (the win of OSAs) had other apps. But nothing was provided by default.

Finally Applescript (and other OSA languages) are used a lot in workflows (especially publish workflows). That’s one reason Apple won’t be pulling AppleScript or OSA soon.

Finally I won’t mention factored apps. The holy grail of OSA. Imagine applications that you could modify on the fly or add features to. Route everything through OSA and people could change your app. Never really happened (perhaps the closest we get is a script s folder). Still NicePlayer doesn’t know how to force video to 14:9 but I have an AppleScript that tells it ow to do that. Neat feature and I don’t have to big the developer.


By: Mo Wed, 04 Jun 2008 21:42:02 +0000 Ken:

Just because the engine is shared doesn’t mean the environment is.

I can write code *right now* that uses, say, Mozilla’s JS engine—identical to that in shipping Firefox—and let it execute scripts which can do all kinds of funky things that you can’t within the context of a browser.

The point here is that Apple will start shipping, along with the KJS framework included with Safari/WebKit, a bridge between it and OSA, making for a good, ubiquitous system-wide scripting language.