I spend 3 months with MA students in translation as interns last spring and our last self-inflicted challenge was to create from scratch, with a language none of use knew (and them even less than me), an equivalent to the script I worked on in the following thread:
The (only?) difference was that the files were not opened and accessed from the command line.
I was surprised to see that Python, the language we chose, even though the 3 of us were absolute beginners in the language, produced a 1000x times faster solution than anything I had done with XML creation in ASObjC before.
I’m not really interested in the “why”, but I figured that all the parts that are not about inter applications communication should rather be handled by more efficient languages while leaving the data collection to AS.
Also, creating XML with Python and minidom was a breeze while doing the same in ASObjC took me a very long time and required the support of AS experts.
Is that approach of splitting the process between communication/data collection and data processing a good approach ?
That is why I created appscript. Having taught myself Python to do all the things that AppleScript was bad at, I figured it’d be quicker just to humph the Apple event stuff over to Python as well than keep going back-n-forth.
As it turns out, it took me another 3 years to get appscript working right, and then all that work got spiked by Apple anyway. But the principle is sound, and FWIW the Python 3 version of appscript still works today and is still the best damn piece of software I’ve ever written/used. Had Apple gone ahead and shipped appscript in 10.5 Mac Automation would be in a completely different state today, but Expert Beginner and Not Invented Here syndromes won out and wrecked the entire platform instead.
My advice? If you’re writing a non-trivial program that does lots of data processing, write it in Python3/Node.js/Swift and call into AppleScript only where needed. (Or, if you’re brave, use appscript/nodeautomation/SwiftAutomation, which all work and have decent support tools although I do not provide free support.) Partly because it far faster and vastly less painful to write that code in better-featured languages (once you get over the initial learning hump) with awesome library support, but mostly to future-proof your investment by minimizing its dependency on a legacy macOS technology with uncertain future ahead.
