Shortcuts + Applescript?

From our friend hhas :slight_smile: Excellent :slight_smile:

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

I find Swift to be very interesting specially website like this.
Swift for scripting.

1 Like

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