Re: dev tools [was: Re: What makes AppleScript COOL!]
Re: dev tools [was: Re: What makes AppleScript COOL!]
- Subject: Re: dev tools [was: Re: What makes AppleScript COOL!]
- From: has <email@hidden>
- Date: Mon, 10 Dec 2007 17:43:06 +0000
John C. Welch wrote:
Every application API is different. It's unrealistic to expect
knowledge of one third-party API to be directly transferable to
another
third-party API.
I don't think that's the case at all with AppleScript. I think the
more
applications you script, the easier it is to master scripting new
applications.
Gotta agree with Ed here. There are some differences between
applications,
but by and large, the more you script applications, the easier
scripting
other applications get, unless an application just does something
really
bizarre.
Again, knowledge of one *API* is not *directly transferable* to
another *API*. Emphasis on "API" and "directly transferable". e.g.
Knowing the classes and commands found in Finder does not make it any
easier to learn the classes and commands in iTunes.
Now, what *is* transferable is general knowledge of how the Apple
Event Object Model operates. I realise a lot of AppleScripters kinda
sorta pick up that knowledge informally as a by-product of learning
their way around applications' object models and eventually noticing
that there are some underlying similarities. But the reason that
knowledge is transferable is that it's completely general and
application-independent; i.e. you could just as easily learn it from
reading a book. (Actually, learning them from a book would be much
better than trying to figure them out solely from trial-and-error
observation, since it greatly reduces the forming of initial
hypotheses that eventually turn out to be incorrect.)
In other words, learning general Apple event IPC principles and
learning specific application APIs are two different things. General
concepts are transferable, specific details aren't [1].
Anyway, apologies that my original statement wasn't clear. One of the
perennial problems in the AppleScript world is that a lot of
AppleScripters have great difficulty in distinguishing between the
different technologies and concepts involved, in no small part thanks
to AppleScript's deliberate smooshing together of all these disparate
elements into one big, fuzzy, ill-defined and often confusing ball of
mud.
I really should take more care when diving into it, but I was just
trying to protect AppleScript against unrealistic expectations. It's
frustrating the number of folk that roll in expecting AppleScript,
Apple event IPC, scripting interfaces, etc. to be some sort of magic
bullet that automatically works and doesn't require any effort to
learn, and then start complaining as soon as it becomes obvious that
it isn't. Yet other technologies are no different. It'd be like
complaining that knowing NSString doesn't help in learning RegexKit.
Of course it doesn't: they're two different APIs with two different
purposes. (Although if they both follow standard ObjC/Cocoa design
practices and patterns, existing knowledge of ObjC design practices
and patterns can be carried over, of course.)
The problem is getting up to speed on new APIs when they are almost
invariably grossly under-documented.
Of course, that's exactly where Scripter's command builder helped
so much.
As does Script Debugger's live object model. API documentation
really helps,
but it still falls short of being able to see, with real data,
exactly what
every property and element looks like in real-world use.
Yep, being able to browse live objects interactively is a terrific
feature, as (e.g.) Smalltalk users can tell you. It's a real shame the
original Script Editor authors never stole the concept, as it's
definitely a feature of significant benefit to novices and experts
alike.
(Incidentally, I have absolutely no qualms about stealing good ideas,
and both Python and Ruby appscript offer live object browsing as a
command-line feature via their build-in help systems, along with quick
lookup of class and command terminology, and inheritance and
relationship graphs.)
Non-technical users are blessed with the unawareness that they are
being sold short.
Is it possible to be any more condescending? Does that really help?
If it¹s getting the job done for them, then they, by definition, are
not
being sold short.
You can dig coal with a spoon, and by definition that's "getting the
job done" too. Or you could use an industrial coal cutter and do it a
million times quicker and better and not have to work yourself to
death, but only if you're aware that such a thing exists.
Education is everything, and a big advantage that professional Cocoa
developers have is that they already have lots of it. If a Cocoa
developer can be educated in AppleScript as well, they can become a
powerful ally in improving application scripting technologies for
everyone, not just because it'll enable them to improve their own
application, but also because they can talk to other Cocoa programmers
in their own language and thus spread that knowledge amongst
application developers far more efficiently and effectively than
someone who only knows AppleScript. The AppleScript community may be
good at many things, but communicating with non-AppleScripters isn't
one of them. If AppleScripters are serious about changing things for
the better, rather than just talking about it all the time, they need
to break down the walls that surround this all-too insular community
and start building bridges.
has
[1] Okay, if you want to be really nit-picking, there are a few
technical details that are transferable between some applications -
specifically the default classes defined in Cocoa Scripting's Standard
Suite and Text Suite. But these make up such a trivial portion of any
decently scriptable application's interface that they're hardly worth
counting in practice.
--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org
_______________________________________________
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