Re: AS Library Question
Re: AS Library Question
- Subject: Re: AS Library Question
- From: has <email@hidden>
- Date: Thu, 10 Dec 2015 19:41:24 +0000
Shane Stanley wrote:
On 7 Dec 2015, at 4:12 AM, has <email@hidden> wrote:
>>
>> Basically, official libraries = more design flaws, more complexity,
and more opportunities to blow up on you when you're not expecting it.
>
> When you first gave us your views on script libraries, your
objections largely boiled down to the per-instance nature of them, and
your dislike of the (entirely optional) .sdef terminology scheme. Oh,
and the potential conflict with JXA .scpt files.
Per-AppleScript Component Instance, you mean. Which means that unrelated
user scripts that import the same library will stomp on each other
should that library contain any shared state. Chris Page's response was
that he didn't see the problem as apps should create a new CI for each
user script, but since that's never been a requirement in the official
developer documentation most apps - and even Apple's own NSAppleScript
class - have spent the last 20 years happily loading scripts into a
single CI and aren't about to change just because some Apple engineer
says something on a little-read mailing list. It's just a typical
example of careless, sloppy, ill-considered engineering and general
inability to take criticism that has long been the current AS team's SOP.
There's also stuff like the horrible `use` statement, lack of
namespacing (libraries can't contain their own sub-libraries AFAIK),
utterly useless error reporting (no stack traces), inability to
customize site paths (10.11 added a shell environment variable, which is
absolutely comical for a language that runs in GUI apps as standard, and
yet another example of the AS team's inability to do joined up
thinking), zero tooling support (e.g. install/uninstall), zero online
repository support (which admittedly renders the zero tooling moot), and
- oh yes - *zero actual libraries*.
In other words, it's weak and flawed in design and implementation, much
more so than it could've been, and utterly risible compared to the
library loaders and ecosystems found in pretty much every other
language. (As I'm sure you'd know if you spent more time learning other
languages and cultures.)
> And, you followed up a little later with a more optimistic take:
>
> > Instead, think about how to get the most out of what we do have: a
library loader which is not technically great but does have the big
advantage of being included in AS as standard
That's not optimistic, it's pragmatic. As I say, it's weak and flawed -
but so is *everything else* in AppleScript (with sole exception of its
Apple event support, which is [sadly] unsurpassed). Compared to
"flamingly incompetent and irreparably broken" (i.e. Scripting Bridge,
JavaScript for Automation), "weak and flawed" is nothing.
"Weak and flawed" is what AppleScripters work with every day; it's
simply the price of doing business in AppleScript's world. You work with
the garbage tools you have, not the wonderful tools you wish you had.
Even a crappy, fragile, non-scalable library system would allow a
significant number of notoriously basic 22 year-old AS shortcomings to
be quickly addressed: replaceText(), sortList(), etc, etc, etc.
> Indeed, you went even further:
>> Getting half-dozen nice standard AS libraries into 10.11 would
provide significant benefit to all AS users at little cost to the AS
team themselves.
>
> So I'm wondering if your latest assessment is based on more recent
experience or technical insight. Because some of us seem to be finding
them pretty useful
Again, even a crappy solution works up to a point, as I've never not
acknowledged. However, I can also do math, which means it's obvious to
me that a library that is useful to YOU is still only 1/5000th* as
useful as a library that is useful to EVERYONE; so your definition of
"useful" is obviously a lot more flexible than mine. (The fact that
"some of you" have done absolutely zilch to bring those benefits to the
rest of the AS community says as much about the terminally moribund
nature of the AS world as the AS team's own failure to build a platform
worth a damn, never mind one they could be justifiably proud of.)
<rant>
At any rate, my previous offer to work *with* the AS team to put
together a standard library for their users' benefit is well and truly
expired. I made one last gesture to Sal a couple months back, to get
decent application scripting support into Swift, and he didn't even have
the good manners to say "Thanks but no thanks" but simply to spew (to
paraphrase) "It's our job to remain ignorant and ignore our users."** So
if the AS community wants any libraries worth a damn they're going to
have to build them themselves now, because I'm no longer willing to help
and the AS team are no help to anyone but themselves.
Worse, I've reached the conclusion the ONLY way Mac Automation has ANY
chance to survive, grow, and thrive in the long term is for Apple to
scrap the current Automation team completely and legacy the entire crap
pile from AEM and OSA up, and start over completely afresh with, say, a
new independent JavaScriptCore team tasked to bringing JS-based
automation to all aspects of Mac and iOS, working in conjunction with
the XPC engineers to provide a usable (if ugly) replacement for
inter-app communication. A "worse is better" strategy, to be sure, but
at this point I'd far rather see AppleScript lost and Mac - and iOS -
Automation saved, than watch the end-user scripting and automation
disappear altogether. Sadly, I seriously doubt Apple care enough about
end-user automation even to bother doing that, in which case all we can
hope is for AppleScript's long tail to stretch for as many more years as
possible.***</rant>
Regards,
has
--
* Or however many AppleScript users are left these days. There's been no
growth in it for at least half a decade so it can't be all that many,
and it's definitely a tiny fraction compared to a similarly mature
language such as Python or an enthusiastically growing one like
JavaScript. :(
** IIRC, Sal's actual wording was something like "it's against Apple
policy to look at unsolicited code", which was just insulting since, A.
they're Apple, they've bigger and richer than everyone and do damn well
whatever they like, B. they already solicited this code (in earlier
incarnations) back in 2007 when they were considering it for inclusion
in 10.5, C. there was nothing stopping him soliciting it again now he
was aware of its existence, and D. I'm trying to *help* the dumbasses
out, not simply for their benefit but for the good of *all us users*.
Compare how the Swift developers interact with their community, and look
at Swift's meteoric rise and massive user love and enthusiasm, and it's
no surprise I told Sal that it is *his team's* arrogance, ignorance, and
incompetence this is slowly shuffling Mac Automation into its grave.
*** Maybe next year if I still care enough I'll see if any of the Swift
folks might be interested in AE support, but frankly it's not my job to
save Mac Automation from itself, and if it weren't for my own projects
still being deeply dependent on high-end AE automation I'd have given up
long ago.
_______________________________________________
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