For example, SB likes to dress up the ‘make’ event as Cocoa-style object instantiation – i.e. alloc+init, and add to a collection – but if you try using -[SBElementArray addObject:] with iTunes, it barfs because -addObject: makes certain assumptions about how the ‘make’ event’s parameters should be formed, which are correct for Cocoa Scripting-based apps but often wrong for Carbon ones.

FWIW, early versions of appscript also tried to impose heavier OO-like abstractions on Apple events, so I learned that lesson the hard way. Unlike SB, I had the luxury of being able to rewrite appscript into its current form, which is about as thin an abstraction as it can be without being unpleasant.

If AE behaviours had been rigorously specced and enforced from the get-go, today’s scriptable apps might not be so lamentably inconsistent in how they implement their APIs, and creating robust, reusable high-level abstractions over those APIs might then be relatively straightforward. But I really doubt anyone could abstract over the current mess without the resulting abstractions regularly springing leaks on unsuspecting users.

That being said, it is perfectly possible that, given the current state or even the whole approach of the Apple’s Scripting Bridge, appscript is a better Apple Event bridge. I’d love to see it support F-Script.

I love to see that too. FWIW, the Appscript framework’s AEM layer is deliberately language-agnostic, allowing other Cocoa-speaking languages to apply their own choice of high-level syntactic sugar on top – e.g. objc-appscript uses a static glue generator, while macruby-appscript (in svn) uses rb-appscript’s #method_missing approach. Unfortunately, I don’t have the time to do any more appscript ports for now (I can’t even keep up on the existing ones), but if you or anyone else wants to give it a go I’m always happy to provide whatever advice I can.

There are also arguments for using the highest-order abstraction that will accomplish what you need; in this case, as Philippe points out, array programming allows for optimizations that would be more explicit otherwise, like building a query to be sent to a database. (This isn’t impossible with closures in the presence of, say, sufficient syntax tree introspection; Ambition is one example of doing this with closures: http://ambition.rubyforge.org/ )

On the whole, I would definitely agree that HOM doesn’t replace closures any more than closures replace blocks. It’s fascinating to see what’s possible these days (:

I’m not sure I understand why the argument for HOM is an argument against closures.

Sequence comprehensions are only a small part of the usefulness of closures, and indeed, there’s no reason that you can’t apply syntactic sugaring to make them as clean as your examples above. Translating the final example to Scala:

for (song = 256) yield song.name

OR

songs filter (_.bitRate >= 256) map (_.name)

Are either worse than F-Script’s syntax?

songs name where: songs bitRate >= 256

I’d argue no, and moreover, the use of closures permits the use of multi-statement expressions.

By expressing code at a relatively high level, array programming excels at providing under the hood, transparent speed optimizations. This is a well studied property of array languages. There is nothing in array programming that requires actually sending one event per track. On the contrary, because the intent of the code is expressed in terms of manipulations of whole collections, the array programming system can apply very efficient optimizations.

For example, in this particular situation related to generating Apple Events, F-Script can automatically translate the expression songs name into the following Objective-C code: [songs arrayByApplyingSelector:@selector(name)]. This code will lead to just one round trip between F-Script and iTunes. The same applies for the other messages such as songs bitRate. This is just one possible approach, other optimizations (e.g., generating the equivalent of the AppleScript code you showed) are possible.

This optimization is not active by default, but you can activate it by recompiling F-Script after uncommenting the code related to SBElementArray in FSExecEngine.m and see that the queries get executed ultra quickly. The reason this is not on by default is a bug in the Scripting Bridge (it won’t be news for you that some parts of it are half broken!). But regardless, the important point here is that from a programming model perspective, array programming does not leads to inefficient execution but is on the contrary an enabler for optimizations impossible or hard to do in classic “one object at a time” models. You can find more about this in the OOPAL paper referenced in the blog post.

That being said, it is perfectly possible that, given the current state or even the whole approach of the Apple’s Scripting Bridge, appscript is a better Apple Event bridge. I’d love to see it support F-Script.