One Apple Programmer Got Apps Talking to Each Other
wired.com
wired.com
[1] http://www.salsoghoian.com/bio/musicbio.html [2] http://www.salsoghoian.com/recordings/index.html
Sal Soghoian isn’t a programmer—I’ve seen his code, it’s embarrassingly amateur.
Sal was not responsible for AppleScript of Apple event IPC; that was Cook and Harris, and that credit is theirs[1]. They walked out of Apple shortly after AppleScript 1.1 was released when Apple abruptly slashed their team. Sal had no part in its creation.
Sal was an enthusiastic end-user and early adopter, who talked himself into taking over what was left of that department some time later. Unfortunately, his gift for the gab was not matched by skills in product development and marketing. Classic case of Peter Principle in action.
Automator was Sal’s, and while it wasn’t a bad idea it failed as a popular product. It was badly positioned as a standalone app, which the standalone Script Editor already demonstrated doesn’t create interest or adoption. To sell it as an end-user solution it needed to be positioned where the end-users’ problems are: within the end-users’ apps. Automator should’ve been a self-contained GUI control for App developers to embed directly into apps, alongside the existing AppKit NSRuleControl and a standard menubar “Tasks” menu to provide high-profile visibility and instant access.
Soghoian’s team was also responsible for Scripting Bridge (10.5) and JavaScript for Automation (10.10), which should have won Mac Automation millions of enthusiastic new users amongst Python, Ruby, ObjC and JavaScript geeks, but were so technically dreadful that they even made AppleScript look good in comparison.
Worse, once released, Sal made zero effort to promote or support them, never mind fix their flaws; even today, a decade on, 99% of Mac programmers have no clue that these “programmer-friendly” alternatives to AppleScript exist.
..
Ironically, there was a true programmer-friendly alternative to AppleScript already available back in 2006: appscript[2]. I wrote appscript precisely because I was an AppleScript user who loved the automation but hated the language, and found all the other 3rd-party Apple event bridges painfully flawed. While my promotion of it was crap, programmers who used it adored it, because it worked for them and, unlike AppleScript and SB, didn’t lie or obfuscate how Apple event automation really worked. (Hint: it’s not OOP, it’s RPC + queries.)
Appscript was good enough that Apple even considered including it in Mac OS X… till Sal Sherlocked it with his crappy broken Scripting Bridge framework, wrecking them both.
..
As for 2014’s surprise announcement of JavaScript for Automation, that should’ve been Mac Automation’s instant salvation, launching just as interest in desktop JavaScript was taking off thanks to Node.js. Knowing its success was critical to Mac Automation’s survival, I even gave that jerk six weeks of my unpaid time to test and critique the tar out of it; even writing a JavaScript OSA reference implementation[3] for them to copy and/or steal.
Halfway through Sal went radio-silent on me, which I should’ve recognized as a warning sign; but I’m a dope. Sal ignored my feedback, JXA shipped half-baked and broken, I scrapped all my plans to write the book and support its community, and Sal did bugger all to promote and support it himself. JXA sunk without trace, and Sal was still utterly clueless that he’d just killed Mac Automation and his own department as well.
Even then, Sal had one last chance to salvage the situation: by 2015 Swift was just about ready for production use and interest in using Swift was exploding. All Sal needed to do was hook Mac Automation onto Swift’s coattails and let Swift lift it upward for free. Seeing this opportunity coming I had already created SwiftAutomation[4] as a free, ready-made solution.
Alas, I made the mistake of offering SwiftAutomation to Sal—and the patronizing fool threw the offer back in my face. At which point I told him he was a arrogant incompetent unfit for the job who’d run Mac Automation into the ground. I got some bitter satisfaction when Apple sacked his useless ass not long thereafter; unfortunately, he took the whole team down with him, leaving the entire AppleScript stack parked in minimal maintenance mode and unloved disgrace.
..
And that’s Sal Soghoian’s TRUE legacy: not as the inventor of Mac Automation, but the incompetent who killed it.
--
[1] http://www.cs.utexas.edu/~wcook/Drafts/2006/ashopl.pdf
[2] http://appscript.sourceforge.net/
[3] https://sourceforge.net/projects/appscript/files/
[4] https://hhas.bitbucket.io/welcome.html
--
Postscript:
For a time I did wonder if it was just me (I am am extremely prickly arse), but then I saw him pull the same arrogant condescending ungrateful crap on another experienced developer who was kindly pointing out some problems in Sal’s (JavaScript) code and offering constructive improvements. Textbook Dunning-Kruger syndrome combined with old-school Not Invented Here, and perfectly described in a great series of articles by Erik Dietrich: the “Expert Beginner”.
https://daedtech.com/how-developers-stop-learning-rise-of-th...
https://daedtech.com/how-software-groups-rot-legacy-of-the-e...
I especially agree that Automator was/is a disaster and there were numerous missed opportunities to improve MacOS scripting adoption.
I've also seen your work, which is very impressive.
I'm working on something in this space. Can I possibly pick your brain about a few things? My email is in my profile.
It’s not just me either, but I say it because it needs to be said, because unless you identify the failure there’s no hope in hell of finding a fix. Mac Automation isn’t on its ass because it’s old or bad technology; it’s on its ass because it was horribly mismanaged by a clueless incompetent of a project manager.
The tech could still be fixed; the problem now is politics. That’s why I think it’s borked, but until the last ax drops I’ll keep on trying to salvage it anyway because I care that much about the fundamental principle: putting power and control back in the hands of the users.