dev tools [was: Re: What makes AppleScript COOL!]
dev tools [was: Re: What makes AppleScript COOL!]
- Subject: dev tools [was: Re: What makes AppleScript COOL!]
- From: has <email@hidden>
- Date: Sat, 8 Dec 2007 16:54:36 +0000
Phil wrote:
What I do miss is Scripter's Command Builder, which would allow you
to build
working commands by pointing and clicking at command components
pulled from
the application's dictionary.
It also provided a better way of looking at dictionaries.
I wasn't familiar with SCB but that sounds like that approach would
also address the problem which is essentially this: figuring out how
to tell AppleScript what you want it to do. (I actually spend less
time telling other scripting languages *how* to do things, which are
usually low-level enough that you can't simply tell them what to do,
than I spend telling AppleScript *what* I want it to do. Seems
counterintuitive.)
For complete beginners, yes, an interactive command builder would be
useful. (Although what non-programmers _really_ need is a full
structure editor/language; something like a 'grown-up' version of
MIT's Scratch.) For anyone with a modicum of programming skills a GUI-
based command builder provides no practical benefits (and is slower
than straight keyboard input), since things like interactive
dictionary browsers and command builders don't provide you with any
additional information beyond what is supplied by the application's
dictionary. And that brings us back to the immediate basic problem
with Apple event IPC: almost all scriptable applications provide
grossly inadequate and incomplete API documentation. (Imagine the
Cocoa documentation with the reference sections reduced to single-
sentence descriptions of classes and methods, and the tasks and
techniques missing completely.
Interactive dictionary and object model browsers are more generally
useful, since they make it quicker and easier to look up specific
information as you work - something that both novice and experienced
users make good use of. Script Debugger has very nice GUI-based
dictionary browsing and object introspection tools, and appscript
provides CLI-based equivalents with similar capabilities. But again,
while these sorts of tools are useful, they still aren't the sort of
silver bullet you're looking for - again, the only thing that will
make a serious difference is vastly better machine- and/or human-
readable API documentation from application developers.
Also, compare and contrast the default AppleScript tools with what
you get for Obj-C/ Cocoa development. Imagine that Apple only
provided an 'Objective-C Editor' with the relative capability of
Script Editor, didn't have Cocoa, provided 8 year old documentation
for the language, and required 3rd party tools and add-ins to get
anything meaningful done.... who would be doing any serious
development in/with/for Objective-C? (memo to Steve Jobs: Apple has
15 billion in the bank. Spend a few million to buy or build
something like ScriptDebugger and integrate it with OS X! ;-)
Script Debugger is in many respects complete overkill for novice and
lightweight AppleScript users, and its relative complexity would
probably scare away many newcomers who are tempted to AppleScript by
its perceived 'simplicity'. There is a strong argument for a 'beginner-
oriented' AppleScript editor like Script Editor to provide some
sophisticated, novice-friendly features such as SD-style interactive
dictionary and object model browsing, but aside from some minor (and
not entirely reliable) improvements that appeared in SE 2.0 I'm not
holding my breath.
That's really the point of the items I listed: universally useful
things should be provided by Apple out of the box.
To be honest, I've a lot more confidence in third-parties like LNS to
provide quality solutions that cater specifically to the novice and/or
professional markets than I do in Apple. For Apple, AppleScript tools
are merely a necessary adjunct to everything else they do. OTOH, for
LNS, AppleScript tools are its core business - and having one's
paychecks being 100% directly dependent on delivering top-quality
product can really help focus the mind.
After all, the odds of some new 3rd party attempting to enter the OS
X workflow automation space is highly unlikely and a brittle,
incomplete toolset only hurts Apple's customers, and in turn, Apple.
Huh? Third parties entering this space actually isn't all that
uncommon. e.g. Mark Aldritt is currently working on a major (and very
impressive sounding) new version of FaceSpan; I've delivered new Ruby
and ObjC versions of appscript in the last year and hope to provide a
Java version in 2008; and I know of at least one significant new book
on Mac automation that's about to get underway.
If anything, the problem is getting users to adopt new technologies,
either because they cost money (but think of it as investing in a
better future) or because they don't already have an established user
community (but somebody has to go first in order to lay the road for
everyone else).
I'm a little frustrated right now as I've spent the last several
hours working on getting a piddly little AppleScript to automate a
workflow between Safari and OmniOutliner. It's mostly working now
but in addition to taking several hours to automate 30 seconds worth
of work, I had to open a ticket with Omni (you guys rock: question
answered nearly immediately), had to use Script Debugger, have to
reinstall QuickSilver so I can assign a keyboard shortcut to it
(Quicksilver isn't at all bad but only needing it to assign a
keyboard shortcut to an AppleScript really bites), and still have a
rather mysterious issue with AppleScript (see my post re:
AppleScript and Spaces) I keep telling myself that this exercise was
worth it since I perform this workflow repeatedly but I don't dare
do the math on the time investment...
How long did it take you to get competent in Cocoa development? All
technologies have a learning curve. Just because Apple's marketing
likes to pretend that AppleScript is 'easy' doesn't make it true
(lies, damned lies, etc). If you want that learning curve eased, start
by demanding vastly better API documentation from your scriptable
application vendors. The more folk that do that, the more likely it is
to happen.
I'd probably have to do keep doing it for the next 50 years to break
even.
More like three or four. Again, demand better API documentation if you
want this reduced further.
(I'm not naive enough to think that this time investment will pay
off in future AppleScript development... AppleScript is the only
language I've ever used where your previous efforts / knowledge
gained don't count the next time you try to do something different.)
I am an Obj-C/Cocoa developer, among other tools and languages, and
continue to be amazed at how painful AppleScripting is...
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. The problem is getting up to speed on new
APIs when they are almost invariably grossly under-documented.
I pity the non-technical user.
Non-technical users are blessed with the unawareness that they are
being sold short. You, on the other hand, have plenty of experience in
using other technologies against which to compare it. That puts you in
a strong position to critique it in terms that scriptable application
vendors can understand and appreciate, just as soon as you've got the
general principles of application scripting down pat.
My advice to existing ObjC/Cocoa developers wishing to get up to speed
on application scripting principles: go read Matt's book if you
haven't already done so; I'd also recommend reading the two PDF papers
written by the original AppleScript designers which you'll find on the
appscript site's links page (see my sig). While you're at it, you may
also want to check out appscript itself, which lets you control
scriptable applications while at least avoiding the many vagaries and
obfuscations of the AppleScript langage. (Leopard also provides its
own Scripting Bridge, BTW, but that just adds a whole new layer of
vagaries and obfuscations over everything, so isn't really a good
place to start if you want to understand what's actually going on.)
Then, once you understand the concepts involved, go bug all the other
ObjC/Cocoa developers to do the same, and then ride them until they
start providing much better scripting API documentation for all their
products.
HTH
has
--
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