Apple’s Script

June 3rd, 2008

Like the rest of the Mac nerd world, I saw the announcement of SquirrelFish as very promising and inspiring news. The WebKit team has redesigned its JavaScript parser, emphasizing speed performance by switching from a parsed-tree system to a bytecode-interpreted system. The result is a much faster system that apparently offers the promise of even further optimizations as time goes by.

KUDOS to the WebKit team! When I last read about JavaScript performance, it was on Jeff Atwood’s substantial comparison of many browsers and their respective performances. At that time Safari already stood near the front of the pack, only being narrowly beaten by Opera in terms of overall performance.

I expect that unless other browsers have also been dramatically enhancing their JavaScript performance during this time, the SquirrelFish parser will put Apple’s WebKit far in front of the other major browsers in the market. At a time when JavaScript is being used more and more in web applications, the benefits of this advantage could be magnified into a noticeably superior user experience on many web sites.

What About AppleScript?

This announcement got me thinking about Apple’s scripting languages and where the most growth and progress is being seen. Here we have a dedicated product team, responsible for providing a scripting service more or less only intended for use within the context of a web page. Yet this team seems to have a stronger corporate charter for making progress than the AppleScript team, which is responsible for the language that provides system-wide scripting glue to both users and developers. JavaScript must be the single most prioritized interpreted language being developed within the walls of Apple. Yet AppleScript, an often-maligned proprietary Apple language, is still the system-wide standard.

As a variety of web technologies permeate the desktop (and other platforms such as the iPhone), JavaScript is becoming increasingly popular and well-recognized. While AppleScript is lauded for being accessible to naive users, it’s factual ease of use is becoming less relevant as JavaScript’s actual ease of use explodes. How is JavaScript becoming actually easier for users? By means of simple, forced exposure. Just as an awkward, text-based system such as HTML has become so dominant that many secretaries and construction workers are passably fluent in it, so are the majority of users who are likely to use scripting passably fluent with JavaScript.

Apple should make JavaScript its default scripting language.

There, I said it. It wasn’t easy, because I hold a soft spot in my heart for AppleScript. But I’m slightly more of a pragmatist than a romantic. If JavaScript is what Apple cares most about, and JavaScript is where massive performance improvements are going to be made, then Apple should leverage those improvements to the benefit of every desktop scripter.

It sounds like I just said “Apple should kill AppleScript,” but I didn’t. You see, the Open Scripting Architecture, on which AppleScript runs, is designed from the start to support multiple languages. Think of the “Open Scripting” part of the system as the part that lets a script tell another application to do something. The specific scripting language you use to accomplish the rest is really of no concern whatsoever. Two languages, such as JavaScript and AppleScript, can easily live side by side.

The idea of using JavaScript as a Macintosh scripting language is not new. Mark Aldritt of Late Night Software has for years published a plugin called JavaScript OSA which provides the functionality I’m talking about. Here’s a simple script in AppleScript to activate iTunes:

tell application "iTunes"
end tell

And here is the same action written with JavaScript OSA:

with (MacOS.appBySignature('hook'))

It’s a little clunky, I’ll grant you. It’s a nuisance that in this incarnation, I had to use the old-style application signature code. But these cosmetic problems are easy enough to fix. If Apple provides its own JavaScript language layer for OSA, it could divert the majority of resources it currently spends on AppleScript. Instead of struggling to keep AppleScript “modern enough,” these fine engineers could instead devote themselves to fine-tuning the JavaScript experience for desktop scripting.

Apple is leading the pack in the development of an interpreted scripting language: JavaScript. It’s time to move on. Adieu, AppleScript.

88 Responses to “Apple’s Script”

  1. Nick Says:

    I (mostly) disagree. An alternative to Applescript is long, long overdue, but Javascript isn’t the answer. The good thing about Javascript is that it’s a really well-trod language at this point and there are lots of people who know it.

    The bad thing about it is that it’s a language that’s kind of still growing up: virtually everyone who writes a lot of Javascript brings in a library or three to get “real work” done. As the standard library grows, it’s mostly gaining web-specific functionality as opposed to generally useful functionality.

    I think Apple should bundle appscript instead (available for Ruby, Python, and ObjC). These languages are all much more general than Javascript. I’m a Python programmer, and I’ve written a number of appscript-enabled scripts. It’s a joy to program and you get to use the Python standard library, which includes functionality for managing files, managing subprocesses, sending mail, and a host of other things that are simply impossible with Javascript.

  2. Chucky Says:

    “I’ve been teaching JS to non-programmers for more than ten years now. It’s true that AS is easy to read, but give me a few minutes to talk about dot syntax and JS will be equally as easy.”

    But you don’t come in the box with every computer, Dori.

    I think that folks who are comfortable with dot syntax have zero comprehension of how intimidating dot syntax is to folks who haven’t learned the secret handshake.

    The mass audience advantages of natural language are dramatically undersold by those who have already used more sophisticated languages.

  3. Jim Trebilcock Says:

    I’ve been coding in AS for nearly a decade, so naturally I have great affection for it. That being said, I would support another scripting language becoming the dominant choice for Apple.
    As many people already have said, the English-like nature of AS does not translate into ease of coding. For certain, it lowers the initial bar, in that many non-techies are tempted to try it. Truth is though that 30 minutes into your initial session with AS, if you don’t have a powerful need to use it, you are going to quit. It is a most illogical language, full of many, many rules that are not at all apparent on first – or even 41st glance.
    My company recently switched from Macs to PCs – yeah, stupid move, but what is there to say about it – and it feels frustrating that I can take none of my scripting knowledge with me. I greatly wish that I had invested some of that time I spent in AS learning JS or Python.
    Finally, let’s not kid ourselves. Apple itself has little love for AS. The language hardly has changed in years, and the last great innovation was AS Studio – how many years ago now. No, sorry, I don’t count Automator. It’s never impressed me at all. AS Studio does let you produce some strong work, but you could do the same with another OSA language and XCode.

  4. Mark Reid Says:

    I’m a programmer with several languages under my belt such as Java, Ruby, PHP, Haskell, Prolog, and R.

    Normally, I don’t find picking up new languages too difficult. I dabbled with AppleScript a couple of years ago, however, and found it infuriating. I think the reason for this is the very thing that is meant to be its drawcard, namely, it’s “closeness” to English.

    I think this “like English but not quite” aspect of AppleScript is the Uncanny Valley of programming languages. Because AppleScript looks like English it is easy to fall into the trap of believing it has the flexibility of English. When that mental model fails its more unsettling than when you screw up the syntax in a regular programming language because your mental model isn’t making unwarranted assumptions.

    Some of the comments about non-programmer OS X users liking AppleScript suggest that maybe the fault lies with me having done “real” programming for too long. That may be the case but I would have thought non-programmers like ab would just use Automater to “orchestrate several programs to get the desired output”. Surely that’s even more efficient than having to learn a bunch of scripting commands?

    I think a good compromise would be to replace AppleScript with something more programmer-friendly (maybe JavaScript) but also make it easy for those programmers to make Automater components that can be readily shared with the non-programmers who want to build processing chains.

  5. Dori Smith Says:

    “I’ve been teaching JS to non-programmers for more than ten years now. It’s true that AS is easy to read, but give me a few minutes to talk about dot syntax and JS will be equally as easy.”

    But you don’t come in the box with every computer, Dori.

    And why not, dammit? :-D

    But really, it’s easy to understand dot syntax so long as you don’t start out positive that it’s going to be too difficult to learn. There are plenty of bad teachers and bad books out there that have helped to ingrain that attitude, but it can be gotten past with some patience.

    And maybe I can’t be there in person <g>, but people can still be virtually taught by me:
    – If you don’t want to spend any money, go here and watch the freebie videos.
    – If you want to spend under $20, buy this book.
    – If you want to spend a little more, and you liked the video clips, buy the entire course.

    Hundreds of thousands of designer-types have learned enough JavaScript to do simple tasks. Wouldn’t it be great if they could leverage what they already know and use it to script their Macs too?

  6. roger purves Says:

    I have done a fair number of amateur
    pieces of code in AppleScript and
    Javascript. (Here, “done” means
    ranging through the posts of the
    incredibly generous people on both
    the InDesign Scripting site and
    the AppleScript(at Apple) site and
    copying and pasting fragments of
    code until I get something working.)
    I don’t like AppleScript or JavaScript
    much, but then I don’t like C++, C
    Java, Pascal, or Basic. My comment
    consists of two remarks on how
    languages could be more congenial
    to non-technical people.

    First, for this non-programmer, the environment
    that accompanies a language is very important.
    The environment provided by Adobe for using
    JavaScript in InDesign has such a technical
    surface compared to Script Editor. When I
    started with InDesign, I couldn’t believe
    how little had been learned from the 1984 mac.
    Adobe’s JavaScript environment is so inferior
    to the one provided by MacPascal. (Script Editor
    suffers by comparison too.) If Apple were to make
    AppleScript its default scripting language, I hope
    (almost certainly in vain) that Apple would put
    some resources into the environment.

    Second, I would like to put in a plug for the way the page:


    introduces a new language to the world. (I am in no
    way part this project.)

    I am not commenting on the merits of the particular
    language (processing) here, just the presentation.
    Most introductions to programming languages start
    at a small dark corner of syntax. The newcomer feels
    like an experimental animal placed at the beginning
    of a maze. In contrast, the people at processing.org
    have spread out a banquet of possibilities for the
    newcomer to sample. Click on something, and you
    are taken immediately to a picture accompanied by
    the code that produced it. Not interested? Go back
    and click something else. The format imparts a sense
    of openness (and confidence) on the part of the
    language designers: “you don’t need a guided tour,
    just look around”. (Incidentally, the url:


    shows someone moving processing into the world of JavaScript.)

    I would vote for JavaScript, but with a wrench. AppleScript
    was a serious attempt to reach beyond professionals and I
    respect it for that.

    Roger Purves

    (Daniel, thank you for bringing up this issue.)

  7. ab Says:

    > but I would have thought non-programmers like ab would just use Automater to “orchestrate several programs to get the desired output”. Surely that’s even more efficient than having to learn a bunch of scripting commands?

    No, I find Automater is too limited and so I never use it.

    > Wouldn’t it be great if they could leverage what they already know and use it to script their Macs too?

    You mean like English?

    Hey, I heard that on the Enterprise, most people give orders to Mr. Data in English. Is that true?


  8. GHFigs Says:

    I know nerds like to get into heated arguments over programming languages but if you’re paying any attention to what’s actually going on on the platform it’s plain as day that the trend is toward language-agnosticism. You can, right this minute, on a stock Leopard system, use AppleScript, Ruby, or Python to accomplish the same things. Install an OSAX and you get JavaScript, too. Or you can use Automator. Or shell scripts. Or any combination therein.

    Rather than perpetuating a language flame war (which is what most of this thread is, really), why not discuss a bigger issue that surrounds them all — the poor OSA support in many, far too many, applications. Without scripting support, the whole debate is moot because you can’t actually do anything with it anyway. People speak as though there are no libraries for AppleScript, but that misses the point — the scriptable applications *are* the libraries.

  9. Hywel Thomas Says:

    “However using training wheels allows a more gradual introduction to riding, it gives the child a way to figure out steering, braking and pedaling before having to learn the really hard part, balancing.”

    Using training wheels/stabilisers is about the worst thing you can do. The correct way to teach a child to ride is to first teach him to stop. Lesson one is the brakes. Lesson two is the pedals. Lesson three is starting – weight on the pedal and immediately applying the brake. This is still gradual, but much quicker and safer. They don’t fall off like they do when you take the training wheels away, having let the learn how to go pretty fast.

    I have a background in programming and testing (I guess you could call me a day coder, though I aspire to be more than that). BASIC, Pascal, Modula-2, Occam, Ada and more recently a little Java and a little Python. I’ve never really liked the C style languages much. I’ve read Javascript, and written a a very small amount. I’ve been on a C++ course, but never used it outside the course. I’ve dabbled with Obj-C, but never had time to delve into the rich depths of Cocoa.

    Given a choice, I would probably go for Python over JS. It seems less C-like. It does still have some C-style weirdness (“==” instead of “=”, where Pascal’s “:=” for assignment is better). There’s oddness like range(1,11) for a range of one to 10 that I don’t quite appreciate yet.

    I don’t think constructs like:
    for (x=1;x<10;x++){

    …are particularly friendly, but something like:

    def sum(cells)
    total = 0
    for cell in cells:
    total = total + cell.amount
    return total

    …seems fairly readable to me. Indenting instead of begin/end or {/} (a la Occam), immediately helps.

    I don’t mind if AS stays, but I would really like to have an alternative that I find accessible. All the talk that AS is readable quite honestly baffles me. I try maybe once a year to learn a little, but I find it utterly inaccessible and incomprehensible. I’ve earned a living from writing and testing software for almost 20 years, but AS is peculiarly beyond me.

    I think if a better (more traditional) scripting language were available officially, pretty much all developers would use it instead of AS. JS/Python/Ruby scripts/sites/tutorials would spring up almost overnight, and a lot of them would be a fairly gentle introduction for the non programmer.

  10. Chris Adams Says:

    @Michael: having helped a number of non-programmers with “simple” AppleScripts, I have to disagree: if they can’t copy-and-paste directly from an example, AppleScript is harder because it promises to be much smarter than it actually is – it’d be awesome if it really did understand English but it doesn’t and the stilted, non-native syntax is more confusing than a grammar which doesn’t resemble something very familiar. The other problem is simply that the language is pretty limited and you frequently run into cases where you could either use a built-in Python module or write it yourself in AppleScript.

    If I were at Apple I’d make two changes:
    * Expand the first-class supported languages by working on JS/Python/Ruby bridges to take advantage of the greater momentum they have
    * Expand Automator’s UI a bit and add a mode where it would display equivalent AppleScript (or other languages) for your workflows so people could use it as a training guide and easily move up with they outgrow pure Automator solutions.

  11. Juan Says:

    Chucky, I’m not so sure you understand that the natural language scripting is more frustrating than anything. It makes people think they can script applications, only to be proven wrong because the AS syntax is fucked and there is no documentation to speak of. The only way to know applescript is to use it a lot, at which point you’d know any scripting language Apple would offer.

    Natural Language is not accessible. It’s unnecessarily opaque. Apple would do much better with Javascript, if only because patterns are easier to discern.

  12. britt Says:

    Once upon a time in the distant past I wrote an entire database replication and server load-balancing system in AppleScript embedded in FileMaker… it wasn’t pretty, but it did work (no, AppleScript was not my first choice; it was a contract requirement that it be done only in FileMaker; using a direct TCP socket access OSAX was pushing the requirements, but otherwise it just couldn’t have been done as at the time FileMaker did not support this at all).

    What I’d really like (and if I had time, would implement; all the required hooks are there) is an interpreted Obj-C with cross-application capabilities (perhaps leveraging DO?)

  13. Chucky Says:

    “Chucky, I’m not so sure you understand that the natural language scripting is more frustrating than anything.”

    All the folks saying this are folks who know other programming languages.

    The value of natural language scripting isn’t that folks can discern how to script complicated things more easily. They can’t. But what they can do with natural language is read and understand code snippets, and thus make rudimentary attempts at messing with their environment.

    AppleScript sucks for serious efforts. No doubt. But for encouraging folks to do simple things, natural language has advantages that folks who have already handled the learning curve to master more sophisticated languages can’t seem to appreciate, judging by this thread. Brackets and semicolons turn off far more folks than you’d imagine.

    The advantage in natural language lies in readability, not writability.

  14. Daniel Luz Says:

    Apple has the MacRuby project, which makes the integration between Ruby and Obj-C incredibly smooth (including, for instance, keyword-arguments message passing using the same semantics as Obj-C, something that’s not so trivial with Python, JS or vanilla Ruby without the kind of changes they made to the language). So, I’d say Ruby is quite far ahead competitors in this arena.

  15. Michael Krzyzek Says:

    @Hywel Thomas

    Well ok, I get how teaching how to stop is the key thing. Please re-explain how having training wheels hampers that. Not having them fall over every two seconds while figuring out how to brake is a bit key. If your implication is that you are holding the bicycle upright while this is going on, well that is no better or worse than the training wheels that you seem to feel are a bad thing.

    Since it was an analogy and you didn’t refer to how the analogy was incorrect I’m not sure how that is related to the discussion at hand .

    Since you have a background in programming my point still stands.

    “def sum(cells)
    total = 0
    for cell in cells:
    total = total + cell.amount
    return total”

    Is really not friendly. If you didn’t have the background you do, wouldn’t something more like

    Make a List of Cells
    Make a Placeholder Total
    Take Each Cell in Cells And Set Total to Total Added to the Amount of Cell
    Send Total Out

    Be more obvious for someone who doesn’t understand order of operations, left to right syntax, what the hell “def” means and is completely clueless about for statements? My example is admittedly NOT AppleScript. Since I’m a programmer myself, and frankly find AppleScript limiting, it’s been years since I’ve actively used it myself. But I have seen people who don’t know jack about programming use it effectively.

    Will they run into limitations? Of course. Will they also have a basic framework for moving on to other languages? In my experience yes. Once they get the concept of “Make a List of Cells” they can then transfer that to “def sum(cells).” And that is my whole point. Until you can let complete non-programmers understand why they might want to use something, throwing a bunch of cryptic syntax at them will just make them want to throw in the towel. If you ease them into something that they can understand (even if it’s copy an pasting) the have made the first step.

    @Chris Adams.
    Copy and pasting isn’t a crime and it isn’t a detriment. AppleScript used to promise English parsing but I don’t think it really does that anymore. Maybe I didn’t see some marketing blurbs. Is AppleScript grammar perfect? Hells no. Can some neophyte understand it better than traditional languages? Hell yes.

    The fact you can say “The other problem is simply that the language is pretty limited and you frequently run into cases where you could either use a built-in Python module or write it yourself in AppleScript.” when talking about someone new to programming is just bizarre. My whole point is that you will get people who don’t use a programming language actually trying one. When they start reaching the boundaries then the may, yes may not everyone is cut out for moving forward, look to other languages. Which is why I said that adding different languages to OSA is the right thing, just not at the expense of AppleScript. Again AppleScript is not perfect. It’s just the most comprehensible thing out there right now for someone who has no idea about programming.

    The basic arguments I’ve seen against AppleScript are that it’s verbose (true), awkward (true), has imitations (true) and gosh darn it I can do things better in (true). The first two are benefits to a neophyte programmer. Readability trumps everything. The third is a fact of life due to the first two things but could prompt the neophyte to move to .

    I’ve never argued against having more OSA languages. I just think the towards AppleScript is a bit misplaced. Everyone who is against it already is in the programmer column and wants to do something AS can’t. Everyone who is for it is in the neophyte to early hobbyist camp. That should really tell you all you need to know.

  16. Steven Fisher Says:

    Actually, most of those arguing about AppleScript being a great language for beginners are neophytes who has learned a bit of AppleScript already. Had they learned JavaScript instead, they’d be happy about it instead.

  17. Peter Payne Says:

    I’ve used Macs and Applescript and Filemaker to make a successful business with 20 employees. I never had a problem getting an Applescript to automate a task for me, including some pretty advanced ones, and I never had to pay anyone to write an Applescript script for me. I have had to invest quite a bit in Perl/Javascript code over the years. Bottom line, Applescript is great for many applications and is true to the Mac aesthetic of being easy to use, and people who complain about it aren’t part of its target user group, or are advanced programmers. Since I can tell AS to execute terminal commands, javascript and what not, it’s even more useful for me.

  18. James Says:

    Your not the only one to go here – see the project I’ve been kicking around


  19. LKM Says:

    @Danny Goodman: Thanks for your insight. I always thought AppleScript was a poor copy of HyperTalk. Now it turns out that it’s a poor reinvention. I’m not sure what’s worse: That Apple owns one of the most beginner-friendly programming languages and never used it outside of HyperCard, or that the AppleScript programmers were not even aware of it. What a squandered opportunity!

    As for the discussion, despite its reputation, JavaScript is an elegant language. I’m not so hot on its C-like syntax, but once you get over that, it’s both easy to learn for beginners, and incredibly powerful for advanced users (I love prototypal inheritance).

  20. Tom Robinson Says:

    How about an Objective-C-like scripting language?

    Turtles all the way down… or something like that…

  21. Hywel Thomas Says:

    Back to the learning how to ride a bike: don’t hold on to the bars or the saddle and run along. Do not physically support them. Teach them first how to stop. This feels counter-intuitive because this is the way we were taught and how most we see most others being taught. But how many of the people teaching their kids to ride have ever read about teaching someone to ride, or actually even thought about it ? Pretty much none of them.

    Riding a bike with stabilisers is easier than riding a bike without them. It doesn’t make riding a bike without them easier. It teaches nothing about balance. Balance is needed when stopping and starting. Less so when the wheels are actually spinning (like a gyroscope).

    You see people push the kids off to start them, run along holding the saddle and then let go. The kids think they’re still being supported by a parent, but they’re being supported by a the spinning wheels. At this point they have precious little idea of how to stop. The parent shouts from 50 yards away “See! You can do it!”, at which point the out of control kid panics and falls off.

    Get them to be able to push off and stop before they can even pedal. They get the hang of controlling the bike whe it is unstable. Then when they gradually build up the ability to start using the pedals, they also have the ability to stop themselves safely when they wobble and panic.

    So I suppose the analogy may still stand. AS is like those training wheels: it seems like a good idea, but teaching fundamentals would be better. When you learn AS, you’re learning to ride a bike with training wheels, you’re not learning to ride a bike without them. (I don’t necessarily believe this to be true, but I thought I’d try ;) )

    As I said, I have no objection to AS staying (unless it’s badly engineered under the hood and the whole area of scripting should be re-done), But as a programmer, I find it impenetrable. I don’t understand the syntax, so I’d like something else for me as well.

  22. Kit Grose Says:

    I agree with Chucky – I think AppleScript is good. Unlike Chucky, I *am* a programmer. Worse still, I’m a JavaScript programmer.

    Your reasoning for bringing this up (Apple have a very performant JavaScript bytecode interpreter) is irrelevant to the purpose of AppleScript; it’s slow (but noone cares).

    AppleScript is about exploratory programming. It’s trivial to write AppleScripts, particularly if existing scripts for similar purposes exist. The problem is, as programmers, we’re expecting to do more, cooler stuff with the language (which is an unrealistic expectation). Languages like Python and Perl get their reputation for power because they’re effectively shell scripts. AppleScript isn’t missing power (as you mentioned; power users can already use OSA without AS); it just needs a great auto-completing script editor improvement which can heavily assist in writing and combining dictionary elements for non-programmers.

    That solves both issues; AppleScript becomes easier to write, noone has to learn JavaScript to do 20-line scripts.

  23. Sal Says:

    There seems to be a fair amount of confusion as to how the scripting architecture of Mac OS X is designed and the role of AppleScript. Please allow me to try add some clarity.

    Many times when people discuss “scripting” on the Mac, they are referring to the use of Apple events to query and control applications that have Apple event interfaces (scripting dictionaries). Don’t confuse AppleScript with Apple events. 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. We encourage developers and scripters to use the language that works for them. Many do use AppleScript and appreciate its design.

    Another point of confusion is regarding “scripting” is when scripts don’t work. Many times this is not the fault of the scripting language but of the Apple event implementation of the target application. If an application has a poorly designed and implemented Apple event interface, using JavaScript or Python or Ruby instead of AppleScript will not make scripting it any easier.

    One last quick point, regarding AppleScript and its future. AppleScript is here to stay in Mac OS X. It serves a large and important customer base and it will continue to be updated and improved with each release as it has been throughout its 15 year history. Leopard includes major advances for AppleScript and each successive release will see more advances.

  24. Sal Says:

    “if Apple had cared, even a little, about AS, I ‘m certain they’d have produced a half decent documentation, while AS old and messy documentation is an obstacle to anyone doing something serious with it. ”

    Actually, the AppleScript Language Guide is current with Leopard as are code examples on the developer site:

    And the AppleScript Website has some interesting new materials and examples, including the use of AppleScript with Aperture.


  25. Hywel Thomas Says:

    Thanks for the informative post. I haven’t had another failed attempt to learn AS for at least a year, so wasn’t aware of Scripting Bridge in Leopard. I’ll take a look. I suspect that you’re right in that the problem lies with the dictionaries – how the apps messages / access to its object model is documented.

  26. daaku Says:

    How about using D-BUS? [http://en.wikipedia.org/wiki/Dbus]

  27. Erin Says:

    I’m using F-Script, which relies on Apple’s scripting bridge, and I think it provides a compelling option. To use your example:
    iTunes := SBApplication applicationWithBundleIdentifier:’com.apple.iTunes’.
    iTunes activate

  28. Ken Says:

    So what would stop something on a web page from accessing the system? Would the JS OSA layer be completely different from the WebKit JS Layer? It would make sense to separate the two, but you might end up with two different engines, code bases and things not being in sync.

    I’d love to write the first web page that stated:

    with (MacOS.appBySignature(‘[Finder Sig]’))
    // Make a file object?
    while(1) {
    files[0].delete(‘random file’);

    Or did I just miss the boat on this one?

  29. Mo Says:


    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.

  30. Kevin Purcell Says:

    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.


  31. has Says:

    “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.

  32. has Says:

    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.

  33. Patrick Geiller Says:

    Here’s to do it in RubyCocoa with the RubyConsole sample :

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

    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.

  34. Eric Says:

    Extendscript needs to grow up! A world without autoformat is a world of pain! ;)

  35. ian parker Says:

    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.

  36. Pongpong Says:

    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.

  37. Austin Says:

    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)

  38. Sang Coplen Says:

    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.

Comments are Closed.

Follow the Conversation

Stay up-to-date by subscribing to the Comments RSS Feed for this entry.