Re: Nice Automator article on O'Reilly
Re: Nice Automator article on O'Reilly
- Subject: Re: Nice Automator article on O'Reilly
- From: Martin Orpen <email@hidden>
- Date: Fri, 06 May 2005 01:19:33 +0100
on 5/5/05 18:59, Christopher Nebel at email@hidden wrote:
> On May 4, 2005, at 4:56 PM, Martin Orpen wrote:
[snip]
>> [S]omebody at Apple has come up with a brilliant idea of re-
>> launching the humble Apple event and a simple way of using it in
>> the form of Automator. I think that [Automator] is as good an idea
>> as AppleScript was, but I personally don't find it half as
>> appealing. An AppleScript dictionary is so much more *interesting*
>> to look at than a fixed Automator Action. ... AppleScript meant
>> linking apps together in ways that people didn't envisage when they
>> wrote the dictionary. Automator *may* mean linking apps together in
>> ways that other people have already placed limitations on.
>
> Aha. This is an interesting point, and it's one that a coworker of
> mine is fond of raising. I think of the problem in terms of
> granularity: Automator actions are "bigger" than AppleScript
> objects. This cuts both ways.
>
> Think of it in terms of Legos -- you've got regular bricks
> (AppleScript) and the triple-size Duplo bricks (Automator). If you
> want to extend the analogy, you might think of C/Obj-C as lots of the
> little flat bricks. If what you need is a tower a foot tall, then
> Duplos will get the job done faster. If, on the other hand, you need
> a sphere, then the regular bricks will make a more precise sphere --
> they're more flexible and detailed in what they can build. Both have
> their advantages, so ideally you have both, and can even mix them.
I've snipped (for brevity) the bit about the graphical nature of a scripting
interface - but I find it very interesting. Especially as I'd like to push
the point of *linking apps together in ways that people didn't envisage*.
(As an aside, I was reminded of this today by a very simple request: how can
you discover the size of the trash? If we had to rely on the Finder we are
screwed because the writers of the app have provided us with nothing more
than missing values. AS gives us the ability to calculate the result using a
fairly simple workaround. Shell tools like du can give us an instant result.
But the important thing is that we have the option to choose different
methods to get the information.)
Speaking personally, the main attraction of AS is that there are numerous
ways to approach a task and those that are the most fun (to me anyhow) are
those that are either unbelievably concise, novel, undocumented, hacked or
whacked.
Frankly, AS in OS 9 (and OS 9 itself) was getting pretty stale. OS X, the
freedom to incorporate shell stuff and the ability to push projects to Xcode
has certainly rekindled my interest :)
It would seem to me that when you've got an object that is massively complex
(like a modern OS) you need a minimal set of rules that can be utilised to
get things done. If that minimal set of rules included a useful AppleScript
dictionary then I'd be really chuffed - but that doesn't seem to be the way
things are going.
Automator offers a simplistic method - but you are totally dependent on
other people having *envisaged* what you wanted to achieve. This is
crushingly dull, and just launching the app depresses me.
To lessen the depression I sniff around the unscriptable apps using F-Script
Anywhere's browser and find a simpler (yet more powerful) set of rules
hidden from casual view in the obj-c classes and methods.
Then I launch Quartz Composer and the depression completely disappears. That
is more what my idea of a starting point for a graphical scripting interface
should look like!
Simplicity, functionality and an option to create something incredibly
complex.
--
Martin Orpen
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden