Finding peace with scripting languages [long]
Finding peace with scripting languages [long]
- Subject: Finding peace with scripting languages [long]
- From: Matt Deatherage <email@hidden>
- Date: Sun, 22 Jul 2007 00:32:26 -0500
On 7/22/07 at 11:09 PM, Mark J. Reed <email@hidden> wrote:
> The sentiment behind the rant remains, though: I do see all this talk
> about "pure" applescript as simple bigotry, on par with, and as silly
> as, concern over the "purity of our precious bodily fluids".
I don't want to know how you measure that.
I don't see it as "bigotry," though I'll grant it's "emotional." It's
somewhat akin to being told that the way to solve a certain software
problem on your Mac is to "install and use Windows." Why not? It's a
"perfectly good" solution that runs on your (Intel-based) Mac, there's
nothing "intrinsically better" about Mac OS X than Windows for a
specific top-level task (in most cases), and if you don't like it, you
don't have to use it.
Yet some might dare impugn it. :-)
This is *always* going to get emotional precisely because it is a
miniature version of the platform wars. Intentionally or not,
consciously or not, to *some* people, when they're told to use a
different scripting language inside an AppleScript script, they hear
"You picked the wrong language for your project, you ninny, and now
you're paying for it."
It's basically the same problem at the heart of the platform wars - for
some people, hearing that [Windows|Mac OS X] is superior means [Mac OS
X|Windows] is inferior, and that makes them feel stupid for choosing
[Mac OS X|Windows], so there's nothing left but to wage bloody war. It
gets into cognitive dissonance and all that fun stuff.
Nothing is the best tool for every job, but most tools are just fine for
most jobs. You can build a lot of things with a hammer and a saw, but
sometimes you need pliers, too. Yet this does not bother us because we
did not spend $2000 to buy the hammer, plus four hours to install it and
another two weeks learning how to use it most effectively. Despite
relative approachability, people spend effort to learn AppleScript, and
when the answer to their questions is "use another scripting language,"
it can evoke reactions that no one intended or expected.
Personally, I am a hopeless nerd, and I object to mixing languages for
all the wrong emotional reasons - it just feels wrong to me in most
cases. I don't like using "do shell script" in AppleScript any more
than I like inline assembly language in C/C++, or than I would like
having to use "osascript" inside a shell script.
I'm not opposed to using the best features of all my tools, but I prefer
to keep things separate. I make .a files and .c files and compile them
separately, and if I have more than a line or two of shell scripting, I
make a shell script and call it. (Or if I need a lot of AppleScript in
a shell script, I make a .scpt file and run it from the shell script.
Subroutines and external programs don't bother me; mixing languages
does. And I don't like tartar sauce on fish, either. It's my thing and
I live with it and it may not be your thing and it doesn't have to be.)
Beyond that, just from going way back to the days of 48K machines and
16K of usable RAM and not wasting resources or space (probably why
UTF-16 still feels "wrong", all those zero bytes just *sitting* there),
I don't like the idea of starting up an entirely new execution
environment inside a script for a line or two of code in another
environment. It feels wasteful to invoke an entire shell to perform
"ls," just like it feels wasteful to open, initialize, and close an OSA
script component for "display dialog." I prefer native solutions in the
language I've chosen to use unless they are impractical. If I have to
call an external progrma anyway, a shell script is just as good - I use
"curl" when necessary rather than send an Apple event to some FBA to
download a file via HTTP, but I'd prefer that to be part of Standard
Additions.
When we get to topics like the original question, my internal thoughts
tend towards efficiency and performance. "Hmm, I could do this in a
loop pretty easily, provided I know how many letters there are in the
alphabet, and that's going to be just fine unless I have to rebuild the
list 50-100 times per second. Then I might want the computer to spend
less time interpreting the script and more time finding the files. I
could whip up some File Manager code, or I could use a shell command if
it won't take too long to set up and tear down, or I could see if I can
get Finder to do it in a single Apple event."
It's just simple optimization to me, like the stuff most people on this
list learned ten years ago to use "whose" clauses to let the scriptable
applications do all the work instead of giving you a buttload of objects
that you have to test yourself. It's always faster to have Finder
return a list of "all files whose names begin with myVariable" than it
is to get "all files" and test the names yourself in a loop. The more
work done by compiled machine code, the faster it gets.
If it's too unwieldy to get there in "pure" AppleScript, I'll invoke
whatever external program I need, with a bias towards those that are
installed on all systems and easier to use and understand. (Over on the
Carbon-Dev list, there's been a thread about using "rm" from within a
program to remove files and how you have to be careful in calculating
parameters to avoid syntax nightmares - like if you try to delete a file
that way but the file's name happens to be "-rf *" and you didn't
anticipate that situation so you pass "rm -rf *" to the shell. Ouch.
This is the kind of trouble you bite off when you start trying to get
too clever with these things, thinking "rm" would be easier than telling
Finder to move it to the trash.)
But I don't expect *any* tool to perform every task I may need, unless I
want to write everything myself in C or assembly language. The
higher-level I go, the more I depend on tools working together to fill
in each other's gaps. That attitude took me a while to develop; when I
was a younger programmer, hitting a roadblock would often make me think
I just *had* to find a "native" way to do something to prove I hadn't
picked the wrong tool for the job.
Getting there made life a lot easier, though. Every now and then, a
friend or family member will approach me about "switching" to the Mac,
but the primary concern is usually that he be able to do everything on
his Mac *exactly* the same way it works under Windows - same interface,
same availability of obscure third-party vertical apps, same Windows
workhorses like ACT! or Access or extensive QuickBooks features, same
two-column file navigation, and so on. And I tell them that if they
want to do things the Mac normally does them but still need to keep a
toe in Windows, that's fine - but if they want everything to be *just
like* Windows, then they obviously want Windows. They sometimes seem
amazed that I feel no need to prove to them that the Mac can do
everything they want, but hey, as about 25,000,012 weblog posts in the
past month have proven, even the iPhone can't do *everything.* If it is
absolutely vital to you that you never press more than 2 buttons to dial
a telephone number, don't buy an iPhone.
Use the best tools available for your task. For me, in most instances,
that's AppleScript, and I prefer sticking with a language's syntax and
features in that project where possible. If I can't, I can't - but if I
can, I will. If there's an answer using AppleScript syntax that
involves standard system programs, I want it first. If there's not, I
want shell scripts or other solutions using standard system programs,
and failing that, I want information about calling third-party
applications even though I may have to buy and install them on every
machine where I need the script. Failing *all* that, I'll write my own
or do without.
But most of the time, I already know I could do something in another
language. If I look for help here, I'm looking for a way to do it in
AppleScript syntax without external programs or scripting languages. I
don't need to be told that a shell command is "better" unless I find
that a native way is unacceptable (and plenty of people optimizing
time-intensive scripts have found ways to use shell syntax to speed up
key portions of them on here - and that's wonderful).
If doing it in Python or Ruby or tcsh is the *only* way to do it without
writing an app or buying one, I'll deal with it - but it's not my first
choice and not what I come here to find. I don't think I'm alone, but I
wouldn't want to ban shell scripting from here for all of these reasons.
It's just never my *first* choice of answer for an AppleScript question.
--
Matt Deatherage <email@hidden>
GCSF, Incorporated <http://www.macjournals.com>
"Nothing fires up a crowd like Burl Ives." -- Stephen Colbert, 2007.05.23
_______________________________________________
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