81 comments

[ 3.0 ms ] story [ 139 ms ] thread
AppleScript and other user automation are pro features. They've steadily moved away from that market so I think it's unsurprising if it were retired / abandoned.
AppleScript certainly doesn't feel like a language for "pro". It feels like a language for people that can't learn regular computer languages. The irony is a language with a small syntax is easier to learn than something that tries to mimic real languages.
OP understands the argument is about user freedom and wants Apple to act to preserve it? Really? #wrongtree
Apple, can you sink no lower? Even MS has this one figured out.

I guess I'm just pissed because Apple's stuff used to be so good, in so many ways. Heck, I was raised on OS9, and later OSX (both PPC and Intel): I couldn't stand Windows, and was an Apple fanatic for years, viewing even Linux is a worse alternative. I only fell into the Linux thing because I was building my own computer, and no way in hell was I installing Windows on it (Yes, really: And what a faithful decision it was).

And now... Jeez. What a mess. Seriously, Apple. Up your game.

I don't think Apple needs to up its game. I think it needs to put some of the gray hairs out to pasture. If I see another video of Jony Ive looking soulfully into the camera telling me that I really really don't need USB and MagSafe because the future ...

Love my SE. Love my Mid 2014 MBP. Don't need a watch.

Well, this article is basically all speculation, so I wouldn't complain yet.
I don't believe it's all over for Application automation on the Mac. Final Cut Pro X and recent updates to iWork apps have all included system automation hooks. This was one of the concerns with the recent rewrites of their apps, that automation would get deprecated, but in reality that hasn't happened. It's always a worth these days, which is disappointing that it's even a concern, but it's not all over yet.

On the bright side, at least OSX has a single standard application automation system that still has decent support. For all the moaning about Apple closing up their platform, arguably OSX still has a far more capable and better supported application automation story than Linux. That's one advantage of a centrally planned platform that has actually delivered benefits to users.

Better automation than a system where most serious applications expose all functionality to the command line? You've got to be kidding.

Better supported, more consistant, yes. But more capable? I doubt it.

All we can do is guess, but maybe they're retiring AppleScript specifically, rather than automation support generally?

Yosemite added JavaScript for Automation (JXA)[1]. Very few people actually enjoy writing AppleScript, I think most see it as a noble but failed experiment in human-language syntax. Perhaps this is just a sign that Apple's removing AppleScript altogether in favour of JavaScript?

[1] https://news.ycombinator.com/item?id=7862973

I'd be very happy to see AppleScript retired in favour of JavaScript. The pseudo-english syntax has always been painful. It might have been reasonable with a good IDE, but I have never found one that can tell me how to write what I want to write.
JavaScript is not AppleScript.

JavaScript is only useful with dozens of libraries imported, and they introduce their own quirky syntax (I'm looking at you, JQuery).

JavaScript can't "do shell script" (even PHP can do exec).

JavaScript can't read and write files.

JavaScript can't read the selection in one program, pull data from another program, and merge it in with something on the clipboard to piece together what you're actually wanting.

JavaScript can't handle unicode to my satisfaction. Even escaping strings is a pain. AppleScript's string manipulation is so clean. Regex that would be very complicated to put together without a trip to StackOverflow is translated into something super easy ("every word of last paragraph").

JavaScript can do whatever the environment lets it do. Obviously browser based JavaScript is extremely limited but JavaScript running outside of a browser (e.g. on a server, or in a desktop application) can and does do all of those things you say it can't do.

It's been a long time since I've ever done any AppleScript so I can't really compare, but it does seem like the JXA environment can do any of those things, since it has an Objective-C bridge[0].

[0] https://developer.apple.com/library/content/releasenotes/Int...

I assume they would leave AppleScript just for legacy purposes, even if they are moving to JS or something else.
Have you tried using JXA? It's horribly undocumented! :( I find it incredibly frustrating, because otherwise I think JXA would be amazing. It's actually incredibly powerful, if you're willing to put in the time to figure it out.

You can use JXA-handbook and its linked resources as a reference. But aside from that the only thing you'll find from Apple is the changelog [1] and the library in Script Editor (open it with shift+cmd+L).

[0] https://github.com/dtinth/JXA-Cookbook/wiki

[1] https://developer.apple.com/library/content/releasenotes/Int...

Python has had bindings for AppleEvents too, which is the underlying OS mechanism for AppleScript/Automator. Most of what you can do in AppleScript can be accomplished in python.

Or at least that was the case back in the 10.6 days. I wonder if those bindings are still being maintained.

Part of how Microsoft got into a bad spot was refusing to end-of-life anything. The hardest choice in making products is what not to build and what to take away. Apple cannot maintain an infinite number of components, so I find this type of argument unconvincing. If this feature is so important I need to see numbers. How many people are using it? The thing is, Apple probably already knows this from system analytics and they know that they are better off putting 50 engineers on facetime and zero on this. If you want to argue a feature is important, show me numbers. They cannot please everyone.
But they can please the right type of people. You know, the users who talk about your product all day long to anyone you asks and end up bringing all of their relatives onboard. You want those too, and raw numbers won't let you know who they are.
It's a fair point. Not all users are equal but I'm very unconvinced by this user's issue because there are a million little oddball use cases out there and Apple does not solve those for everyone. The only issue here is that they used to solve this issue for this user and now they are maybe taking it away.
If they can mess with swipe to unlock and make my kid cry then really anything is on the table and we just have to adapt.
"Have to adapt"?

There's choice in the market, you know? I'm pretty happy with my Nexus 6P, for instance.

My kid is now very happy with my 6P too :-)
There's a lot of things I dislike about Microsoft and Windows 10, but as a PC gamer their support for backwards compatibility is something I agree with. I can, with a little effort, run a 20 year old game (Diablo) on Windows 10. That's amazing.
Automation was a pretty big thing on OS X, though. I understand that Pro users are not Apple's market anymore, though, so I guess it makes sense...
So long as OSA sticks around, it'd be hard to shed a tear over AppleScript - you can use saner languages to do everything Applescript does through OSA. AppleScript is a complete abomination of a language. Killing OSA would be a terrible idea though. Not enough information to really know what's happening, regardless.
Bring us back another HyperWebCard with a born again ResEdit.
Second that! Like many (almost all?) others, I find AppleScript the language really painful to use. As I recall HyperTalk was similarly laden with unnecessary syntactic sugar, but the HyperCard environment was so much fun to use that I really did not mind the language.
I really enjoyed working in HyperCard, HyperTalk 2.0 -- but never felt that way about AppleScript.

I don't know why, exactly. Perhaps it was that HyperCard defined a domain. Applying the same primitives to every app could get clumsy.

A hand-waving example: making every useful procedure a function hanging off of a single Window object. Except for the two functions that are actually in the Application object...

(I don't have specific example at the moment but this sort of thing was discouraging for me.)

I think what was fun about HyperCard was that it was not purely textual -- a lot of the work (and fun) in building a stack was graphical. AppleScript seems more like a traditional programming language, but with syntax I have a hard time remembering (only use it very occasionally) and a lot of extra typing.
Literally the only thing I'd improve about this article is that I wish they'd not be so 'iTunes-specific'.

AppleScript is beyond useful for just iTunes - back in the 10.4/10.5 days, I used to use AppleScript for some pretty interesting things, including modifying the 'Extras.rsrc' file to perform some interesting functions like colouring windows and changing font files that OS X simply didn't support at the time.

I also recall making an AppleScript that did some other OS/GUI-level modification, such as choosing to have my icons at the left side rather than the right on the desktop (coming from Windows this was rather annoying)...it's an incredibly powerful and useful tool when utilized correctly and I sincerely hope Apple keeps it around.

EDIT: Damn, I looked around to find that old 'Cloak' program but it looks like macthemes.net has been gone for a long time...makes sense since there's no real 'scene' for that anymore as it's all dynamically-generated now :/

Hell, at my last gig, we used AppleScript to build custom DMGs. No doubt there are probably easier ways to go about it, but we didn't need a GUI and the end result was consistent.
I'm not an expert, but it seems like there's at least some separation between AppleScript (the programming language), Automator (the visual IDE), and the Open Scripting Architecture (the language-agnostic framework that actually interacts with the OS and applications).

Does anyone know if it's possible to either build open-source clones of Applescript and Automator? I can see why Apple would be leery of supporting a team of people to support those, but maintaining and supporting the OSA seems to bring a broad set of benefits.

They have also just killed wifi routers, which likely means Time Machine is also living on borrowed time (clearly it's all going to iCloud very soon).

At least this should free them to focus on their real revenue generators: dongles and "jet white" phones.

You want to script iTunes? That's such a niche usage that it's surprising Apple allows it at all. ITunes is for content consumption.
did you read the article? scripting itunes is for curating the consumption library.
I was going to say what I use Automator for in iTunes, but then I read the article and what the author does is pretty much the same thing as what I do.
LOL. He writes "You see, it’s all about freedom. Freedom to do things we want that Apple doesn’t think we need to be able to do."

Apple was never about freedom. Apple has always been about control. They take freedom and control away from consumers to deliver a "better experience" and charge a premium for it. If you don't align with Apple's vision, you are always SOL.

Their whole business model is built on a gamble that they know better then everyone else. no Floppy, iPhone, iPad, no headphone jack... (although the headphone jack is probably a bust)

Exactly. If he seriously cared about freedom he'd be using an open-source operating system.
You can give user freedom to customize the OS in a closed source system TBH. Look at World of Warcraft. The interface can be customized to the user's need, yet WoW isn't open source.

And macos is based on an open source Kernel (darwin), and does a lot of open source stuff in general.

Of course a closed source system can be very customizable, but as OP noted, Apple has never been about freedom of choice.

Their whole business model is about locking you in to their products. They are not the only ones who do this, of course.

But I also had to actually laugh out loud when I read the whole "it's about freedom" paragraph.

The Apple ecosystem is the wrong mothership if you care about these things.

Yep - and this model generally works because when it comes down to it choice sucks.

I'd rather have a high quality thing with good defaults than a thousand different things to choose from. Ultimately the best would be a combination where you have high quality software with sane defaults that also allows a power user to make changes when necessary, but in practice it's hard to do both without tradeoffs that cause you to end up with neither.

This doesn't mean I don't like playing around with linux or that everything Apple does is high quality (looking at you Apple Music), but generally reducing choices a user is required to make is a good thing.

> I'd rather have a high quality thing with good defaults than a thousand different things to choose from

You're a one off edge case though. There is a line between flexibility and lack of control.

Are all Apple's customers one off edge cases? That's an awful lot of one offs.
He was complaining about an odd one off edge case of debating that quality must come at the cost of flexibility....
(comment deleted)
Given the exclusive choice between the two options, I'd rather have a thousand things to choose from. Chances are that many of those choices will suit my needs better than the one "quality thing with good defaults".

I'd consider the "quality thing" as a baseline, or a starting point. From there, if something bothers me enough, I can look for an alternative that doesn't have that problem. If nothing bothers me that much, then I guess that the defaults were good for me.

"Apple was never about freedom. Apple has always been about control."

Not so fast youngster. In my PR#6 days you could open the top and add cards to improve your machine. Changed after Woz was relegated by Jobs. Apples historical roots is in open hardware.

So that's, what, 5% of Apple's life? :)
"Apple was ^never^ about freedom."

QED.

> Their whole business model is built on a gamble that they know better then everyone else.

$596B in market capitalization says they had a point.

I would think that if they're getting ready to introduce a replacement technology ("SwiftScript" maybe?) they wouldn't let go their expert on the old tech just yet.
Just Swift I hope. I'd guess it more likely that scripting was dropped alltogether as the number of users of AppleScript is probably under 1%.
The concept of a general computer is under attack by Apple, Google and Microsoft because consumers don't care and would ultimately prefer an appliance over a general computer. I think it means that the future of general computers will increasingly be relegated to open systems, namely Linux.
They're not attacking anything, they're just presenting an alternative. Nobody is trying to take away your Linux distribution.
Maybe attacking was the wrong word. Apple and Microsoft, at least, have historically produced general computers but they're moving away from that as computers move more and more from the domain of us nerds to an everyday appliance involved in all aspects of our lives.
Next year I will have been programming for half a century; in this time I've used a few dozen languages (counting things like awk, m4, and SQL in addition to ordinary programming languages). AppleScript has to be near my least favorite language. It's so called natural language syntax is verbose, unintuitive, and ambiguous to me. Almost any real programming language would be better: bash, python, Lua, JavaScript, tcl, ruby, whatever.

AppleScript seems to be a valiant effort to design a language for non-programmers, but the English like syntax just adds complexity to writing even simple programs.

See Dijkstra's take on "natural language" programming[1].

[1] https://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/E...

You're also not the audience that AppleScript's natural language programming was designed for (similar with Automator). Don't get me wrong, I feel the same pain points, but AppleScript never was a programming language for developers.
Yes you're right. Perhaps something like Automator or even Scratch might work for non-programmers instead of AppleScript. I find both of those quite intuitive (although slower to code in for a trained programmer).
IMO just use Lua as it's easy to embed and well-suited for the task of ad-hoc scripting. There's also a large community and plenty of library support to help get weird interactions working.
I think its a lot worse than this though; it isn't realistically a language for anyone.

Anyone working on almost any task in Applescript is going to be frustrated. In particular, just the ambiguities in the language for doing simple queries on containers makes writing even simple scripts needlessly painful.

This.

I can't remember what it was like before I learned a programming language. I do vividly recall my fights with compilers, however, and imagining trying to guess what Applescript wants in a particular context without reasonable notions of what was going on under the hood, and I would have become a plumber instead.

Applescript is horrid. Seriously, every time I try to write something in it, it devolves into Googling for whatever weird, stilted 'natural language' variant is needed in a given context in the best case. The worst case is me wracking my brain for odd ways to write subordinate clauses that might make it happier.

Applescript should be used as the definition of a write-only language. People like to bag on Perl, but even if you hate everything about Perl, it is still a vastly more human language than Applescript.

> Applescript should be used as the definition of a write-only language.

It’s the opposite. Applescript is a read-only language. Very difficult to write, but easy to read code that’s already done. Whereas Perl is easy(?) to write, difficult to read. So it’s a “write-only language”.

I agree 100%. Various attempts have been made to design "human readable" programming languages, where someone who wasn't familiar with the syntax (or with programming in general) might be able to read some code and get a sense of what it was doing.

I've heard that COBOL was designed with this goal in mind- make the syntax a little more verbose and English-like, and in theory nontechnical business people could understand what it was doing. AppleScript took this concept and ran with it.

The problem is that while this might (or might not) enhance readability, it definitely hurts writability. You end up with a verbose language with lots of extraneous and ambiguous syntax that isn't really well-defined. I've found AppleScript to be much more confusing than other languages, and if I wasn't a developer I would expect that to be 10x worse.

I have met a few people who said they got started with programming by playing with AppleScript, but I can't escape the feeling that they got into programming despite AppleScript, not because of it.

Maybe they picked it up first because it's always been pitched as a language for non-programmers, but it just doesn't seem to scale beyond something good for copying and pasting tiny chunks of code to tell an app to do something that otherwise can't be automated. It's useful as a tool to create and send Apple Events (which is really all it is- a wrapper around Apple Events), but its usefulness speaks more to the occasional usefulness of Apple Events as a part of the OS, than AppleScript itself as a language.

> AppleScript never was a programming language for developers

But, who is it for then? For general users they still made it too difficult to discover how to do things. Perhaps, the failing was simply with the documentation and discovery of the language.

Regardless, it's clearly been an area underinvested for quite some time.

Given that it was introduced 20 years ago on System 7 and has survived through Mac OS 8/9/X, it's kind of hard to address the audience question over that timespan. But I think it was always intended to be accessible to end users.

Personally, even as an experienced dev, I've found it hard to discover how to do things in AppleScript. The "natural" language can be surprisingly unintuitive sometimes, especially when it breaks down into a program that looks like half OOP / half NLP.

AppleScript was originally intended as a way for non-programmers to develop applications, hence the "natural language" syntax. You could think of it as the spiritual successor to HyperTalk / HyperCard. Aside from that, the language served an important purpose in classic Mac OS which lacked preemptive multitasking and thus true IPC. AppleScript was used to allow multiple applications to communicate with one another using a pub-sub model.
> The main problem is that AppleScript only appears to be a natural language. In fact [it] is an artificial language, like any other programming language. [E]ven small changes to the script may introduce subtle syntactic errors which baffle users. It is easy to read AppleScript, but quite hard to write it."

- AppleScript by William R. Cook (http://www.cs.utexas.edu/~wcook/Drafts/2006/ashopl.pdf)

My first programming language was Applescript and I have to say I agree. I'd spend most of my time coaxing the language of my code until the compiler could recognize its grammar. (Also, without an external application like UIElementInspector, just forget trying to figure out the incantations to properly manipulate windows and their buttons) The biggest strength of Applescript was the ability to pipe out to the shell for areas it sucked in. There are also a mountain of gotchas that newbies ha ve to watch out for: making sure the application has focus, escaping quotes properly, posix paths vs aliases, data types (text vs integer), and much more. I have to say the best parts of Applescript were the documentation (APIs exposed as "dictionaries" by each scriptable app), and being able to create "native" apps really easily as well as UIs/dialogs. (though with codesigning its utility to beginners is further reduced)

AppleScript is just an implementation detail. The power of scripting with MacOS has always been the underlying Apple Events. There have always been a number of languages that work on top of Apple Events to allow scripting.
I think Dijkstra's gonna get some comeuppance on this one when it comes to audible computing. What are spoken commands if not NLP one liners in a REPL?
They did this at the same time when Microsoft was localizing VBA. I still remember writing German VBA code which was horrible ("Wenn... Dann").

I think it was a good try but turned out to be not so great.

> It’s not clear whether the termination of Mr. Soghoian means the demise of AppleScript altogether

It's not? It's pretty clear to me…

Unfortunately the effectiveness of this argument is lost in the times. The author gets really caught up in metadata, bur we're in a year where Apple just wants you to subscribe to Apple Music and stop managing music files manually. To be clear, I'm not disagreeing with the author, just echoing why I think the argument wasn't effective.

|You see, it’s all about freedom. I think Apple would disagree with you
Scripting iTunes metadata made sense when Apple wasn't pushing a streaming service.
AppleScript is my first language. When I was 7 years old I learned a little bit of Logo, but I stopped using it. When I was 13, half my life ago, I taught myself AppleScript. Many of my scripts were for iTunes, but I also expanded to scripting my whole OS. I still use it daily.

If there are any comparable programs for Linux, I really want to know. I don't trust Apple's direction, and AppleScript is a killer feature tying me to this platform for now.

AppleScript just needs nice IDE with code snippets, etc. Script Editor is just a bit more than TextEdit and it's not enough.

It's interesting language, but it's not used widely, so when you have to use it, you need to remember syntax, etc, and that's much easier with good IDE. I doubt that I would be happier to use Python, because I used it once or twice in my life and I would google for every bit of language anyway.