|
[last one, then I'm officially off till
2016]
On 18/12/2015 11:16, Chris Page wrote:
Honestly Chris, advocating deep technical enhancements to
the core language is pointless.
Obviously, I disagree, and not just with words, but with my
own actions:
Ah, but we can both play the "not just words" card: AppleMods,
Python/Ruby/MacRuby/ObjC appscript, MacPythonOSA/PyOSA,
_javascript_OSA. Difference is, your actions - even the wrong ones -
get welded into the OS. Mine generally go tits up through no
technical fault of their own, in consequence of inadequate project
management by me and larger decisions made by you (Apple/Automation
team).
Had Apple gone ahead and included appscript in 10.5, I seriously
doubt we'd be having this discussion because the Mac Automation
world would have gained thousands of enthusiastic and talented
Python and Ruby converts who'd be building it into something far
more than just the sum of its parts - and at virtually no cost to
the Automation team itself. Because that's how *successful
communities work*, and anyone here who thinks otherwise
*desperately* needs to pull their head of the the sand and spend
some time exploring the world beyond of the AppleScript ghetto to
realize just how much *they are missing*.
Had the AS team learned from its technical mistakes and popular
failure on Scripting Bridge and done _javascript_ for Automation right
- or even talked to me post-WWDC14 when I was busting a gut trying
to save it from itself (and you) - you wouldn't have cocked that one
up too. And maybe JXA, which is after all built on a language with
millions of existing users, wouldn't have shipped Dead On Arrival,
lame and broken with zero documentation, support or evangelization,
and promptly ignored by all but a handful of those millions. (And
even they struggled to make it work, or just abandoned it and went
back to AppleScript.)
I was prepared and ready to write *the* book on Automating your Mac
with _javascript_ for Automation, but I could not write a book about
the piece of junk that you guys shipped. 1. I've already attempted
three books explaining another hideously complicated and flaky
technology, AppleScript, and it flat killed two of them and left
everyone involved in the third completely trashed. (Plus, pity the
poor reader who has to wade through 500 pages just explaining a
language that should've taken no more than 50, c.f. Logo.) So there
was no way I could ever write a good book about bad software, nor in
good conscience sell it. And 2. The Automation team, as represented
by Sal, who declared huge enthusiasm for my input and then promptly
ignored both it and me, wasted six weeks of my time, pissed me off
with their irresponsibility and callousness (I expect that from me,
not you), and blew not only the little confidence I could still
muster but all my respect and support too.
So that's what *I've* been doing, and all off my own back and out my
own pocket. The difference is, I've been doing it not just for the
love of the technology and what it lets _me_ do, but also because I
believe - hard - in what it lets other users do too - and not just
the few thousand users it has, but the *millions* of users it could,
and should. As Facebook, Google, Apple, et al migrate us from their
original pants-down implementation of personal computing to their
new chooses-our-pants-for-us model, AppleScript is this last, lonely
hint of a radically different vision, one where developers, users,
scripts, and programs all work *together* to construct the tools
that *users* want, not just the tools that vast powerful
multinationals dictate we should have.
I've been improving AppleScript every release for years,
involving significant changes. I added libraries and use
clauses, support for terminology in scripts, parameter type
declarations and default arguments for handlers,
“AppleScript/Objective-C everywhere”, and more. In particular,
most of these are focused on making it possible to write
libraries that can replace scripting additions, with a lot
less code compared to writing event handlers in C.
And what has this achieved? Has it brought in new AppleScript users?
Has it improved AppleScript's reputation amongst professional
programmers and app developers? Has it improved things for the
AppleScript community, by making it possible for them to share
libraries with each other, as Python, Ruby, Perl, and every other
community does? Has it enabled AppleScript users to do a
find-and-replace on text, or sort a list, without resorting to the
same hand-to-mouth, scratching-in-the-dirt, mailing list begging
caps and old wives' tales copypasta crap that has been the sole
modus operandi for pretty much every AppleScripter everywhere for
the last 20 years?
Answer: No. It hasn't.
Like way too many programmers, you think that if you write it they
will come. I'm sorry to report, the world doesn't work like that, as
Apple itself taught me when it decided not to include appscript in
10.5. Had I done more community building work, had I worked to build
influential contacts and supporters both outside and inside Apple,
the decision might well have been different, because the person
making that choice would have had the full picture. But since s/he
couldn't see the benefit of having three (per-language) Apple event
bridges instead of one, so in absence of any better information made
the obvious economic choice to have one to cover all. Didn't even
matter that Python and Ruby appscript were proven, popular,
production-quality software while SB was a pile of tat; technical
merit is the _least_ important factor in determining success.
Getting out in the trenches, working every day to advertise and
support _your_ product and build both user base and ecosystem for it
is what makes success.
To everyone else reading this, I'll reiterate: please file
radars.
And if anyone's still reading this, perhaps they will. However, once
again you are failing to understand your own users. You're expecting
them to behave as trained professional programmers like yourself
would, sharing the same expertise and motivations as you. But
AppleScript users, with few exceptions, are NOT trained professional
programmers; their interests and education are in dozens of other
fields that are vastly more important to them than learning how to
program professionally.
Saying "file a feature request" is utterly meaningless to people who
aren't even aware of what they're missing, never mind what it could
do for them if they had it. I'm not kidding about "find and replace
text" and "sort list"; these are the sort of insanely basic, OBVIOUS
omissions that if you added them tomorrow would be a thousand times
more popular than your clever library architecture with its clever
SDEFs and clever `use`s and all the other clever things that have a
habit of creating as many new problems (e.g. mad namespace pollution
and collision potential) as they ostensibly solve.
Putting together a standard library may not be an enticing prospect
to you, cos let's face it, it's 100% drudge work regarded as beneath
a mighty programmers's talents, whereas compiler/interpreter hacking
is _exciting_, a worthy challenge for a true champion. But the whole
point of having a library system is in the first place is not to
exist for its own sake, or even to load libraries, but to provide
users with simple, easy, zero-effort access to tons of useful, basic
functionality that they need every day. And if you're too
lazy/disinterested/bored to put in the first half-dozen libraries
yourself, not only to prove to yourself that the system works as
well as you've hoped, but to prove to users just how useful it
really is _and_ make a significant start at being just that, then
why should you expect much interest or adoption by anyone else.
And now you're asking users to beg as well. Okay, please, on behalf
of all AppleScript users everywhere, put a frigging standard library
for AppleScript in 10.12. Text, Math, Date, List, File (I/O).
A given component instance can contain more than one
script, and all the scripts share state like “text item
delimiters”.
TIDs are a known exception to the "scripts don't share state"
behavior. Heck, all but the greenest ASer knows that TIDs aren't
even safe within the _same_ script, which is why it's drilled into
them always to do `set TIDs to WhatYouActuallyMean` immediately
before doing any text-splitting or list-to-text operations. And
anyone who knows anything about good software design knows that
global TIDs are an absolute abortion of a bad idea, and should've
been done using a local 'with text item delimiters {...} ... end'
block. So advancing a Notoriously Bad MisFeature in defense of your
argument is really just doing my job for me.
This is a feature: you can have more than one script
interact with state and with each other, executing one, then
another, then the first one again, or what-have-you. Scripts
are persistent, stateful objects that you send messages to,
not just linear code that runs once, independently of all
other scripts in the component instance, and component
instances contain state shared by all the scripts within them.
This has always been the case, and it has always been
documented.
I've read the OSA documentation. It's 100% technically accurate and
100% useless in actually telling developers how to (and how not to)
use it in their apps. You keep telling me how you believe the world
should be. I'm telling you how the world *already is*. One of you is
going to have to accommodate the other in order to do right for
users, and if you need me to tell you which one that is then I'll be
wondering why you're in the nice office with the nice chair and the
nice salary while I'm out here wondering how I'm going to pay next
year's rent.
The rest is just the same appeals to popularity, authority, and
irrelevant analogies to use cases in other, professional
programmer-only, platforms that bear little, if any, resemblance to
AppleScript's. So I'm going to call it quits at that, and in the
hands of the middle managers and beancounters be it.
Regards,
has
|