[MacPerl] Re: general AppleScript Rant

[Jonathan Eunice <develop@illuminata.com>]

Jefferson R. Lowrey (lowrey@postoffice.sells.com) wrote:

>>And how!  Let me rant the ways:
>At least you admit it's a rant. ;-)

Yes, it is...and to each his own.  If it works for you, more power to
you!

>>1. In trying to be like a natural language, it's got innumerable
>>   ways of stating every little thing.  Which variants are usable at a
>>   given time varies considerably.
>
>Which can be annoying.  Perhaps as annoying as a full beastiary of special
>variables, only some of which are useable at any given time.  And, what
>exactly is wrong with "There's more than one way to do it"?

Sure, Perl's got its many nitsy annoyances and arcane backstroke
squiggle pound variables.  I'm no great fan of them either. But I
am put off by things like

    set myVar to 16            -- works

    set monitor depth to 16 -- doesn't work

    set monitor depth 16     -- works (the "to" above was wrong)

AppleScript's attept to provide pleasant, conversational syntax is nice,
the inconsistencies aren't.


>>2. It is a language for talking to applications, yet it encouages
>>   app developers to provide an "object model" above and beyond,
>>   and thus often quite different from, the one that most users
>>   experience through the standard GUI interface.  The AS interface
>>   is thus often absent, buggy or incomplete when provided, and
>>   almost never supported.
>
>"Almost never supported" is no longer true, nor has it been for about two
>years.  Most serious applications being released for the macintosh have at
>least *some* applescripting capabilities built in.

Perhaps you've had better experiences, or use a different set of apps.
In my world, "almost never supported" remains true.  I've tried to do 
relatively simple things in Adobe Acrobat Exchange, FrameMaker, and
other major publishing tools here, only to be quite frustrated.  When
AS is supported, as in FM, it is hugely buggy and woefully incomplete.


>>3. Though "driving" the user interface as a normal user would do
>>   would be the easiest and most direct way to handle many scripting
>>   tasks, AS has no mechanism whatsoever for doing this.
>>   There is an (invaluable) third-party product, PreFab Player, that
>>   lets an Applescript programmer navigate as users do, but because
>>   it's an add-on rather thans something built into the OS, it only
>>   works some of the time.
>
>I disagree completely with qq{"driving" the user interface as a normal user
>would do would be the easiest and most direct way to handle many scripting
>tasks}.  It's not.  Having to say something like:
>    select document "MyDoc3"
>    do menu item "Print"
>
>or worse yet
>    move mouse to coordinates {x:50,y:15}
>    click mouse
>    move mouse to menu "File"
>    click mouse with holddown
>    move mouse to menu item "Print"
>    release mouse
>
>instead of
>    print document "MyDoc3"
>is bad.


I'd much rather 'print doucment "MyDoc3"', for sure.  That is the "right 
way to
do it."  But it is the wrong place to start. Had Apple build GUI 
navigation in
as a fundamental part of AS, EVERY SINGLE MAC APPLICATION would have
been scriptable from day one.  Not optimally scriptable, to be sure.  But 
at
least it would have been possible to control application behavior and 
offload
our users of repetitive tasks.  As it is, we're STILL doing many things 
by hand
in FrameMaker, Acrobat, etc. that should have been scriptable years ago.

Indeed, the combination of 'do menu item "Print" of menu "File"' not 
being 
an inbuilt part of AS and our important apps not providing reliable or
sufficient AS models, we're reduced to using your middle example (with
the PreFab Player extension), which is even harder and less reliable.
In several important situations, it just breaks.

In summary, I'd love to have the ideal that Apple was shooting for. But
I'd much rather have a pragmatic and immediately useful fraction of that
capability now, rather than wait, wait, wait for the ideal (which may 
never come).


>>4. <timing and synchronization problems Paul mentioned earlier>
>>
>>Apple could have saved itself and everyone else huge amounts of
>>time, money, and energy, and had a better product besides, had it
>>started by providing a regular, reliable system for navigating every
>>MacOS menu, dialog box, and control item.
>
>I'd much rather not have UI come up when automating an application.
>Anything I can specify with a UI I should be able to specify WITHOUT one
>(and ain't that a Unixish thought!).  Encouraging people to implement AS so
>that the UI gets "driven" would lead to exactly the kind of tortured coding
>I showed above.   Avoiding that kind of programming is exactly what the
>object model you complain about is trying to do, as well as STANDARDIZE
>behavior between applications of a similar natures (like virus checking
>software, or page layout programs (|dream here) ).


I agree.   I'd love pure access to application engines apart from their 
GUI
manifestations too.  But even under the current AS model, where apps 
provide objects, frequently they look and act as though they are being
"driven."  If my email-sending script is running, I'd damn well better not
be trying to drive Emailer myself as a user, because it will interfere 
with
the script (which makes natural assumptions about which document/window
is on top, say). 


> Now that we actually have TWO sides to this language war, let's get back 
> to the business of babbling about MacPerl, shall we?

Ok...but I don't think we got too far off-topic, because for many of us
AppleScript is a natual and necessary accessory for MacPerl programming.
And at least for me, understanding what I didn't like about AS or couldn't
easily do in AS increased my appreciation/understanding of the Perl model.

***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch