but some time around 2005 or so, Apple the company stopped caring about these AppleScript and Automator, and let them languish, to the point where now, basically nothing is scriptable. HyperCard was also dead by this point.
so routes into end user programmer were dwindling
@beka_valentine a lot of people seem to believe this and I am not sure why. there have been big improvements to the applescript ecosystem, including fine-grained access control inter-app user-consent support added during the gradual tightening of security during the introduction of code signing and notifications. I regularly use applescript. apple’s first party applications still have scripting support, and the mac version of Shortcuts even has applescript actions
@beka_valentine applescript is under-marketed, perhaps, but it’s still right there in macOS I strongly suspect that there is a big element of revealed preference here. users programmed out of necessity but they always kind of hated it; while Apple makes their apps scriptable, relatively few third party developers do, for the same reason that APIs have been falling out of fashion generally. shout out to the ones that make it a headline feature though, such as the Omni Group
@beka_valentine I still use this stuff quite a lot, despite being warned off of it in the early 2010s because if was “all going away soon”. it’s been a solid 15 years of it all continuing to work perfectly well for me. I try to convince others to use it as well, but even other programmers mostly just ignore it since it’s kind of alien to the way programming works on the web now, and that’s most programming
Adding AppleScript to an app used to be quite clunky. There were a bunch of classes encapsulating AppleScript verbs and so on that you had to wire up. About ten years ago, they added some reflection-based things that let you just expose an Objective-C class as a scripting interface. They also did the converse and made it easy to use AppleScript interfaces from Objective-C, which made it easy for one app to drive another without needing to embed AppleScript code as text that Objective-C code would then pass to another parser.
@david_chisnall @beka_valentine I have, admittedly, yet to make an app scriptable myself, so I am not sure how hard it would be, particularly in Python; I should definitely get around to that. I do wonder if this stuff exists in Swift?
@david_chisnall @glyph @beka_valentine
I recently learned Chrome has AppleScript support, and was disappointed that it doesn't seem to support anything similar on Windows.
I think if you expose IDispatch COM objects you can probably build something similar, but of course I'm sure it's a huge pain of fighting with legacy technology.
@KevinOfComputer @glyph @beka_valentine
Windows DCOM is closer to Distributed Objects in the NeXT world. I think one of the largest mistakes Apple made with OS X was not reimplementing AppleScript over DO, which means that you have two completely unrelated ways of vending an object to external users (three once they introduced XPC) in the core system abstractions.
I did some prototyping ages ago in GNUstep with the tooling I wrote for writing scripting languages that shared an object model with ObjC and using DO as a building block for scripting. It worked quite nicely at the time.
I think most of the Objective-C stuff is bridged in Swift, but I’ve never tried using Swift seriously. And SwiftUI is such a huge step backwards that it’s hard to take the ecosystem seriously.
@beka_valentine anyway it does feel like the magic is going away but it is still worth learning; both because it still works and can solve actual problems, and also because it would be good to learn lessons from it while it is still a living system and not just retrocomputing
