Of possible interest to the KM community: Apple has eliminated the Applescript and automation position?
https://macosxautomation.com/about.html
I’d like to say how positively wonderful Keyboard Maestro is, and how much I value it. I evangelize it all the time. Please stay with us forever ^_^;;
Fascinating article.
Thank you, @ppayne, for posting that link here.
After reading the article (by Sal Soghoian), I signed up to receive the wnewsletter.
The automation of that process was stunning:
It figured out my email program, which is not one of the standards.
Activated email, opened “compose new email” complete with “to” address, subject, and short text filled in.
I clicked once, “send,” and that is all I did.
I’m impressed.
I just read it a second time.
After 20 years he got fired from a job that promotes one of the most outstanding features of Mac OS.
(Product manager for automation technologies.)
Only two or three people in the world with that depth of experience.
Impossible to replace him.
Very strange.
How could that be explained?
What is the best fit to the facts?
My speculation (but without any facts):
Political correctness at its evil worst.
20 years experience doesn’t matter.
No more use for a middle-age, white man.
Putting that one piece together with many others, I think not just trouble for Applescript, but trouble for Apple as well.
Not tomorrow, but trouble on the horizon, sure.
Maybe Apple will thrive on watches and electric cars.
But I won’t be buying either.
Hey Mark,
That's a basic mailto URL.
They've been around for a long time now.
Use “Inspect Element” in the context menu of your browser to see the code that makes it work.
Search Google for “mailto hyperlink”
-Chris
.
Yes, indeed, a long time.
I learned about it in "HTML 101" about 30 years ago.
But the "stunning" part is that Sal Soghoian uses it on his web site, but almost no other web builders do.
Others have a convoluted process like ths:
On the other hand, Sal Soghoian's approach:
The simplicity was stunning.
Why isn't every web builder using that basic mailto URL?
I never knew about Sal Soghoian until a few days ago, when the news came out that he was fired by Apple.
My respect for him increases.
For anyone interested, there is a long thread about this on the AppleScript Users List:
AppleScript Users List RE: Sal
I wouldn’t worry too much – any genuine crisis in automation technologies would take years to develop (and so would the solutions). It’s not even clear that this particular personnel change really signals a great deal.
(If you are starting to learn a scripting language now, then perhaps it might make more sense to learn JavaScript than AppleScript (useful on the web, and on iOS and other platforms as well) but even on that score, once you have digested the basic concepts of one language, a second language is always interesting and easier to learn).
Fans of macOS automation features like Automator and AppleScript feared the worst this week as it transpired that head of the automation technologies division, Sal Soghoian, had left the company and the whole unit inside Apple had been closed down. This fuelled speculation that Apple was abandoning a core power feature of the pro Mac user’s wheelhouse.
A 9to5Mac reader (who asked to remain anonymous) emailed Apple software exec Craig Federighi about the future of automation on the Mac. Federighi responded with a definitive reply that Apple “has every intent” to continue supporting automation on macOS. See the full email after the jump …
Here are a couple more blogs about the implications of the leaving of Sal Soghoian from Apple by two AppleScript veterans, both a long-time user/developer/advocate of AppleScript.
I know a few of you are interested in, and maybe excited by, Swift.
Here is one informed person's view that macOS and iOS scripting may be moving to Swift:
Goodbye AppleScript – The Eclectic Light Company
Apple has invested heavily in Swift, and in 2017 I expect to see it confirm the death of AppleScript, and to announce its replacement by a new scripting system based on Swift playgrounds, which will not only run on macOS, but which will also empower iOS users. I’m heartbroken that AppleScript is going, and grieving at the departure of Sal Soghoian, but I’m looking forward to getting to grips with the Swift tools of the future.
On the other hand, Sal Soghoian's approach:
click (opens email)
click (sends email)
The simplicity was stunning.
Why isn't every web builder using that basic mailto URL?
Actually this is the way IT WAS DONE IN THE 90s. Email signups prior to that (browser based interaction) used an email send to start/stop the subscription. Commonly referred to as LISTSERV.
How do you know this?
Actually, I prefer to send REAL email from my own email client.
This does not make sense. Why would my own email service provider block outgoing email? I've never seen this happen.
Sorry, but I disagree.
The long-standing mailto: URL is very secure. All it does is invoke your default email app, but does NOT auto-send. You can choose.[quote="CrashAndBurn, post:11, topic:5528"]
Most important, you get far less (almost none) tracking info from having people send emails.
[/quote]
I guess the "you" in this statement is the company requesting the email.
IMO, the recipient gets all of the "tracking" info it needs when it received the email.
This is simply a matter of choice on the recipient's system.
How do you know this? [people don't like using their email client]
Experience. LOTS AND LOTS OF REAL WORLD EXPERIENCE. The world of email clients was not always so wonderful.
Also, not everyone uses an email client. And not all use a client that can be a "default client." (MUTT, is a good example. Yes, there are ways to kludge this, but eww)
If you use a "throw away" that is NOT connected to the system you are on (usually browser based, but sometimes via virtual machine, or live cd); how do you sign up for the list? Copy and paste? Most people will not do that.
Actually, I prefer to send REAL email from my own email client.
Your personal preference is irrelevant. And just what would FAKE email be?
[companies blocking outgoing email] This does not make sense.
You must be joking, right?
Companies routinely block outgoing email. I know, I've done it at hundreds of companies. Only foolish companies DON'T block by default. BTW all external connections should be blocked by default.
Why would my own email service provider
block outgoing email? I've never seen this happen.
Why do you think GMAIL, and other email providers provide alternate ports for SMTP?
SPAM SPAM SPAM. It goes out on port 25. Guess what used to be the easiest way to send it? Compromised machines running (usually windows) at a home on a NON commercial internet connection.
ISP's don't want you running mail servers on their system, unless you are paying for a commercial internet connection. So they block port 25 for home users. Again it's common.
Sorry, but I disagree. [that it's easy to manipulate LISTSERV]
You are WRONG. Again, experience. LISTSERV was designed to be COMMAND driven via email. It was NEVER meant to be secure. Why? It was usually an internal tool.
We all loved being able to start up MUTT, send SUB email to LISTSERV XXX, and when we would be gone for awhile send a NOMAIL email to get off till we returned (the cool kids had scripts to do this). And then upon return, send a MAIL email , to restart. And if you wanted to see what you missed you could send INDEX, and get all sorts of good stuff, hopefully.
Those days are OVER, with rare exception.
The long-standing mailto: URL is very secure.
SMH what does that have to do with the server? And no it's not secure, why do you think so many sites, when they do use it, obfuscate it? (email scraping, fyi, which can be used to attack the server)
All it does is invoke your default email app, but does NOT auto-send
Where the did I say that it auto-sent?
IMO, the recipient gets all of the "tracking" info it needs when it received the email.
AGAIN, YOUR opinion is IRRELEVANT. The discussion is about why THE MAIL SERVER OWNER is using a particular method, and the reasoning behind it.
[bulk email services WON'T allow incoming email for signups.]
This is simply a matter of choice on the recipient's system.
It's about security, not preference.
LISTERV used to bombed regularly (Denial of Service). How do you do it? Send millions of request for signups for emails, that's the easiest; looping SUB/UNSUB/INDEX/NOMAIL/MAIL requests will bring down a server, too. Again REAL WORLD EXPERIENCE, before you ask.
BTW why do think sties have gone to CAPTCHAS? To stop this same thing from happening on the forms.
PROFESSIONAL mail services DO NOT EVER ALLOW EMAIL SIGN UP/OFF. It's just DUMB. (and if they do, RUN, don't walk to another provider, they'll be blacklisted for out of business son)
Professional sites have to keep their email from being SPAM boxed (or worse "slow rolled") due to bad emails, so they don't do incoming email signups BECAUSE IT'S EASY TO GAME THE MECHANISM.
Some private LISTSERVs do allow email sign on/off, but that's not the norm, anymore.
@CrashAndBurn, @JMichaelTX - Hey guys, what does this have to do with the topic “Trouble for Applescript?” I suggest you take this to a private thread.
Thanks.
You are correct, Dan. Most of our discussion is very off-topic.
Unfortunately, it actually started with posts by several others, which makes it difficult to move to a new topic.
I will not respond further to the off-topic, so I hope we are done with it. 
Returning to the original topic...
Thank you, @JMichaelTX, for links to those blogs.
I've been reading.
And here's a comment from the larger perspective of the future of the "pro Mac market".
That's us, isn't it?
I wonder how this situation could affect dedicated Mac users like us.
"Obviously the pro Mac market is only a speck in Apple's overall
financials, and they obviously simply don't care about it anymore.
They've been making that excruciatingly clear in a multitude of ways
separate of terminating Sal's job and all that implies."
.
Michael Tsai - Blog - Thank You, Sal
.
That comment is from the public forum for EagleFiler software.
(I'm not interested in debating; just gathering and trading 'intelligence' about it with others here.)
Few storms make it out of the teacup, and even then only slowly 
I don’t think this one is going to make it.
Apple will need Macs as long as developers need them for the development of iOS software. Full stop.
(If iPad Pros or some fused descendants of macOS and iOS devices are ever flexible enough for use as iOS development platforms, they will also be flexible enough for use as automation platforms for professional work).
In the meanwhile, we’ve got excellent resources already to hand, so lets just use them. (If some kind of Automation version of Swift emerges in the place of AppleScript, then just enjoy learning it when and if it comes. AppleScript’s OK, – plenty of fun – but it was never really that good. Not a patch on VBA, for example )