The problem with scriptable apps [was: Re: Informal Poll]
The problem with scriptable apps [was: Re: Informal Poll]
- Subject: The problem with scriptable apps [was: Re: Informal Poll]
- From: has <email@hidden>
- Date: Mon, 16 Jun 2014 22:05:19 +0100
Chris Paveglio wrote:
> My magical Applescript request would be sort of broad: To be able to
add Applescriptability to Cocoa apps in a much easier fashion, i.e.
Built into Xcode with GUI tools. I've done it once (added AS to my Cocoa
app) with SDEF editor and boy that process is byzantine!
I already said this in another post, but it bears repeating: I believe
the fundamental problem that scriptable application developers and users
have is that the AppleScript engineers never actually eat their own
dogfood - i.e. they never use their CocoaScripting, ScriptingBridge,
etc. frameworks for any sort of real-world work themselves. If they did,
they might start to realize how much most of it sucks. Not that there's
anything wrong with writing bad code in itself: we all do it, and doing
it quickly and frequently is often the best way to learn. "Write one to
throw away", as Fred Brooks says. But programmers who churn out bad
software without ever experiencing the pain of using it themselves are
much less likely ever to realize/admit there's a problem, never mind
know or care how to fix it.
I suspect there may be another problem in that the current AppleScript
engineers have a rather shallow and/or flawed understanding of how the
Apple Event Object Model is supposed to work. Their APIs and
documentation suggest that like a lot of mainstream programmers nowadays
they're stuck in a rigidly Object-Oriented mindset, which causes no end
of confusion and problems when applied to Apple events' RPC+relational
query model. I might be wrong, of course, but actually getting them to
talk about their thinking and motivation is rather difficult, and I've
pretty much given up hope of them ever straightening things out.
As far as making Cocoa applications scriptable, if third-party
developers don't like Cocoa Scripting (which is entirely understandable
as it is pretty crappy), they can and should develop their own
alternative AEOM framework, ideally as an open-source project. Whether
they should attempt a true relational query engine or just a dumbed down
OO-style DOM is something they'd have to decide for themselves. While
the former is more elegant and powerful, the latter is much simpler to
implement and OO developers will find its idioms more familiar, so
there's pros and cons to weigh. Either way, a community project means
control is in the hands of the people who actually use it every day -
i.e. app developers and app scripters. So if they don't like the way
it's working they can figure it out and fix it themselves; something we
just can't do when it's Apple's frameworks that are causing the problems.
Ray Robertson wrote:
> Given the lack of awareness and support, I wish there were some
almost-open-source way for members of the community to help add AS
support for needed apps. How many of us would be willing to spend some
time developing AS support for Preview? Yes, I know there are security
issues, other technical challenges and have no idea how it could be done
without developers giving some an inside look at their apps. Just dreaming.
See above. Forget about Apple's own frameworks and apps: if they're
busted, they're busted. Only Apple can choose to change that. However,
this doesn't prevent third-parties creating and sharing their own
superior alternative to Cocoa Scripting. Lowering the barrier to entry
for application developers who wish to add scriptability would be one
way to improve things. Another would be to actually explain to
programmers how application scripting actually works (something Apple
has completely failed to do), as it's almost universally misunderstood.
The other thing would be to turn app developers into enthusiastic app
scripters themselves. Developers do not work for free: they do it for
love and/or money, so if you can make them love using the technology
then they're far more likely to add it themselves. And application
automation is just the sort of fantasically powerful, geek-friendly
technology that professional programmers ought to be falling over
themselves to use. Honestly, it should sell itself. Unfortunately, this
is something Apple have totally screwed up over the years[1], and while
JS4A is obviously a fresh attempt to put that damage right I am
extremely leery, as so far it appears to be more of the same brokenness
that caused 10.5's ObjC-Apple event bridge to fall flat.
One more thought: it's also possible that once JS4A is released, app
developers will ignore all the pain of adding Apple event support and
simply publish their apps' raw Cocoa APIs, which JS4A can talk to
directly via its JS-ObjC bridge. Gus Mueller tried to do this with his
third-party JSTalk project a few years back, but it never found
sufficient traction to take off on its own. OTOH, JS4A has a huge
starting advantage of being a standard part of the OS itself.
Controlling apps this way would be much cruder, brittler, and
inconsistent, but there are a lot of developers out there who simply
don't have the time, resources, or near-inhuman patience it takes to
build good Apple event support into their apps, so might well be tempted
to go that easy route instead.[2]
Anyway, we'll see.
HTH
has
[1] In screwing up their own Scripting Bridge design, they also
effectively undid the independent work myself and others (especially
Matt Neuburg) had been doing in bridging the AppleScript and
Python/Ruby/ObjC worlds via appscript. (Which, unlike SB, _was_ good
enough to be a true alternative to AS.) But with appscript dead in the
water and SB simply not good enough for us to switch to, never mind
encourage others to us, there was nothing left for us to evangelize, so
we pretty much gave up. So not only was it bad technology, it was also
_terrible_ community building. And just at a time when getting thousands
of new Python/Ruby/ObjC/etc programmers to absolutely love application
automation could've provided a huge boost to the AppleScript ecosystem.
[2] FWIW, I'll give JS4A a shakedown when the public beta drops (it's
already available to paid developers, but I don't see much point giving
Apple $99 just to tell them "I told you so"). But if its Apple event
support is bad, I may give some thought as to whether it'd be better for
application developers to give up on AEs and go the JS-ObjC approach
instead. I know Dr William Cook (AppleScript's dad) has done some more
recent work in this field, using a simplified dialect of JS which can be
sent to another application to be safely executed there, which might be
a good avenue to pursue.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden