When AppleScript and Apple Events were first introduced, in an update to System 7, they were revolutionary. Prior to their introduction, numerous developers were working on their own scripting systems and languages for their applications.
AppleScript and Apple Events made two advances possible. First, that the English-like scripting language, based on HyperTalk, was accessible to non-programmers, and second, most important, that any developer could fully implement an automated interface using scripting that made their applications compatible with any other AppleScriptable application.
Once I learned AppleScript, one of my first scripts would extract data from a Microsoft word file, open a Quark Express document, and based on the specification extracted from Word, add pages, text boxes and image boxes. It would then download a tagged text file from a vendor’s FTP server, import the tagged text. From there it would download a set of images, from an inhouse server, import them onto the image boxes on the appropriate page, open the images in Photoshop and scale the image files to fit the image box, and extract captions and credit info and populate the caption boxes on the page. The user would look through the document, and, if needed, make minor adjustment to the images and captions and credits, then another script would preflight the document before generating a PDF, sending that to a printer for a proof, and uploading it to a server at the printing company.
In those days (and to this day), Microsoft, Adobe and Quark were fierce competitors and didn’t think too highly of Apple either.
But, with AppleScript and Apple Events, a non-programmer like me could build a rock-solid workflow. I could not have done that had I had to learn three or four different scripting languages. Before this interapplication automation was possible, a user would spend two to three hours producing each document. As a result, we were able to produce dozens of publications (TV booklets each carrying listings for the specific cable availability in various neighborhoods) at no additional production cost.
Plus, for those who didn’t like the AppleScript language, Apple bent over backwards to make the Apple Event architecture accessible to other scripting languages (like Frontier) and to make other scripting languages accessible to Apple Events and AppleScript.
That same script that I wrote over 20 years ago would still work today on the latest versions of all those apps with only minor changes (including switching out Quark for inDesign).
None of those alternate scripting languages that Apple facilitated with the Open Scripting Architecture ever took off on the platform the way the AppleScript language did.
For all their flaws and frustrations, Apple Events and AppleScript are still the best system available on any platform for interapplication automation, scripting multiple applications from different developers.
People have been predicting the demise of appleScript ever since it’s birth, really, yet some how, it’s still there, still robust and supported.
Hey Folks,
A Mac without Applescript (or more specifically a sufficiently robust form of automation) is about as useful as a balsa wood boat anchor.
-ccs
It’s 2022. Apple makes hypersonic luxury scramjets. What on earth would it still want a boat anchor for?
Eek… That’ll really chap @hhas01’s ass, since he’s written a lot of words in this thread explaining that Apple may, indeed, sell Mac computers, but that’s not its purpose. Macs are a means to end: something to rope in and tie down developers to the Apple ecosystem so they’ll churn out products for their iOS platforms.
Personally, I resent iOS. 15 versions later and the home screen still scrolls horizontally, and doesnt give the option of sorting apps alphabetically. It’s all very communist.
I know nobody asked, but here is my take on AppleScript’s future
The Problem
AppleScript has been in a state of benign neglect for a very long time. However, I feel the real problem is the erosion of the scriptable applications available for use with AppleScript. The introduction of Shortcuts for macOS and Apple’s evangelizing developers to provide Shortcuts integration in their applications is accelerating this trend.
AppleScript is only compelling because it allows us to exploit the power of object model scriptable applications. On its own AppleScript is an awful programming language.
Apple’s Role
Apple is neither good nor bad in this situation. They aren’t killing AppleScript for some devious reason. They are responding to their perception of the need for automation across iOS and macOS in an ever more security conscious world.
Apple in the end is a hardware company, and lately a services company, and they will do what they think is best to drive sales of devices and services they offer. It’s really that simple.
And never forget we are in an iOS first world now. macOS certainly matters to Apple as it represents a multi-billion dollar business, but its far smaller than iOS.
The Audiophile Simile
For those of you who feel that AppleScript is a killer feature of macOS that must be preserved, I think you are missing the forest for a tree.
I’m a life-long audiophile (yes, one of those crazy ones 
). I love the way a great hi-fi lets me engage deeply and critically with music. But the thing is, few people see music in this way. Sure, music is an important element of many people’s lives, but the way its presented does not matter so much. Other considerations like convenience and suitability to location (car, night club, gym, etc.) matter much more.
As a simple example, take the Bluetooth wireless earbud. Bluetooth robs music of a lot of its life but it just doesn’t matter. The convenience and usability of these devices vastly outweighs the consequences to the music.
Audiophiles have this inflated sense of their importance to the music industry. The truth is we represent <1% of the music buying public. Our needs and desires simply don’t matter to the powers that be in the music industry and even to many musicians.
I think AppleScript is sort of like this. Those who have discovered the power AppleScript provides (once it has been learned and tamed) think everyone is like them, or convertible into people like them. But the truth is that the vast majority of people are happy with the manual processes they have and understand and can’t imagine a world where they can bend the systems they use to their will. The tedium and errors involved in manually processing information over and over is just the way it is.
What’s Happening To AppleScript
As the number of good scriptable object model application declines, AppleScript becomes more and more irrelevant. Sure we can resort to ASObjC, UI scripting and other techniques to overcome the limitations of some applications, but we need well implemented scriptable object model applications. Other approaches are fragile and cumbersome and slow.
Secondarily, AppleScript its self is frozen in amber. Because it’s not being actively developed it is not benefiting from tools and technologies that are present in other programming languages. Sure, we can use ASObjC to bring Foundation capabilities into AppleScript, but I think many of these things should be part of the language. For instance, NSArray and NSDictionary should be first class citizens within AppleScript, replacing the existing list and record implementations. AppleScript should have first-class Unicode string handling based on NSString. Ideas from Swift (closures, etc.), Python and other languages should be adopted where they make sense. I could go on and on.
As I say above, if you take away AppleScript’s ability to control other applications, you are left with a terrible programming language.
Internet Services
A lot of the services that were central to AppleScript’s success in the early years have moved to the web and become language agnostic. The Mac and AppleScript are no longer central to the deployment of large-scale automations.
What’s Happening With Shortcuts?
Here is where the greatest danger to AppleScript lies. It’s not Shortcuts its self, but the SIRI Intent API that Shortcuts uses to interact with applications that represents the greatest threat to AppleScript. This API is not an object model API. It is, in essence, a remote procedure call. Developers have to define their own set of verbs and their own means of addressing information within their applications. Some do this well, but the vast majority offer limited access to the information within their applications.
Next, Apple has made the SIRI Intent API cross platform. A developer can expose their automation interface once, and exploit it on iOS and macOS.
I regularly see developers talking about how the SIRI Intent API is so much simpler to adopt than Cocoa Scripting (the tool developers use to expose their AppleEvent Object Model interface to AppleScript), and how they can deploy on all of Apple’s platforms. They are choosing to only adopt the SIRI Intent API. This is bad for us and it’s happening more and more!
What is the Future We want?
I want a future where multiple automation systems (some textual, some graphical, and others) are peers and can interact with as many applications as possible in a secure fashion. I don’t think AppleScript is going to drive this future. I don’t think Shortcuts will either in the long run. But if the platform encourages it, someone is going to devise something really amazing we’ve not yet thought of.
What we really need is an Automation API
I feel that we need to urge Apple to define an automation API that many automation systems can exploit. This means a well defined and structured interface for applications to expose their automation interfaces. This also means a published means of discovering, introspecting and calling an application’s automation API.
Apple’s Shortcuts could be the AAA title that uses this infrastructure, but there could be other offerings as well. Even AppleScript might be transitioned to this if there is a will to do it within Apple (I’m not holding my breath).
Heh. Do not fear. I am mostly switched to sending words off-list now. That way only one poor devil gets crushed by The Wall of Noise, not all.
Perfectly put, and short! Say, d’you want the job as executive editor? Hours crap, pay non-existent, yada-yada… 
Not “communist”, good intelligent capitalism! Apple looked at what everyone else in the world was doing, then did what weren’t. e.g. Microsoft succeeds because it aims to please every single customer that comes along: thus their products are huge, unwieldy, and can do every single thing you could ever want, plus a million more things that you personally don’t. Everybody uses Microsoft products, but nobody really loves them: they’re too compromised for that.
The closest MS gets to an “Apple product” is Xbox. Everything else they sell is just kitchen sinks, lashed together, forever.
Apple’s tactic, upon retaking “personal computing” was radically different. Apple does not want to please everyone. Apple wants to please a large profitable majority whose needs and wants are broadly similar. Apple can then make a product that targets just those customers, and that product smashes all competitors when it fits those customers like a silk glove.
What’s funniest is when said competitors do not see this: after all, wearing welly boots on one’s hands keeps those hands dry and warm too, and this has always worked for them; so why is everyone raving about Apple’s product, and buying it hand over fist.
This is what Apple did to the mobile MP3 player market. It wasn’t the first player into it. But it was the only player that mattered. iPod changed the world… and iPod wasn’t even a product that Apple was interested in making. It was just something they did in as part of laying their brand new 16-lane freeway to the future; a motorway all of whose tollbooths they’d own.
Steve Jobs 2.0’s Apple 2.0 should be mandatory teaching in every business school in the world. It’s why I don’t buy the whole “one person can’t make a difference” schtick, to which people who don’t make a difference often retreat. One person can; they just need to do their damn homework first.
…
Coming back to Apple and its customers: Customers who do not fit smoothly into the tight-fitting mould that is an Apple Product™, Apple does not want them at all!
Like I said before, one of the first lessons of effective business is learning to Fire Your Own Customers! If one customer consumes 10% of your resources, that customer had better be generating 25% of your income to justify such drain.
And even if that customer does generate 25% of revenue, if firing that customer allows you to recruit 100 new customers, each of which consumes only 0.1% of your resources, then do it—as soon as you are able! Not just to make more money in total, but also because it spreads your own exposure to risk. Many a small B2B, upon landing its first large client, has crashed and burned a couple years later—when that client ups takes its custom elsewhere. That customer was massive to them, maybe 50% of their income… but they were tiny to that customer.
BTW, this is exactly what killed my first startup: Desperately trying to please our first customer when we should have fired them instead! It was the very first customer we had successfully landed, and we were rightly chuffed. But they sucked up all our resources, ran us in circles, paid us pennies for the privilege, and played us for the fools that we were—because we let them.† Good for them! We should’ve taken that priceless lesson early, promptly sacked them, gone back out into the market and invested every ounce of our energies into successfully landing customers #2, #3, & #4. We didn’t, because we couldn’t see past our own noses.
That’s what Good Apple does. Tim’s Apple is Mediocre Apple, which means that wallowing stagnant markets now regularly get left to wallow stagnantly for years—Hello again, Mac Trashcan Pro!—but eventually even Tim’s board drops the ax, after they can’t hear it generating money enough.
Folks here talk about how important AppleScript is to them, and how they can’t even imagine life without it. Yes, I get that. Y’all are looking at it backwards. See it from Apple’s perspective: How important is AppleScript to Apple. And how does Apple imagine life without it?
The answers to both are already in. I see them, Mark sees them (Hi, Mark!), Apple sees well beyond them already. If you don’t see them, that is only because you do not wish to. Thus all consequences of such willful blindness are your error, and yours alone.
Apple will do what is right for Apple. If you do not fit into Apple’s carefully curated market demographic, then driving you off to go be a boat anchor to Microsoft of whoever is daft and/or specialized enough to actually want you is the best business decision Apple can make. Your growing resentment of Apple’s design decisions becomes a self-resolving problem. You are not the Customer they want, so the sooner you flounce the better! That is all.
With apologies for length, as ever,
has
–
† This wasn’t by accident either. After they completely won, as a kindness they even explained to us the real game they were playing. The card sharp explaining his tricks to his mark as part of his victory lap. Well Played indeed!
Hi Mark,
Honestly, mate, I’d been holding off emailing you directly to recommend you quietly disappear this thread as being not conducive to good LNS business.
Trust me though, I’ve been hoping for years you might break your (sensible) silence, throw caution to wind, and dive right in in full public view—Cannonball!
You are, of course, 100% on the nose in everything you just said, and so much more concise than me too!
(Say, do you want job as executive editor; long hours, no pay, yada-yada, etc?;))
…
Re. “Automation API”. 100%.
You can forget urging Apple to do it, of course. Apple already knows exactly what it’s doing, and why it’s doing it. App Intents only needs to satisfy the 98.999% of Apple customers, who don’t need a Rolls Royce of Automation; they just need something that makes Siri Automation marginally more useful than a box of rocks. It only needs to be 1% as technically powerful as AppleScript. Because its reach is a million times longer!
App Extensions + Intents fully satisfies Apple’s need—albeit in the most overwrought, least efficient, and least expandable/reusable way they could have come up with. All the power-to-weight ratio of a house brick. Apple doesn’t care. Its millions of App developers don’t care. They can afford to brute-force it. It is, to them, the obvious, Right Solution.
Not only that, “brute-forcing” it is pretty much the only problem-solving strategy that they know! “Hit it with a rock!” Doesn’t work? “Hit it harder!”
An elegant powerful alternate strategy wich is open and accessible for anyone to use, and which is not only accessible to programmers and non-programmers alike but even achieves a superior result, is actually a THREAT to their domination!
Hence programmers are not only their own worst enemies, they are ours too. They make everything Hard that they touch. But that doesn’t matter to them; they’ve already won their game so can write all its rules. The status quo serves them. Why on earth would they change it? Why on earth would they want to?
Why? See: Microsoft.
Microsoft owned Personal Computing for 15 years. And then, without warning, Microsoft lost Personal Computing overnight!
Steve Jobs didn’t destroy MS by building a better PC. He knew that game was already lost, 15 years ago. So he reinvented the game—the very definition of what a “Personal Computer” was—and then he sold that Personal Computer to everyone.
A Supercomputer in every Pocket! Think Different… indeed.
This is the lesson that anyone who wishes to save AppleScript and Mac Automation must first absorb.
Mac Automation is Already Dead; Long Live Siri Automation!
…
The question now is: How do we get our grubby little hooks into that? To (borrowing from Ray Kroc) let Apple have it the way that we want?
Technologically, our target has to be Siri and iOS. That’s non-negotiable. Fortunately, Apple has left us two ins:
-
SwiftUI.
-
Shortcuts.
These are the two prongs of our attack.
Prong #1:
SwiftUI is a View toolkit in a Model-View world. For those who understand GUI app architectures: the Model layer is where the user’s data is internally stored, managed, and manipulated. The “brains” of the App. The View layer is a “skin”, stretched across that Model to make that data visible to the external world (the user) in some shape and form.
An App has one Model. Normally it has one View. That View, for a desktop/mobile app, is inevitably a GUI. However, a View may also be a Command-Line Interface, or a Web Interface, or a Voice Interface, … or really any Interface of which the App developer can conceive, and for which there is a market that wants it. (This is true even if the market itself doesn’t yet realize it wants it!)
What “AppleScript” did, and a lot of programmers don’t even get this, is add a second View to Mac apps, one that sits adjacent to the app’s traditional GUI View, providing an separate, fully independent, second view into that Model data. The difference to the GUI view, which allows humans to access that data via point and click, is that this “AppleScript” view allows other programs to access that data by sending Apple events: program-to-program commands.
I drew some pics illustrating this architecture way back when:
https://appscript.sourceforge.io/py-appscript/doc_3x/appscript-manual/02_aboutappscripting.html
Old, but hopefully they convey the point.
That there are many programmers who even today think AppleScripting is all about manipulating a GUI app via its GUI. That just goes to show the productive vs destructive power of good documentation vs bad/non-existent documentation. Just about every programmer on the planet grossly MIS-understands how Apple events works. I won’t go into that again in detail—folks can find my previous dissections if they want. The short version is:
Apple event IPC is Commands plus Queries.
This is Huge. And I don’t just mean a huge PITA, although it is that too.
Queries is huge, because Siri itself is a Query-Building engine.
And the Apple Event Object Model, which is what scriptable apps expose to Apple events, is a Query-Handling engine.
…
Implementing a high-quality, fast, capable, robust Apple Event Object Model is Hard. Really Hard. That is why programmers don’t much like it: it is a huge amount of work for them; a feature cost they can only justify if adding that feature is guaranteed to win their App tons of new users.
Outside of a very few pro apps—Adobe Photoshop and InDesign being the canonical case—adding an AEOM to an App is a pure money pit for that developer. Their own money goes in, no value to them comes out.
Very occasionally you get a vendor like Omni who adds it anyway, and really goes all out to polish it to the max, purely because they personally love using this technology themselves. But those developers can be counted on one hand: they’re the same programmers who don’t instantly despise AppleScript but instead accept it for what it is—a massively flawed, programmer-hostile language that nevertheless holds all the Keys to the Magic Kingdom.
That is the market that Apple’s Scripting Bridge and later JXA were meant to open up, making a million App developers fall in love with Mac Automation by giving them a product made just for them.
I have already iterated all the ways in which Sal and his team—and me, independently—completely destroyed this market instead. Without App developers who add Mac Automation support out of the love of it, it leaves only developers who add it because they make far more money by adding it than adding it costs. Which is, again, the number of developers I can count on one hand: Adobe (huge, obvious), Microsoft (arguably), FileMaker (really a non-entity)… that’s it.
Adobe has already declared that its Automation future is UXP. Even if it Adobe wasn’t moving to UXP, Adobe’s AppleScript support is nowhere significant enough to keep AppleScript alive. AppleScript may be a huge deal to a small number of Adobe users. Adobe users are small beans to Apple: the only ones that matter at all are iOS game devs, and I doubt any of those even use AppleScript automation at all.
…
So, back to the Apple Event Object Model and SwiftUI. What SwiftUI is is a brand new View toolkit for building cross-platform GUIs, which work across all iOS devices as well as on macOS too. Part of what SwiftUI does is define how an App’s Model layer exposes all its data for SwiftUI to get, set, and generally manipulate. Do you see where I’m going yet?
Accept SwiftUI is the future. Make it the future. Don’t even think about anything else. Solve this one problem alone, and do it fast, because time is running out.
Build a new Apple Event Object Model framework that sits on top of a SwiftUI-based app’s Model APIs, and talks to those Model APIs just as the SwiftUI framework already does.
macOS’s Cocoa Scripting framework, which is what Cocoa apps used to provide “AppleScript” support, never quite worked. Cocoa’s Cocoa Bindings, which is what Cocoa apps used to connect their GUI Views to their Models, never quite worked either. Apple missed two great tricks there: they could have fixed both CS and CB by redefining their problems in its most general form—What is the “language” that we need to create to enable any View to talk to any Model?—and then solving that.
…
Note: When I say “language” I don’t mean a programming language specifically; it can be anything and/or any combination: a messaging protocol, an Interface Guidelines document, a software library/framework of building-block code, etc. And it could even be a programming language: there is a sub-category called Domain-Specific Languages, which are languages designed to do one highly specialized job, and only that job, and do that job infinitely better than any general-purpose language ever can. Because a general-purpose lang has to try to please everyone by doing all things equally well (i.e. mediocre), whereas a DSL does one thing exceptionally well—precisely because the DSL can leave out all of the features it does not use, which means it is not compromised as the general language is.
BTW, guess who spent the last 15 years learning how to build DSLs, and in so doing successfully cracked a Hard technical problem that industry giants such as Kallik, Esko, and Adobe themselves have hardly managed to scratch?
Right.
BTW, what does honk me off about SwiftUI is it actually pretends to be a DSL, but it isn’t: it’s just syntactic sugar slopped all over Swift itself, till the user (i.e. Swift dev) cannot even see what it’s doing any more.
Sound familiar? Right again.
However, it is what it is.
…
If you want to save Mac Automation, you have to build a new AEOM framework that sits as a full peer to SwiftUI, talks to the same Model objects via [as much as possible] the same commands as SwiftUI, and thus can be added to any SwiftUI app by any Swift developer for minimal additional work.
Again, this is the first prong of a two-prong attack. Lowering cost of access for App developers, so that it’s cheap enough for them to add AEOM support as a feature, and not have to care whether it attracts loads of paying users or not. “Sufficiently cheap to add” is ameliorated to “free, costs me nothing” over time.
…
That is everyone’s first job. Solving the “server-side” challenge.
Luckily, 1. prior art exists from which to learn (and copy where it works), and 2. I have made a bit of a start.
We will call this one “SwiftAutomation”. Of course.
Prong 2? Later.
(I need to go spend today doing proper work: polishing my new automated AppleScript-to-JavaScript script translator, readying it to begin production testing this month. Much as I care for the future of Mac Automation, hard life priorities must. I gotta pay my bills too!)
So a few followup thoughts on Prong 1 before Prong 2:
People I would suggest approaching to build a new AEOM framework to complement SwiftUI:
-
Steve Troughton Smith – figured out a couple years back how to put AppleScript support into a Catalyst app, which points to him caring about it.
-
Mark Alldritt, obviously – implemented the AEOM for Adobe Illustrator, so understands the giant PITA it is and isn’t afraid to dig in and get dirty.
-
Wil Shipley – a third pair of eyes, also cares about automation.
As for pitching it to Apple, while it’s not possible for unrelated apps to talk to each other, it is possible for related apps (by the same vendor) to do so. Thus the two people you might want to haul aboard once you’ve got something working:
-
Simon Støvring – author of Scriptable, which is a JavaScriptCore code editor on iOS with a good emphasis on IPC
-
Gus Mueller – author of various productivity tools with scripting support
Get those guys to put custom builds of their apps into a single application group so they can talk to each other, and you can demo a live working “application scripting” system on iPadOS.
Obvious caveat there is that Gus’ productivity apps probably aren’t SwiftUI, and Simon’s editor might be ObjC rather than Swift. You may want/need to shop further.
Any AEOM framework that presents an “object model” (it isn’t really; it’s just an abstraction to throw queries at) needs to make some deference to the RPC of App Extensions and App Intents. And Apple events is itself RPC, so there should be a degree of commonality there; it’s just that AEs have some extra datatypes for building first-class query values, in addition to the usual number, string, list, etc datatypes that any self-respecting RPC API has. So the pitch itself is probably somewhat sneaky and roundabout: “it’s just the addition of a query type to AE/AI’s existing RPC”, then “let’s standardize AE/AI’s giant bag of completely arbitrary, not very composable command verbs to a small number of generic get/set/make/move/duplicate/delete/etc verbs so they’re more reusable”, and finally “gee, this looks kinda like an AEOM now, doesn’t it…”
Any new AEOM framework will live or die by the quality of its IDL—Interface Definition Language. AETE and SDEF were never IDLs (despite SB & JXA trying to use them as one; part of why they sucked technically). The IDL needs to be able to express revolutionary concepts (/s) such as generic types (so that a command’s argument and result types are fully, unambiguously documented), permissions groups (which SDEF does have, based on UTIs), and intents (which is the glue that helps Siri close the gap between what the user wants to express to what the program needs them to say). Basically, the more it looks like Apple’s own ideas, the easier sell it will be.
BTW, I’m strongly +1 for defining IDL as a DSL, as opposed the current mess of Swift type system, XML SDEF, Xcode WYSIWYG form, and the rest of the inchoate mess that Apple puts up. The DSL should not only describe the scripting UI, it should produce the glue code that binds it to the app Model (comparable to what Cocoa Scripting does with SDEFs and what Cocoa Bindings does with its awful Interface Builder UI; both translating to lots of KVO magic and stuff), it should generate all the user-readable docs and Siri request-response gubbins that helps users put together working requests too. (e.g. My kiwi language does this a lot.)
i.e. The more different tasks that one piece of code can do, the more cost-effective writing that code is for the developer, even if its language is a new domain-specific one they have to learn first. Design the “ideal” language first, then implement the framework to “run” it, then make any compromises to the language to get it out the door, then dogfood the hell out of it with your tame App developers until it stops stinking. You now have something that probably several times better than Apple can produce, and quicker too. That’s the benefit of “roll up your sleeves and do the job yourself”: you can’t just blow off yourself with half-baked pap and pretend it’s done well—you keep going until it actually works for you.
Anyway, onto Prong 2…
What Mark wrote about remaking AppleScript is wrong. From a technical perspective: Replacing/Reimplementing AS datatypes such as string and list atop NSString and NSMutableArray would actually be a backward step. NSString is actually worse at speaking Unicode than AS’s native string type (NSString is UCS-2 internally, which betrays its age and clunkiness). And, of course, Cocoa is itself on its way out now, clobbered by C++ mark 2, aka Apple’s Swift language. Swift is not the best choice, it is the only choice. Any scripting language MUST be 100% implemented in, and 100% interfaceable with Swift, to sell it to Apple. We’re trying to sell them the future, not two pasts they’re already abandoned.
And, in any case, updating AppleScript does not change that its core design is deeply, irrepairably flawed. The obfuscated syntax alone, with its arbitrary keyword injection and magical hidden behaviors under that surface, is a pedagogical disaster. This is why I keep saying: the technology (which is what everyone else obsesses on) is the least important part of the product. The most important part is the market, and AppleScript has proved it cannot build market to save itself, not even amongst the programming geeks for whom Mac Automation should be an irresistable product.
AppleScript has to die. It is broken, exhausted, and entirely unwanted by the world; the wrong tool for the job. We have to throw something under the bus, to reassure the folks at Apple that their decision to abandon AppleScript is absolutely the right one. We try telling them they’re wrong, and sayonara, all of Mac Automation. Most folks don’t like being told they’re wrong, even when they are. Doubly so when they’ve already bet their career.
Furthermore, our goal is not a new AppleScript. Siri is the only Automation product Apple cares about. And Siri already has Shortcuts. Whatever we sell has to build on, and improve, Shortcuts.
So what has Shortcuts not got?
Mark Alldritt, again, with just one slight amend:
I want a future where multiple automation interfaces (some textual, some graphical, and others) are peers and can interact with as many applications as possible in a secure fashion.
Mark had said “systems”. Forget “systems”. Automation is People. Users, by and for. Users want interfaces, not systems, to talk to—no, to talk with—their devices.
Shortcuts has got exactly ONE user interface. Which is really good at presenting a single, simple, visual form. That’s Graphical. It’s attempting to bolt a second interface, Voice, onto it, which is what intents are for. The third obvious interface would be Text.
And we’ve just been talking about how a single App can have more than one View onto the world, so we know it is 100% possible and also often highly desirable to have this arrangement: a choice of tools—in this case UIs—so that a user can select the best tool to perform her particular job.
Shortcuts treats text as if it were the Devil’s Work. No words for you!
Not even when a few typed words would express the user’s intentions ten times quicker and more naturally than GUI drag-n-drop. Seriously, look at math; and even simple parameterized commands: Shortcuts quickly gets in the way of itself. An exercise in growing frustration that users tolerate only either because they enjoy playing challenging games, or because alternative choices are zilch.
Why? Because Shortcuts’ authors figured out that non-programmers cannot use programmers’ text languages, but that non-programmers are able to use GUIs. So they conclude what non-programmers need is a GUI. Because GUI programming is what today’s object-oriented App programmers know. I don’t know if it even occurred to Ari &co that a programming language is what they were actually making. (See also: Greenspun’s Tenth Rule.)
The result is Shortcuts: A visual programming language that has all the complexity and unnaturallness of a traditional text-based programmer language, but in colorful GUI block form. Problem solved? Umm…
This is not a new idea: WorkflowHQ freely admitted they took the idea from Apple’s Automator; and there are plenty of other examples: MIT Scratch, MATLAB, various dataflow languages for graphics and audio pipelines, and so on.
Now contrast Papert’s LOGO language, a text-based language created in the 1960’s (when Teletypes ruled the world!), that was so simple an 8 year-old child could learn it. Even I can explain Logo concisely:
-
This is a Word.
-
This is how you Do a word.
-
And this is how you Add words of your Own.
That’s it. That’s the whole language. The rest is just a dictionary of all the words that Logo already understands:
move forward
move backward
turn left
turn right
pen up
pen down
and so on; basic building blocks of sentences. To perform a more complex action, the user composes those words into a sequence:
Move forward 100, turn left 90, move forward 100, turn left 90,
move forward 100, turn left 90, move forward 100, turn left 90.
(That’s not true Logo syntax, btw. That’s entoli, which was my first prototype for an AS successor. Allows whitespace within words… seems familiar. A little easier to read; the intent is identical though.)
As the user begins to tire of repetitive typing, they might discover some additional words to be useful:
repeat 4 [ move forward 100, turn left 90 ]
The real insight comes from discovering one built-in word, to, which is the word that enables a user to define new words of her own:
to square
repeat 4 [ move forward 100, turn left 90 ]
end
This to word is so important it even has a special syntax all of its own, to facilitate easy use:
to NAME
…
end
None of the other words in Logo has special syntax; not if, repeat, or any others. They don’t need it; more importantly they don’t deserve it!
The most important words in a Logo program are not Logo’s built-in words. They are the words the user adds for her own use—to describe the ideas and behaviors most important to her! The user crafts her own vocabulary, each word a building block she made to describe one part of her problem, which she then composes into new and more powerful building blocks, and so on, until she has grown her own custom language for expressing her problems in their own terms, and she assembles her own solutions using that.
This compositional constructionism, BTW, is the part that is not intuitive. It has to be taught. Which is why 8 year-olds: because that is the age that young kids begin to develop the capacity for true abstract thought. Which enables analytical problem-solving, and the sort of self-directed world-building towards a pre-chosen objective, that is the key to unlocking all this self-enabling power.
Logo gets straight down to business: provides its users the essential toolkit (1. words, and how to 2. perform, and 3. compose, them), a little 3rd-party training on how to wield those three tools effectively, then gets the hell out of its users’ way.
How many pages to explain the AppleScript language to the same depth? Freaking hundreds. The syntactic special forms alone run into dozens; and, worse, emphasize all the least important parts of a user’s program!
When I finished rewriting Learn AppleScript, 3rd edition, I wasn’t proud of the size of the beast; I was appalled. Five hundred pages on the language alone. And, even allowing for my own logorrhea, the job can’t be done in less than a hundred.
Yet at the same time I was writing about AppleScript, I was writing the first version of the language that’d eventually become kiwi. It’s a little more complicated than Logo syntactically, as Logo has one Key Concept—commands—whereas kiwi has two: tags and rules. Even so, kiwi is explainable in a fraction of the words AppleScript is, and also allows skilled users—in its case Adobe Illustrator artists—to compose advanced automations with no programming knowledge at all.
Those videos I showed before. All but one were built by an experienced artworker, with just a little technical backup from myself (composing new rules for that artist on request).
You can read Papert’s Mindstorms for free online, or buy a 2nd-hand paperback no problem. It costs you only your time; and it is time very well-spent. (Ignore its sequel, “The Children’s Machine”, which is drivel. Just Papert whinging how School failed to buy his—legitimately amazing—product, never understanding that it was his own inadequate sales skills that failed it.)
Another book to read: Bonnie A Nardi’s A Small Matter of Programming. (Hardcopies are impossible to find, so that’s an iBook link.) A little thin overall, but the chapter on collaborative working practices is pure gold; and my own kiwi work confirms that model.
Those are the two books that anyone who wishes to solve Apple’s Automation Accessibility Problem needs to go read for themselves, right now.
The accessibility problem is not text; it never was. Humans have been using text successfully for 10,000 years—our entire civilizations built on it!
Text is the most powerful and empowering tool humans have ever created: the tool we use to encapsulate all of our acquired knowledge and understanding into reusable, shareable, re-executable, and ever-improvable form.
The problem with text-based programming is that, with exception of Logo, all of its languages are designed by Programmers! Self-referencing, inexpressive, stodgy, dull, unimaginative, given to martenism and control freakery. Whose only actual expertise in life is knowing how to turn it off and on again. Thus a User who does not already think and speak as a Programmer thinks and speaks now has precisely two choices:
-
Learn to talk Programmer-ese, and become one of them; or
-
Walk away, save herself the pain, and surrender all that power to them.
The problem with your typical programmer today is the problem we’ve had for them for the last 40 years: they position themselves as the world’s great problem solvers, but haven’t the slightest bit of interest in learning or doing anything that isn’t about writing code. Need an accountancy software? Find a programmer who understands accounting first. GLWT.
My first professional automator job, I worked four years out on the shop floor amongst a bunch of artworkers. It was great! They brought me artworking problems, and I learned from them how they currently did it until I understood enough about them, their jobs, and why they did things the way that they did (and why they did not do them other ways), and then I encoded that understanding in software, which they then kicked the tar out of in test and production, and together we iterated towards solutions that solved their problems, correctly. There were two of us full-time automators, working out of the IT department.
The same place had a large Application Development department, maybe 20 people. In all my time there, I saw their developers step out of their glass-walled enclave to wander the shop floor, talking to their own front-line users, learning how those users were getting on, exactly… LOL. Nope. Artworkers loved IT-built automations; steamed at theirs.
All of this comes right back to what I’ve been saying (badly!) from the start:
If the Users here desire an Automation platform that works for them—that isn’t just some programmer’s summary opinion of what we deserve—then there’s no point us whining at Apple to make it: We have to build it by and for ourselves! Apple’s Real Programmers™ aren’t going to do it for us; they can’t. That means us, knuckling down, doing all the fundamental learning that they skipped right past as “not important [to them]”, building, trying, throwing out, and redoing until we crack the problem first.
This is the key to delivering the technical part. Once you’ve got that, you’ve still got the challenge of selling it into Apple, to people who might well interpret your move as a danger rather than a gift. But at least it’s a start.
And, 90% of that work already exists, if in raw form. Prior art, dating back 40-odd years. Pedagogical research done in the 60s and 70s. I can trust in Papert’s constructionism, and Nardi’s tiered learning and support practices, because kiwi already tested the principle and found it to work in the small: artworkers tagging artwork templates for kiwi’s automation engine to consume. The trick is converting all that disparate experience into focused directed work, and doing it quickly too.
Which brings us, finally, to iris-script itself, which is quite obviously SiriTalk by a temporary, non-infringing name. Technically not an xTalk language, but it’s the intention that counts, and the xTalks were intended to open programming to non-programmers.
Here is that SiriTalk code example again:
tell com.apple.TextEdit to do
make new: #document at: end of documents with_properties: {name: “Test”, text: “hello again!”}
get text of every document
done➞ [“hello again!”]
SiriTalk is not a replacement to AppleScript. SiriTalk is the replacement for all of Siri Shortcuts’ XML-based backend bullshit!
More on that in a moment. For now, revel in the agony that is Siri Shortcuts’s user-to-user pedagogical experience:
Screenshots. Opaque URLs. Actual written text descriptions. Absolute impenetrable, human-hostile, farce.
Because Real Programmers think text is “too hard” for all us Users. Because we can’t understand their text languages. It never even occurs to them there might be more than one reason for that. Or if it does, they won’t admit it: their languages suck for human users; so what does that say about them? Right.
Now here’s the thing about SiriTalk: It only has one Key Concept to learn:
Everything is a Command.
There are no statements. tell is just a command. 1 + 2 is a command. 1 + 2 × 3 is two commands, nested.
Now there is a little bit of syntactic sugar here being added on top:
1 + 2 × 3
is, when expressed in ST’s native tongue:
+ {1, * {2, 3}}
which, if this were an Algol language, would be:
add(1, multiply(2, 3))
and, in a Lisp, which is what ST really derives from:
(+ 1 (* 2 3))
Same with the tell example, where tell is a command:
tell {target: ..., action: ...}
As any Lisper will tell you, machine-reading Lisp code is comically trivial, because every Lisp program is just Lisp data: a list [of lists, of lists, …]. An ST program isn’t quite as minimalist: whereas Lisp lists do double duty, representing either a list of command name plus arguments OR a list of arbitrary values, ST defines two discrete datatypes: command and list. This eliminates any ambiguity—syntax makes clear what you are looking at. However, both are values, first-class datatypes, so an ST program is also 100% data. By the way, this also includes metadata: comments, TODOs, user documentation, and so on, which are part of a program’s data structure as well.
Which brings us to ST’s great trick: because every program is a series of commands, it is trivial to map a sequence of commands to and from Shortcuts’ grapical representation as and when and as much (or little) as you wish. All that App Intents stuff Apple is overengineering for App Extensions, ST can give you for free. This is true whether you’re writing the handler for a command in native ST code or in underlying Swift. For instance, here is the definition of ST’s “multiply” command, which itself is written in ST:
swift_handler ‘*’ {left as number, right as number} returning number requires {
swift_function: multiply
operator: {infix [“*”, “×”], precedence: 1296}
}
This includes the command’s name and argument and result types (the ST interpreter will automatically map values between native ST types and “primitive” Swift types).
Hanging off the back of that is its Swift-based implementation, which in this case is a total nothingburger:
func multiply(left: Number, right: Number) -> Number { return left * right }
What I haven’t included above is any user documentation, partly ’cos kiwi syntax support isn’t fully implemented yet, though also because even without additional annotations a kiwi dictionary can generate the following documentation (mockup):
Command:
‘*’
left : number
right : number
Result: number
Operator syntax, including synonyms:
left * right
left × right
Add in a “chevron” syntax for weaving metadata into the code data, e.g.:
swift_handler ‘*’ { « multiply v. – multiplies two numbers » «eg: 2 × 2 → 4 »
…
and
‘*’ multiply _v._ – multiplies two numbers
…
Examples of use:
2 × 2
→ 4
As I say, this integration of handler interface signatures, ST↔︎Swift type bridging/glue generation, and end-user documentation is not fully implemented in ST yet. (The interface signature and glue code generation is, and already used to build those library modules.) It has all been built and proven in kiwi though, so I know it works, and works well. As a bear of very little brain, I dislike any coding system that only does one job when, with a little clever design, it can perform 2–4 jobs from the same code—this is just good, efficient Automation!
You’ll also notice how it handles the “custom syntax” problem: an “operator” in ST is just a little bit of custom syntax that sits on top of the command. And that syntax is defined not in the language core, but by the library that defines the command. And all commands are library-defined. The only syntax and features defined by the core language are the built-in datatypes: boolean, number, text (string), list, record, command (and a few others). Everything else is an optional plugin to that core. Want a JSON-like language for representing data? Just run ST with zero libraries loaded. Want to provide a general-purpose imperative scripting language, similar to AppleScript? Load ST’s standard library (org.siritalk.stdlib) plus its custom operator syntaxes, and then load its Apple event library (org.siritalk.aelib).
Want to convert your human-readable code to machine-friendly syntax? Just turn off the custom operator syntax when you pretty-print your program’s code and the whole program will appear in plain CMD {...} format. Hey presto: Siri Shortcuts’ impenetrable XML backend and file format can be completely replaced by SiriTalk. Totally portable and human-readable. ST syntax even has built-in punctuation for piping the output of one command as the input to the next:
Foo; bar; baz.
is semantically identical to baz {bar {foo}}, but structurally follows the sequential order in which a human user and Shortcuts workflow naturally wants to express it. The choice of punctuation—semi-colon—reflects its written-English usage: to link two connected thoughts together.
(With apologies for ST’s Euro-centrism to IndoChinese script users, but I don’t have the smarts to solve non-Latin syntax. Hopefully though, ST’s “word-centric” nature makes it easy to translate all the commands and other text between native languages around the world, especially with the automated human-language translation tools Apple and others are engineering now, and perhaps from there others can eventually figure out how to localize for punctuation as well.)
The syntax and semantics of ST commands are designed to be as easy for humans to learn and read and write as it is for machines. (Caveat western-oriented verb-noun construction, as noted above.) AppleScript has eight different syntaxes, largely incompatible, in which to write commands. ST has one syntax for writing a command, and its syntax and semantics are reduced to the simplest form:
COMMAND_NAME OPTIONAL_ARGUMENT
For practical purposes the argument is normally treated as a record of zero or more LABEL: VALUE properties. ST has coercions built-in, so if you are passing just the first value, you don’t even need to write out the record, thus:
beep 3
is equivalent to writing:
beep {count: 3}
And if you don’t want to pass any arguments:
beep
The coercion system includes the ability to declare optional values, and to supply default values where appropriate. For instance, the beep command’s signature may be defined as:
beep {count: optional {type: whole_number {from: 1}, default: 1}}
Unlike AppleScript’s records, ST records are ordered (more similar to C/Swift structs), so the coercion system also allows labels to be omitted where they can be automatically inferred, meaning:
beep 3
beep {3}
beep {count: 3}
are all acceptable, and, if you are a lazy typist, its signature can also be abbreviated to:
beep {count: optional {whole_number 1, 1}}
One more thing: Nobody likes typing Lots of Irritating Silly Parentheses all the time or, in this case, lots of curly braces, so ST also allows the record’s punctuation to be elided as long as it can be unambiguously inferred by the parser. This is the magic that allows ST commands to be written almost as cleanly readable as in AppleScript:
make new: #document at: end of documents with_properties: {name: “Test”, text: “hello again!”}
get text of every document
Here’s the same commands with the records fully punctuated::
make {new: #document, at: end of documents, with_properties: {name: “Test”, text: “hello again!”}}
get {text of every document}
The only difference you’ll note to a dictionary-defined make command in AppleScript is that each labels always ends in a colon, regardless of whether braces and commas are included or omitted. This small change means there is no longer an awkward artificial difference between a command defined by a scriptable application and a command defined by the user. There is only one syntax to learn, everyone can use it, and it needs no special, brittle, conflict-prone magical keyword injection nonsense to support. This makes ST syntax unambiguous, quickly learnable, readily interpretable by humans and machines.
Little details too, like writing lists:
[1, 2, 3]
[
1,
2,
3,
]
[
1
2
3
]
Both are functionally identical. Just as either commas or linebreaks can be used to separate commands, the exact same punctuation character(s) are used to separate items in lists and records. There is no reason to have two sets of punctuation rules when the intention is exactly the same. Oh, and ? and ! punctuation is also reserved (though not currently supported) so that these can be used as “sentence modifiers” in ST code just as they modify the meanings of sentences in written English. Why? So the user can better express her intention, of course! A dangerous operation? Place a ! after it. Sneaking a peek at a command’s output while debugging—put ? at its end. Depending on how the script is configured when run, these might trigger confirmation/inspection dialogs, do nothing at all, or whatever other behavior the user wishes to hook in. It is her tool, after all; so let her shape it to suit herself.
Everything about ST’s design is designed with two objectives:
-
It is fast and easy for non-programmers to learn, and to extend by defining their own command vocabularies in addition to and/or in place of ST’s default vocabulary so that it better fits their particular needs.
-
It is fast and easy for professional programmers to learn, and to extend by defining their own command vocabularies in addition to and/or in place of ST’s default vocabulary so that it better fits their particular needs.
ST is a natural playground, and a DSL toolkit. Floor polish and dessert topping.
Even ST’s underscore naming convention for commands is deliberately chosen (and should be enforced). An ST pretty-printer can easily color command names so that any underscores appear at, say, reduced 40% opacity. Thus the words are emphasized and the underscores de-emphasized, so the words visually stand out to human readers, but the underscores are still visible on closer inspection so that the reader can distinguish exactly where each name begins and ends. Contrast AppleScript’s pretty printer where, if two adjacent keywords are formatted in the same color, it is impossible to see where each keyword begins and ends, or even tell that they are two separate keywords and not one with a space in the middle. Underscores, it turns out, are semantically useful to the reader, unambiguously denoting name boundaries. (Indeed, AppleScripters struggling to read AS code might want to add underlining to the various keyword styles in Script Editor’s Formatting Preferences.)
That’s the level of thought that has already gone into the iris-script prototype’s design; and it is the third such prototype I’ve built, exploring different design strengths and compromises each time. Because I first saw the one-day end of AppleScript coming a decade ago (2012) and have been slowly chewing on this problem ever since.
There’s a whole lot more I can tell you about SiriTalk’s design and what it means. For example, how most Real Programmers™ would turn up their noses and immediately sneer at its slow “naive” (AST-walking) interpreter, especially when compared to their own insanely optimized bat-out-of-hell fast JavaScriptCore and V8 interpreters. Yet even that is deliberate: ST’s goal is slow, metadata-rich interpreting, with plenty opportunities to attach normal-human inspection tools (debuggers) so any user can see what her program is actually up to as it runs, and even pause, fiddle, and resume.
And when she is happy it is behaving correctly (if not very quick) can swap out the original command libraries for alternative libraries that define the exact same commands but which, instead of performing the behaviors, emit the equivalent Swift code instead, which can then be compiled by Swift’s complex but very powerful optimizing compiler into a program that runs at a decent fraction of the speed a true hand-coded Swift program would run. SiriTalk doesn’t need—or want—a fast interpreter. It bypasses all that complexity and hard work entirely, by making it easy to emit a fast compiled Swift program.
This is why I say again: if we want it, we must build it. Left to their own devices, Real Programmers would rapidly compromise and cripple SiriTalk’s entire design, which they wouldn’t even try to understand on its own terms before remaking it to fit theirs, just to compete amongst themselves to see who can implement the fastest interpreter! Yet we, being Automators, know that’s idiocy. Why do all that work? Just take programs and tools which already exist off the shelf and whip up some quick glue code to link them all together to do the job that we want!
But all that above is more than enough to digest all at once. Sorry for the brain dump; it is what it is. First job of anyone who takes in on: be or hire an editor to reduce all this raw noise down to a readable working roadmap.
…
So, that’s Prong 2, the Language part. And that’s me too. To be clear: none of this is my job to do. I made a start but, I have two options: 1. Build out the SwiftAutomation and SiriTalk prototypes so they’re ready to pitch to Apple well before WWDC 23, or 2. Build kiwi 3.0, get it in the cloud, and steal a healthy chunk of the global $20BN-and-growing Product Personalization market. So I already know which I’m doing; however, if others want to step up and lead the “Let’s Save Apple Automation!” charge, I will do everything I can to facilitate that, and give those crazy kids every change to succeed where old fools failed.
Y’all know where to find me if you choose to step up.
Enjoy,
has
/out
–
p.s. All of this work is open and available on my GitHub except for kiwi, which is proprietary. Anyone who wishes to learn/see more about kiwi, please DM to arrange a professional consult.
I think you may be poisoning the well, so to speak.
Poisoning the well and blowing too much hot air! Why not take all available resources and do what you cannot in one with the other and focus on strengths. It’s great that you have split off and gone in a direction you believe is the right one, but if someone wants to promote AppleScript and encourage its support, don’t go to a site that supports its users better than anyone else and stand there with a sign saying ‘the end is near’. Everyone with any experience has heard that before and somehow it continues with the help of a community of support from people like @alldritt @Piyomaru @ShaneStanley and many others.
Poisoning the well and blowing too much hot air!
All 100% true. The problem is: @lite’s proposed strategy is a futile one… and had lite or I done due diligence we’d have found the whole petition thing was already tried in 2016 and achieved exactly zip, and saved ourselves a good chunk of unproductive exchange entirely.
That leaves all of you with only two options:
-
You can accept that AppleScript’s day is done, that Apple has already chosen a completely different road and is already well along, and just enjoy it while it lasts; or
-
You come up—quickly—with a completely new, exciting strategy to influence Apple’s new direction, by fixing its flaws and making it a hundred times better. Then roll up your sleeves and Build It Yourselves. A modern cross-platform Siri-centered solution which also happens to salvage the concepts that made AppleScript and Apple event Automation so compelling to you lucky few, and make those ideas attractive and accessible to MILLIONS of Apple’s iOS customers. And then You Sell Apple on That.
…
So, by all means, correctly criticise my inability to express myself coherently and concisely. And, once you have your own frustration out of your system (get in line!), you can start by editing my raw ugly brain dump with a chainsaw till you have it down to a fast plan of attack. Why use my plan? Because you don’t have one, at all, and mine has a 10-year headstart.
Or, keep posturing uselessly, fooling only yourselves that you are going to save anything of Mac Automation by complaining how Apple doesn’t love you enough any more.
…
Sorry not-sorry to speak super bluntly, but y’all have enough resources to build a solution that works and take to Apple to show, and maybe even succeed in selling them on it too! (Maybe 1-in-3 chance? Which is really good odds.)
And, for all my faults, what I have done is a lot of the ground work for you. There is nobody left who understands this tech as I do. Both AppleScript’s creators are dead now. I’m the only person on the planet to build Apple event bridges in the last 25 years that actually work. I have over a decade’s experience in designing end-user automation languages that work. None of you here have done that, including Mark (who is a legitimate tiny god). No-one at Apple has done that. Yes, I’m mad as balls, but everyone here is an automation user: we work with the tools we’ve got, not the tools we wish we had. And what we can build with them is phenomenal.
I will not be leading this charge. As you can see, that’s a non-starter even if I wanted to, which I don’t. My own Automation future is building something different entirely, for a smaller ($20Bn) market. But I will work with anyone who wants to work with me—and I am very good at that too, believe it or not—and I will give those people every assistance I can so that they have the best chance of winning.
.
This is my last post here. Anyone who wishes to contact me to get technical advice, discuss collaboration, etc, Mark has my email address. Be well.
I think you lost the point. Nobody asked you what you thought the future of AppleScript was. If you don’t believe in the persons cause that posted, why go so negative on them, the language and one of the people that contributed a majority of their life to it. I’m not trying to start a war of words and posts, my point is…stand on your soapbox and preach what you believe. I respect that. Don’t deflate someone else’s enthusiasm. I personally believe in using every tool at my disposal to get the job done and until AppleScript, applescriptObjC no longer work and people stop building bridges from it to other languages, we all can contribute positively to the learning and support environments that are here.
You can accept that AppleScript’s day is done, that Apple has already chosen a completely different road and is already well along, and just enjoy it while it lasts; or
I do not accept that. People have been saying that was happening or was iminent for as long as I’ve been doing appleScript and they’ve been wrong.
Not only is it still there, still usefull, still supported, it is faster than ever.
Yes, Apple does make nearly all of it’s profits on the iPhone. No doubt. But that doesn’t mean what you think it means. The Mac division still makes a profit. A good, profit, better than it ever has, but not a big as the iPhone. So why wouldn’t they keep a profitable business going?
It’s not like they don’t have the money to invest in both. It’s not like the Mac is syphoning off iPhone profits.
Ford makes cars and trucks, but its biggest money maker is the F-150 pickup truck and its most profitable division is pickup trucks. But ford isn’t going to stop making smaller profits on cars and busses and vans and tractors, because they’re making larger profits in one division. They’re going to keep making profit wherever they can.
Plus, the Mac division has other benefits besides profit and an iOS development platform. In the marketplace it helps apple keep a unified fenced garden of users, all within iphone, ipad, icloud, iTV and mac universe.
And since they have a profitable mac division and are getting a return on their investments, they will keep it going, and, for now and the forseable future that includes AppleScript as part of the Mac Automation strategy.
Hhas01, I felt compelled to open an account here just to reply to you. You begin so far above by criticizing the original poster for not using enough paragraphs, then you launch into the first of many exceedingly-verbose epic rants that you have cluttered this thread with. I have never seen so much drivel pouring out of someone in one place! I can’t believe you have the time in your life to spend furiously typing away your very-strong opinions like this, on and on ad infinitum. I wouldn’t normally have such an issue with this, I suppose—live and let live and all—but you are so negative, and so condescending to everyone else. It’s completely uncalled for; it is absurd. Perhaps you are a sage old AppleScript wizard and you know this subject inside and out—that doesn’t mean that your opinions are the de facto truth of the universe. You are, after all, merely another human being who thinks that they know more than they do—this is a common human feature, and you are not unique in this. You can be an expert at this subject yet still be mistaken about matters concerning it. Don’t forget your own fallibility—we all have this in common! People have more respect for someone who has at least a shred of humility about them compared to someone who bloviates endlessly while informing others that they absolutely can’t disagree as they are all ignorant little toads.
Now please go have some nice tea, give your pet some attention, and rest those poor, tired fingers for a while.
There’s still plenty to enjoy and use in AppleScript, and sunset can last a surprisingly long time, if you choose the right latitude.
Activism here is probably just time lost – waves crashing against rocks.
For better or for worse (my personal feeling tends to the latter) Apple’s centre of gravity has now shifted to the iOS cluster of operating systems, which are scriptable to some degree, but, inevitably, not in terms of Apple Events.
That’s it …
Relax and make good use of what is still there, and maybe enjoy learning a few additional languages in the meanwhile. It’s not a religion, and we should all get out more.
Very well put, CP, thanks!
I don’t know the abstract and ideal story. And I don’t know why you don’t talk about 2.9 after Applescript 2.8.
It’s not a story of a dream story, but specifically, you need to find the functions that should be in 2.9.
1. Elimination of defects
It is deplorable that the print command does not work well. Eliminating this type of problem must be done immediately. I have never heard an excuse that the AppleScript droplet cannot access the dropped file. This is an obvious defect.
2. Reserved reserved words that are not functioned
Select a remote application, select URL, and other CGI -related commands are not suitable in the current MacOS environment.
3. Elimination of specification restrictions
The very narrow width of the numerical variables is starting to be a problem. When cocoa enumerations are assigned, there are cases where an error occurs due to lack of digits. This is because the number of valid numbers in numerical variables is too small. The extension of the numerical type is necessary on a daily basis.
4. Orthogue of functions
The printer name can be specified with the print command, but there is no command to get the printer name list. You can specify the voice reading character by reading the text, but there is no function to get the character list. These are features covered with cocoa calls, but we want to avoid using Cocoa functions for beginners.
5. Cocoa script version upgrade
The adventure that uses Cocoa API from AppleScript seems to have completed the map on the map. The boundary between what I could and what I couldn’t do was clear. I gave up what I couldn’t do and polished what I could.
Nevertheless, cracks have been revealed by the introduction of Swift in the current Cocoa script world built in the Objective-C era and Cocoa API itself. The number of frameworks that cannot be reached from the current AppleScript is increasing. At least you need an API that cannot be called without using a block.
6. Restoration of Xcode environment
The situation in this area is the worst. The script using the XIB file in Xcode 13.x is hindered by Apple, and the AppleScriptObjc template deletion is specified in the release notes of Xcode 14.x. At least, I want you to restore the environment where you can create a normal application with the GUI.
7. Standard attachment of the 3rd Party AppleScript library
Currently, the library is created only by AppleScript, and various user interfaces (mainly dialogs) are provided. At least I want Apple to attach these things as standard.
Finally, as a result of working on Cocoa scripting, you realize that these APIs have been changed so often that they are unnecessary. And you will notice that bugs are occurring surprisingly frequently.
Even if AppleScript does not have a new feature that is surprising, I feel that a large amount of work is needed just by continuing to provide the same function. Apple does not look back on the opinions of foam developers from the Far East island country.
However, the maximum harassment we can do with them is to spread AppleScript great things and increase users.
You sound like you have much experience with AppleScript, Piyomaru, and I can only imagine your frustration with Apple for neglecting this amazing technology for so long. After many decades of being an Apple fan, I have finally decided to look into AppleScript, but it does appear I might be a little too late to the party. It seems that AS may finally be going the way of the dinosaurs—though hopefully not. They are known to return their attentions to things, sometimes. I do not get the feeling that this is likely in this case, unfortunately.
Cheers!
Can you clarify what you’re referring to here? Or, even better, are you able to give an example to illustrate what you mean?