Re: WWDC and AS
Re: WWDC and AS
- Subject: Re: WWDC and AS
- From: has <email@hidden>
- Date: Thu, 1 Apr 2004 20:39:40 +0100
Don Briggs wrote:
Automated Testing Using AppleScript
"Using practical examples, this session will teach you how adding
an AppleScript interface to your application can provide an
efficient and powerful way to create thorough automated
testing.[...]"
Uh-oh...
As acting temporary devil's advocate, I gotta say this sounds very
_wrong_. [...]
I see the WWDC session, "Automated Testing Using AppleScript," as a
hopeful sign.
I see it as another indication of Apple's commitment to AppleScript
and, I infer, to AppleScriptability for Cocoa.
Don't get me wrong: I'm absolutely for Apple promoting its
application scripting technologies [1]. But this particular exercise
sounds like a dodgy attempt to sell developers a hammer for a task
where they should be using screwdrivers. Just because users happen to
like nails doesn't make it right. And once the developer discovers
their screws are all pounded in wrong, who are they most likely to
blame?
In the WWDC AppleScriptability sessions of recent years, developers
have been encouraged to design new apps with AppleScriptability in
mind.
As they should. The classic problem with selling developers on
scriptability is they often don't see the point of something that
doesn't benefit them directly. As a developer, one of the best ways
to judge the value of something is to use it yourself - aka "eating
your own dogfood". You can easily tell which APIs, application
scripting interfaces, etc. have never actually been used by their own
developers: they're the ones that blow the most. So getting
developers to implement, use and refine their own scripting
interfaces is a Good Thing. But trying to sell developers on
scripting support by fabricating a "concrete" use for it is most
definitely not, which is what the ATUA session sounds suspiciously
like to me. (Hey, I'm a natural worrier.;)
In that context, automated testing using AppleScript makes very good sense.
I have, in fact, used it that way.
AppleScript, after all, speaks to the "Model" (the business layer).
No, it doesn't. The AppleScript language runtime speaks to the Apple
Event Manager, which speaks to the Mach messaging layer, which speaks
to the application runtime, which speaks to the Cocoa Scripting
layer, which hooks into the application's Model layer. That's a lot
of extra junk your tests have to go through. And that's even before
you write your actual test code, and for that AppleScript is about
the last language you'd ever want to use for this: 1. it's seriously
underpowered; 2. it's buggy as anthills; and 3. there's essentially
no existing infrastructure for developing test code [2], so
developers will have to roll everything they need from scratch.
I presume that this WWDC session would not have been scheduled if
Apple had not found success in this technique internally.
Given Apple still hasn't gotten its act together supporting decent
scripting interfaces in its own applications, I hope you'll forgive
my scepticism at such an assumption. :p
As for improving "developer street cred," I would judge that one
intent is improve the credibility of serious AppleScriptability.
In a recent exchange in this list, "Jeff Handy" <email@hidden> wrote:
3 - Sal has been sending subliminal messages over the web in those X.10
camera popups
and John C. Welch quipped:
We need to send subliminals to the Professional Applications Group ;-)
Look, if the technology is good, you don't need subliminal selling.
Just be honest and it'll sell itself. If it's crap, all the sneaky
marketing tricks in the world won't change that, but _will_ honk off
the folk you're trying to flog it to. Now, the AppleScript language
is crap [3], as anyone that knows anything about software engineering
can tell. The underlying interapplication communication technology -
Apple Event Manager, Cocoa Scripting - is generally pretty sound,
however. Okay, so AEM is excessively baroque and not much fun to use
(but it's becoming less relevant as Cocoa Scripting takes over), and
there's still some roughness in Cocoa Scripting, but that'll no doubt
be ironed out in time. And the scripting support (OSA) is solid in
concept; even if some of the implementation blows, and the few new
developments we have seen to date are frustratingly Non-Open (yes,
NSAppleScript, I'm looking at you), but nothing that isn't fixable.
If Apple seriously wants to get developers to _use_ application
scripting, they should present it to them in a form developers can
actually work with. That means cleaning up their existing APIs and
documentation, and ensuring first-rate application scripting support
is present in developer-friendly languages like Perl, Python, Java
and Unix shells [4]. Put solid Apple event-based scripting interfaces
and attachability into XCode, IB and other development tools. Break
the fingers of any remaining vi holdouts, and take away their shells
so they can't use *nix pipes for a week. Do this, and you won't be
able to keep the blighters away from it!
...
Sorry if that's turned into a rant, and be assured it wasn't directed
at you (or anyone else) in particular. (Did feel good tho'.;) I'm
still no more convinced my original assertion is false at this point,
but further input is certainly welcome.
Best,
has
[1] Note I say "Application Scripting", not "AppleScript". It's an
important distinction that's all too often blurred to the detriment
of both. (Not least by Apple itself.:p)
[2] Well, ok, I've written a basic unit testing framework for
AppleScript, plus a complete module binding system and 30+ other
modules. But none of that stuff is anything like mature enough for
this kind of use; heck, it's not even publically available yet (the
guilty parties there know who they are;). (Also, consider also that
I've chucked in AS-based development and moved to Python: I wouldn't
have walked away from all that investment if I thought the AS
language was a credible platform for even semi-serious programming.)
[3] And I say that as someone with great appreciation for all AS's
bold intentions, smart ideas, and cutting-edge features. It's still
crap. Flawed design; hoary, shallow, unexpandable - unfinished! -
implementation, dreadful lack of surrounding infrastructure, low
bit-literacy rate amongst users... the list goes on.
[4] I'm sure the handful of bold souls currently working to remedy
this themselves would be absolutely delighted to see Apple engineers
throw their weight and expert knowledge behind it. (e.g. Did I
mention my own MacPython/AEM bridge is needing of a thorough expert
code review...? </hint>;)
--
http://freespace.virgin.net/hamish.sanderson/
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.