From our friend hhas 
Excellent
RE: hhas/SwiftAutomation, yes. I have built it from source and tested it against my scriptable applications. It is fairly straight-forward, but a Swift syntax has most of the same issues as AppleScript and JavaScript. Those issues are a result of the AppleEvent architecture, SDEF issues, and flawed scriptable app implementations,IMHO, and not of the particular OSA language syntax that is used. Nevertheless, I admire the tremendous work hhas put into SwiftAutomation.
I donāt understand what that means.
I have not used Swift, but I have used both AppleScript and JavaScript extensively.
I see very, very few common issues between AppleScript and JavaScript.
- Simply put, AppleScript is very verbose with very limited support for functions that are built in to most other languages (strings, arrays/lists, records/objects, dates, regex, etc). But it usually works quite well with most app object models.
- OTOH, JavaScript as a language is very mature and full-featured. Unfortunately it is often hard to determine the proper JXA syntax to address automation objects.
So, may I ask, in that context, how would you describe the SwiftAutomaiton language?
I should have said JXA instead of JavaScript, because I was talking about the OSA interface, not the wider use of general-purpose languages. SwiftAutomation converts SDEF terminology into Swift quite well, exposing elements as arrays, classes as objects with properties using dot notation, and defining constants for enumerations, etc. Errors in an SDEF will produce problems in the generated Swift code ā which can be instructive. It does what an OSA language is supposed to do: provide a higher-level interface to sending and receiving inter-process AppleEvents
As @ronzo99 mentions āwider use of general-purposes languages,ā I think this thread is wandering toward a key component: Excellent application support for scripting is the key to the success of any language attempting automation. The main problem: it only exists in rare cases.
It doesnāt matter much if Swift is wonderful. It doesnāt matter much that JavaScript/JXA has far more built-in functionality than AppleScript. Just because there are tons of web developers who know JavaScript doesnāt mean they wonāt hit a brick wall when confronting huge holes in an object model, especially when attempting to automate multiple apps in a single workflow. I think that would be the same case even if JXA was not flawed.
Where has a form of JavaScript worked in application automation? One example: Adobe InDesign. Thatās because InDesign provides automation support for about 99% of its functionality. Many developers use a proprietary JavaScript-based language (made by Adobe) called ExtendScript.
InDesign is a big application in a field in need of automation. So ExtendScript developers suffer through an atrocious editor. They lust after a development environment like Script Debugger, but ExtendScript is cross-platform, so the revenue possibilities are high. They make do with a very flawed environment because the application support is there.
One more thing: Even if all other applications provided superb support, the scripting environment still calls on developers to learn the object model of each application. Thatās far more challenging (and powerful) than a macro program or other types of automation which are based upon the UI. When I speak to developers who are critical of AppleScript, they have many good points about the language. But often times they are just as frustrated with understanding how to direct commands at objects in applications, and vent on that as a general problem with AppleScript. But that is not the fault of a scripting language.
We are so lucky to have Script Debuggerās wonderful dictionary views, including the Explorer, to help figures things out. But we still hit a wall when encountering unsupported areas and very buggy application support. Mail, anyone? MS Word? Preview?? Final Cut Pro?!?
I donāt understand enough about Shortcuts on macOS yet. But is application support a key issue for it as well? We would hope Apple will lead the way, but remember there are a lot of warring factions within Apple itself, which is why so many applications have little or no Apple Event support (plus it is so complex to implement). I wish Shortcuts the best of luck in getting the marketing and technical support needed. But will it be as powerful as automation based on the object model? We will see.
3 Likes
Key phrase: āfor anyone who has ever programed in a real languageā. A great thing about Applescript is that itās NOT a ārealā language ā itās much more approachable by infrequent scripters. Amateurs who want to automate a few processes do far better and far more with Applescript than Assembly, C, C#, C++, Objective-C, Python, Java, or Javascript et al. I think quick and easy monkey-see, monkey-do scripting is where itās at for more casual users. I have a keen interest in this because Iām not a real computer programmer and never took any computer classes, yet as an editorial/creative type, I can still automate the print production of big publications by using Applescript. I have a lot of other stuff to do, so I donāt want to get bogged down memorizing programming minutiae and symbolics. I understand that people who program or script all day will have a different perspective, of course. But I like to stick up for us scripting punks!
1 Like
Iām going to step in here and try to pull this back on topic.
Everyone has been very respectful which I really appreciate, but the OP was about Shortcuts and AppleScript.
JavaScript for Automation is a great alternative to AppleScript for those that find the JavaScript syntax and its built in library of features familiar. JavaScript for Automation is going to benefit, along with AppleScript, from any infrastructure improvements implemented for Shortcuts on macOS.
Similarly, Swift automation has the potential to be a powerful tool. @hhas01 's work in this area is great but he is only one man. I feel that Apple needs to show some interest and intent in this area if it is to be fully realized.
I think the key point has been identified: all the automation options depend on good scripting infrastructure provided by the applications involved. This is the area where advocacy with developers has the greatest potential benefit for us all. The language you choose to exploit these features is a matter of suitability, experience and taste.
If you want to debate the merits of JavaScript for Automation or Swift Automation, letās put that in its own topic. Just remember that these āmy language is cool(er) than yoursā debates tend to descend into noise. The trick is to get the most out of all the tools at hand no matter what they are. Wanting to let people know about alternatives is great, but please avoid the better/best comparisons. All the tools have their place, strengths and limitations.
6 Likes
In the early days of planing for a AppleScript. They looked at small talks but also how unix pipe worked in unix. And in the early days of unix and later pipe. It was possible to write command to talk to each other to return useful data. In the early days of Linux to be able to maintain a computer you need scripting knowledge. For the last 10 years scripting language have become more powerful. Far more easier to find a library, package or module to do what we want without spending time to build it ourself.
@Mark: Bud Tribble a big advocate for open source once said, he doesnāt believe in open source without a strong maintainer. So you are right Apple need to be on board to make anything possible for the future of scripting.
2 Likes
Thereās a deeper core issue here: Appleās support for automation is best described as āthe least possibleā.
FOr example, thereās no coherent way to automate things at all levels of the OS. For the UI level you have these languages and these frameworks, for the lower levels, you have something completely different and to describe getting the two working together as āfragileā is I feel, generous. Kind even.
Compare Appleās automation support to how Microsoft supports PowerShell, and the difference is shockingly obvious. And thereās no reason for it other than will. Apple has the resources and the money to build and document this correctly, but they choose not to. As I said here: Apple and Automation ā Bynkiidotcom, this is literally all about leadership. While I am glad to see Shortcuts and have played around a bit, filed some bugs, am I taking the āregular people can use scripting languages to build thingsā part seriously?
No. Based on Appleās actual history here, I expect the parts that allow devs to port shortcuts to and from i(Pad)OS to get a lot of love and care and attention, and the parts that would be macOS only to be ignored as ruthlessly as possible. Thatās 100% what Appleās done with every new automation push in the past.
Apple could, if they wanted, give us a scripting implementation that was easy to use, but gave you a way to transition to ārealā swift if you wanted. They sort of did that with ASOC, which made ObjC a lot easier to deal with after a while. They choose not to. They could give us āSwiftShellā if you will, that would take the better parts of AppleScript, but give you more power and extensibility.
They choose not to.
Apple could evangelize and dogfood scripting and user automation in their own apps, make them best of breed, showing ISVs the way.
They not only choose not to, they refuse to do so.
Until Apple gets serious themselves about Automation, the parts of Shortcuts that arenāt portable between macOS and i(Pad)OS will get ignored the way Automator has been ignored, the way ASOC has been ignored, the way user-created automation that doesnāt start in Xcode has been ignored. I see no reason to think otherwise. Which is a shame, but Apple does what Apple does.
Because thatās what they choose to do.
4 Likes
Today I was watching 2 videos from WWDC about Shortcuts. It looks to me Shortcuts for macOS 12 is other Automator in SwiftUI Interface. Some concern hit me why do Apple believe developers would include actions in Shortcuts if they never did before with Automator.
I guess Apple think I need other way to start a screen saver on my computer to for fill my need and greatest desire. When they had for years a way to move a mouse cursor to corner of the screen to start a Screen Saver.
Itās a good questionā¦ I guess weāll find out soon enough.
Itās a very good question, and remember that ādevelopersā includes app development teams within Apple, some of which have never created actions or supported any automation via Apple Events. Iām sure we will see some initial enthusiasm because of the marketing emphasis, but the question will be whether that can be maintained long term.
For me at least its more difficult to understand a technology or how to use it if the source code is not available. If Shortcuts action is only limited to a commercial market or few application it will die sooner and later. People have try this before and it have never work.
There are powerful scripting language that include the source code to make it possible to change to learn or build something greater. ex. Pixar Renderman 24 have 100% support of OSL its means a user do not need c++ and that make it easier for any CGI or TD to maintain a shader library.
Iām 100% sure any user of Adobe could learn to code in JavaScript by study Adobeās all JavaScript Scripts examples for ex. Indesign.
PR. Shortcuts already got the marketing that Automator never did. Plus my impression is that Shortcuts isnāt aimed at developers so much as the ordinary Joe.
However, for people who code, I believe Shortcuts workflows can be created with JavaScript. Iāll try and dig out the link.
Iām the same, but thatās just a function of cognitive processing style, and itās one thatās most probably in the minority. So I would guess that most people donāt require the source code to use a technology, and some would actually find it confuses the situation.
Are you dyslexic, by the way ?
Huh? Dylexia?
Itās a form of cognitive functioning that impairs the ability associate phonemes (atomic groups of characters that form a unique sound) to the characters that group together, and any variations of such, to make that sound. The result is difficulties in reading, and comprehending written language for any language in which one is dyslexic, but the payoff is that thereās usually a much stronger visual and spatial ability, and verbal reasoning skills. Programming languages like AppleScript are a nightmare to many, but even more so to dyslexics. Languages like JavaScript or C/++ are processed cognitively like spoken language, but not read like one. So the use of symbols and tokens in place of phonemes and word clusters actually works in favour of dyslexia (or, it can do, I donāt think itās guaranteed).
So, given that you prefer to use source code as a way of understanding a technology, I just wondered if that might be why.
I think the conclusion is a given, as all technologies appear to have a finite lifespan. Thereās a page somewhere with projected lifespans of each common language in use currently. Even C/++ doesnāt appear to be thought to be immortal.
I donāt think itāll be Shortcutsā commerciality that limits its lifespan. Itās surely going to be a strength, given that programming/coding āor some form of itā is increasingly popular with younger people, school leavers, and girls.
Itās no longer bad to be a nerd in British high schools.
Iām not sure thatās relevant. Functional programming almost got vanquished by Javaās fluke PR that popularised OOP in the 90s. Now functional programming is the in-thing even in commercial software development.
Also, donāt underestimate the power of repackaging something old and presenting it as something new. The dog food called Cesar is massive in UK. Itās first incarnation, with identical recipe, named Mr Dog, was a commercial flop.
And the biggest stain on the reputation of millennials wasnāt their inability to cope with real life, but the brief revival of 70s fashion, notably flared jeans, that theyāve tried erasing from the collective consciousness. (For reference, watch Season 4 of Buffy the Vampire Slayer, which documents this inexplicable blip).
Not really, For me its far more easier to read and understand ex. Shane Stanleyās ASObjC and someone else doing the same in AS or ASObjC.
Other cases could be if I do not understand a method I like to do test cases to see the difference. Source code could also give me new ideas and approaches to something and in return I could get something with less code, faster or more comfortable way to code there I do not need to worry next day if I understand it or not. Source code could also give a user the benefit to build code in blocks there we could use the same code in other projects. The benefit by sharing code make it easier for other people to do something better. With that mind set we borrow code from the past to build the future and that will benefit everyone. I truly think Apple could be so much better to share useful code, example specially when they are the maintainer of it. Few videos on WWDC is not enough to say we are done and thats it. Its fine to ask a question, I also think its a responsibility to seek the answer before we ask. (in many cases when I do this I find 5 other ideas). If my memory is correct Apple have in the documentation archive 1 example to make action in Automator. If we search on google we properly will find things related to AppleScript Studio and far beyond Cocoa-AppleScriptObjC. Not only that when Automation was live at Apple the marketing was outside Appleās control in other words they never owned the marketing of it.
You will be surprised how many companies who has engineer, marketing and design people who serve and execute same vision but they do not serve each other. In some cases one part become more important and the other. And that could be a sign of bad judgment or leadership for future products.
Why do you think it would be so much different today ??
OK, thatās a different conversation to the one I thought you were trying to initiate. When you related the ease at which you can understand and make use of technologies better when you have access to the code, it sounded to me as though you were describing a cognitive tendency towards source code as a more natural way to get to grips with using e.g. a piece of software. In this case, I figured you meant that Shortcuts would feel easier to use if you had access to the applicationās source code.
But it sounds like I got the wrong end of the stick, and you might actually have been referring to the use of source code that others have written for e.g. a plug-in, or an Automator action, as a means to learn from, or inspire your own future coding projects.
If Iām closer to the mark this time with what youāve said, then I agree with (almost) the entire paragraph starting with āOther casesā¦ā. I think sharing code makes sense, and I think itās very sensible (and a common means of bolstering learning) to analyse other peopleās work, adapt it, etc. Yup, canāt disagree with any of that.
No, I probably wouldnāt be surprised one iota. Itās a fairly universal ethos, at least across UK vocational sectors (Iāve worked across an usually broad range of fields, that some might describe as indecisive, or a lack of corporate loyalty. On both accounts, I totally agree). It seemed to be less the case in Danish academia in which I kicked about for a year, and in Souh African public healthcare, in which I spent another year. Those two places had one thing that I could see in common, which was that neither were driven by monetary needs. The Danes appeared to have an over abundance of wealth, that Iāve heard is not unique among the Scandinavian countries nor across employment sectors. The South African public healthcare system essentially was funded by goodwill and ability to reuse whatever you have, on the assumption that there wonāt be any more coming. Either way, money wasnāt the overriding imperative, and it cultivated more cohesion and cooperation for one mutually-agreed goal at any given moment. The UK working environments feel like a war zone, except for Google.
I donāt follow. What did I say would be different ?
It was not about what you said, it was more about my approach to companies who have a vision, do innovation and serve the quality of a product. Sometimes they do not always serve each others best interests and in return the product become a forgotten technology but not directly a pore design for what it does. Engineer, marketing and design are different things and they see the world differently and maybe its a bad judgement to think this is the same person. Its not Sal Soghoian fault he become that person when Appleās executive had other plans for the future or maintain the technology.
We agree that Apple never owned the marketing of Automation. If the engineer believed Automation was a powerful technology. Apple decide to close the development of Automation of business reasons. It looks to me if Apple thought Automation was important they could have choose other path. Automation have always been important in many different environment and Iām sure Apple knows that.
Would it be so much different today
If you do not have engineer, marketing and design people who share the same visions who also serve the vision and believe in the product. You have something that more likely will failing and be a success. In the Italian culture the design serve the quality. In Sweden and properly in Germany to the engineer (quality) serve the design. It means it doesnāt matter for a German if the design is excellent if the engineer approach to quality is poorly. Same culture you find in France in restaurants its very difficult to have a business with bad food in France. (bad food in french standard)
If user X is only limited to the actions Apple provide only the creativity is the limited factor what is possible. If user Y is developer or know how to code he/she could make other approaches that user X couldnāt. Still both will be limited to the design it provide and the time it takes to implant it.
If the design how to use it is limited or Apple do not maintain the API to extend it. It doesnāt matter if you have knowledge how to use it most people would use something else.
The power of scripting language its very easy to maintain by importing libraries of your own design or someone else who have been so kind to share to the community. That has not change 2021 and still matters and everything doesnāt have to be thru Xcode. Iām glad some people at Apple believe in something else: Core Image: Performance, Prototyping, and Python