[Pythonmac-SIG] Applescript

[has]

Michael J. Barber wrote:

>Your description of AppleScript is not far off, I'd say, but 
>AppleScript is better than a lot of websites would have you believe. 
>The core language is semantically like Python, but dumber. IMO, it 
>is  most significantly marred by not having first-class functions or 
>decent  mapping objects.

Handlers are first-class objects; however this is not an officially 
supported behaviour and suffers from variable scoping problems that 
can introduce bugs in non-trivial use. Its lack of a native hash 
class is one of the many feature omissions that are, by modern 
standards, unacceptable for any high-level scripting language that 
wants to be taken seriously. Its lack of a built-in mechanism for 
managing and loading modules is another, and probably goes some way 
in explaining the dreadful dearth of decent libraries available for 
the language.

(Whereas some features, like its prototype-based OOP model and native 
support for persistent objects, are - with a few inevitable caveats - 
actually rather nice and could actually put quite a lot of others to 
shame if they weren't being dragged down by AppleScript's other 
faults.)


>The syntax can be awkward when writing scripts, but  does make 
>examples easy to read, at least.

Well-written AppleScript code is an absolute joy to read, and I 
personally prefer it over any other syntax I've yet encountered, 
including - in many respects - Python's own (which, despite its 
flaws, I've considerable admiration for).

But as you say it can be a royal PITA learning how to put code 
together yourself. Consider AppleScript the "anti-Perl" - the 
definitive example of a "read-only language". :)


>Most OSA examples are in  AppleScript, and Apple seems to like to 
>treat OSA and AppleScript like  they were synonyms.

Yes. Probably a Marketing habit. Downright annoying. IMO this 
unfortunate association has done far more harm than good over the 
years, considering that high-level, AppleEvent-based 
Inter-Application Communication should, by rights, be as central to 
the whole Mac OS concept as pipes are to Unix's. (Though considering 
the fate of much 90s Mac OS technology, it should probably consider 
itself lucky just to be still around.)

BTW, they also frequently conflate OSA (Open Scripting Architecture) 
with AEM (Apple Event Manager). (Something you just did here 
yourself, but as it's really their fault I'll let you off.;) Though 
I'm encouraged to see Chris Nebel actively attempting to clarify this 
issue over on the MACSCRPT list these last few days (The man deserves 
a solid pat on the back... followed by hearty cries of "Tell Us 
More!!":)



>[JavaScriptOSA]
>The documentation  is aimed at programmers, including some examples 
>of how to construct  and send raw AppleEvents. That could be a 
>useful starting point for  sending AppleEvents in Python.

Not really; working directly with AppleEvents is a right PITA to do 
in practice, which is why any self-respecting high-level language 
should plaster sufficient high-level APIs over it till it can no 
longer be seen. Bob's aeve module attempts to do this, as does my 
appscript, and Pudge's Mac::Glue. (There may be others, though I 
haven't heard about them.)

Coming up with a _really good_ IAC API is pretty hard, however; and 
maybe impossible if you've not grokked the whole application 
scripting concept 100%. Which is actually damned difficult to do... 
the whole lot is deeply shrouded in fog and mystery, and what 
explanation is available from Apple is often less than helpful in 
dispelling this. [1]

The first few early adopters who already know something of Mac IAC 
and are willing to brave some missing wiring and the odd hole in the 
wall are starting to appear now. But "just about usable" is still 
quite some way way from being ready for prime-time use, and until 
there's some decent documentation for it (tours, tutorials, examples 
of use, etc.) then I can't really recomment it for newcomers. All I 
can say is: 1. be patient; and: 2. it _will_ happen. :)


Regards,

has


[1] <puff>Now I've grokked IAC, AEM, et-al for myself, I'm absolutely 
confident of developing just such an API at some point this 
year.</puff> It's just a matter of spending the time and effort to 
get it  right. Once it's done, I'll publish the spec as a reference 
for others planning to develop IAC support in other languages.
-- 
http://freespace.virgin.net/hamish.sanderson/