Re: AppleScript and programmers (was: Re: on neophytes vs perfectionists)
Re: AppleScript and programmers (was: Re: on neophytes vs perfectionists)
- Subject: Re: AppleScript and programmers (was: Re: on neophytes vs perfectionists)
- From: has <email@hidden>
- Date: Sat, 20 Dec 2008 00:12:48 +0000
Shane Stanley wrote:
>> With more than 30 years experience I find AppleScript to be the
least
>> approachable language I've encountered.
>
> As someone who has teaches AppleScript, I can tell you you're not
alone --
> people with extensive programming experience often have the hardest
time
> coming to grips with it. My guess is they keep wanting it to be
what it's
> not.
Partly, but there's a lot more to it than that.
Yes, programmers kvetch about the weird, unfamiliar syntax and how
various features are different to what they're used to - but they do
that about *all* languages, not just AppleScript. Fact is, once you
start learning a new language, its syntax is the easiest bit to pick
up. Also, once you know one imperative procedural/object-oriented
language, picking up others is relatively easy as well - e.g. I
learned basic Ruby in a week based on my Python knowledge, and basic
Python in about the same time based in good part of my AppleScript
experience. (It's getting to grips with the various supporting APs -
modules, frameworks, scripting interfaces, etc. - that's the time-
consuming bit.) So learning a supposedly "simple" language like
AppleScript itself should, in theory, be an absolute cakewalk for
anyone already familiar with C++, ObjC, Python, Ruby, etc.
Here are the things about AppleScript that *justifiably* freak out
programmers:
1. AppleScript syntax is inherently ambiguous. In order to make it
look "English-like" the original developers eschewed much of the
cryptic brackets, braces and other symbols that more traditional
languages use.
This is good in that it makes AppleScript code relatively easy for
complete non-programmers to read and still get a good sense of *what*
that code does. It is bad in that all that cryptic gubbins was
actually there for a reason: it tells you exactly *how* it does it.
Without that information, it is much harder to understand the
underlying mechanics involved, and if you don't have a good grasp of
the mechanics you will struggle in trying to assemble code of your own
as you are never really sure which bits you've got or how they should
fit. Other syntaxes may look like ass, but they are really precise,
detailed ass, and once you learn to interpret all that line noise it
ceases to be scary and starts to be helpful in a way that AppleScript
syntax never is.
2. It is difficult to tell which bits of a script are part of the
language, and which are really parts of scriptable applications, as
AppleScript kinda smooshes the two together so you're never really
sure where the joins are.
This wouldn't be quite so hard if the native language features and
remote application features all looked and behaved in exactly the same
ways, but they don't. That means a technique you use successfully in
one part of your script fails in another, and it's not clear why.
Eventually, experienced AppleScripters learn to tell the difference
and memorise the different traits of each, but that takes lots of
time, clever deduction, and trial and error research. Most other
languages do not treat their users this way, preferring to draw
obvious lines between different component parts so that users can
easily see whereabouts they are.
3. Pretty much every programmer I've talked to looks at AppleScript's
application scripting syntax and goes "A-HA! Application Scripting
equals Object Oriented Programming!"
WRONG! It is, for want of a better description, RPC plus queries.
AppleScript is quite misleading in that its syntax looks object-
oriented, and various hidden behaviours such as implicit gets
initially reinforce that misconception, but pretty soon programmers
who believe it to be object-oriented discover that it doesn't exactly
behave as an object-oriented system should. This difference between
what they *think* they're asking it to do and what it *actually* does
understandably drives them nuts. Because the underlying theory and its
practical implications are never properly explained to them, they
naturally fall back on their existing knowledge and experience (which
is of object oriented systems), trying to map that OO knowledge onto
AppleScript based on the visual similarities.
I've lost count of the number of times I've told programmers "It's
*not* OOP, it's RPC plus queries". Some immediately "get it" and are
soon off automating applications as well as any AppleScripter. Others
don't, and continue struggling in their tarpit of faulty
understanding. As someone who's spent years trying to evangelise these
technologies to programmers, it's really frustrating when that
happens. As AppleScripters, you should all be concerned, as quite a
lot of programmers are also application developers, and if they can't
grasp what makes Mac application scripting tick, what chance of them
creating great [Apple]scriptable applications?
4. Documentation. Or rather the abysmal lack of it.
5. Reliability, or the all too frequent lack of it.
6. Peer support, or the heavy shortage of it. Folks like me and Matt
try to do our bit to help, explaining things to them in ways that they
can understand, but we are small in number and doing it off our own
backs because we believe in the technology (or at least the important
parts of it) and want to see it succeed, not because we're being paid
for it or anything like that (well, except when we are; but it still
won't buy us those tropical island paradises we really need).
Then there are the relative shortcomings of the language itself, such
as the severe lack of features, total absence of library support, and
significant shortage of tool support compared to what they're used to.
(Yes, Script Debugger is wonderful, but still only covers a fraction
of the ground that 'big' languages' toolsets provide for.) This is one
of the reasons I've spent five years working on appscript: so that
professional programmers would have a genuine alternative to
AppleScript for controlling scriptable applications.
However, even having alternative Apple event bridges and/or OSA
language components doesn't insulate them completely. They still need
to learn enough AppleScript to be able to interpret existing
application documentation and sample code, and to ask for help from
the primary experts in Mac application scripting [1] whenever they get
stuck - which, given the lack of documentation, reliability, etc, is
just as often as everybody else.
...
So yes, real programmers are ornery, stubborn and stuck in their ways.
But hey, so are most AppleScripters too if we're being honest. The
difference is that programmers have typically been around the block a
few more times than non-programmers, so they're much quicker to spot
when they're being short-changed and a lot less restrained in kicking
up a stink about it.
Regards,
has
[1] That's you lot here, in case you didn't know. (But don't be
getting swole heads now just 'cos I said so.)
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net
_______________________________________________
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