4 ms·

A couple weeks ago I wrote an Automator folder action that faxes any PDF dropped into it (https://github.com/EricWVGG/birchfax https://github.com/EricWVGG/birch

A couple weeks ago I wrote an Automator folder action that faxes any PDF dropped into it (https://github.com/EricWVGG/birchfax https://github.com/EricWVGG/birchfax, if anyone is interested). Uses a bit of Automator, a bit of Applescript, a bit of Node. Fun little exercise and has been enormously useful to a friend whose life now depends on faxing forms to hospitals and insurance companies every week. But the whole experience also left me sad about the Macintosh platform. Applescript is a hot mess of a language; it can be done in Javascript now, but that's largely undocumented. Thanks to poor accessibility of the technology, the support for scripting in apps is waning. Automator, goodness, what a wild tool… but again, the documentation is horrible. Apple made two phenomenal technologies and then completely fumbled on the last mile. The future of initiatives like Siri needs robust inter-app scripting. My only wish for the future of MacOS and iOS is a renewed push for this. (okay, that and lock screen "complications")

neurobashing 8y ago
The "JavaScript for Automation" stuff is extremely incomplete, and to make matters worse, whatever dingus in XCode generates the documentation only knows about AppleScript, so sometimes you get object methods called properties and in any event the return type is wrong, etc. Basically made it work well enough for a few things that ship on a default OS X install and stopped.
- crooked-v 8y ago
  It also has the problem that there's no straightforward way to use external packages at all, which is a killer for efficient Javascript use.
  - hhas01 8y ago
    This. This. And Absolutely This. npm integration was an absolute must-have to ensure popular adoption; even I could see this straightaway. Alas, as last Apple bastion of Not Invented Here, the Mac Automation team insisted on rolling everything themselves. All problems I told Sal about before JXA ever shipped. Told him about lots and lots of problems, which he pretty much ignored. Even wrote and sent him a quick-n-dirty JavaScript OSA implementation (https://sourceforge.net/projects/appscript/files/ https://sourceforge.net/projects/appscript/files/), by which time the man didn’t even have the common manners to say “thanks but no thanks”. A charming chap who talks great game, but a thin-skinned martinet. There was no technical reason JXA could not have been 99.9% as good as AppleScript at application automation, and a million times better at everything else. 100% PEBKAC.
jorvi 8y ago
Since Apple acquired Workflow I still have some small hope they’ll create a unholy fusion between AppleScript, Automator and Workflow for both iOS and macOS..
- Eric_WVGG 8y ago
  Well, we just came a step closer :) #wwdc2018
infogulch 8y ago
> The future of initiatives like Siri needs robust inter-app scripting. That's a really good point. Siri would have enormously benefited from a robust, powerful automation ecosystem. Even if they don't use it directly it could have been the base for all Siri actions and the distance from automation to Siri would be much smaller than going all the way to Siri from where we are now. Apple missed a big opportunity.
- hhas01 8y ago
  +1 That Apple still can’t put 1 and 1 together shows just how utterly ignorant they are of the mind-bogglingly powerful product technology they’ve been sitting on for the last 25 years. The great irony is that unlike painfully tedious low-level object-oriented API/IPC systems like DOM, CORBA, and SOAP, the Apple Event Object Model (the IPC architecture used in “AppleScriptable” applications) is driven via RPC using simple, high-level relational QUERIES. VERY powerful, amazingly (when it works right) elegant. Apple event IPC has its issues—inconsistent implementations, notoriously inadequate interface descriptions, and a security model rocking it like it’s 1995—but it’s still remarkably close to being Siri-drivable, and has the massive benefit that it’s already implemented in hundreds of apps and is free for the taking. (Or would be, if Apple hadn’t left Sal to run it into the ground.) .. Not coincidentally, I put together a proof of concept for a hybrid Logo/AppleScript replacement a couple years back, designed from the start not just to enable traditional text entry, but also to be skinnable in a Workflow-like GUI or even driven by voice. Other commitments got in the way, but POC files are here: https://bitbucket.org/hhas/entoli/src/master/README.txt https://bitbucket.org/hhas/entoli/src/master/README.txt Key USP: true whitespace support in command names, making them very easy for non-programmers to read and write, particularly with modern autosuggest+correct+complete assistance (command interfaces are fully introspectable too). Add Apple event capabilities (https://bitbucket.org/hhas/swiftae/src/master/ https://bitbucket.org/hhas/swiftae/src/master/) and wrap some friendly end-user tools around it, it’d be very powerful indeed. Classic turtle example: Turn right 135°, pen down, move forward 2.5mm, turn left 90°, move forward 20cm, pen up. Named “entoli” (phonetic Greek for “instruct” or “command”) in HT to Seymour’s Logo, but also nicknamed “SiriScript” for fairly obvious reasons. :)
mistersquid 8y ago
AppleScript is an incredible tool that has many warts, perhaps the largest being how idiosyncratic its implementations are from application to application (each app defines its own AppleScript dictionary which is, essentially, a framework library). There are also many idiosyncrasies due to how scripts are run by the AppleScript component manager and state may or may not be maintained between execution depending on whether the script has been compiled on the local machine, is run inside AppleScript Editor, is run in a particular version of AppleScript Editor, which version of AppleScript is on the local machine, etc. etc. [0] Apple's official documentation is helpful, but the real documentation for AppleScript developers (I feel AS is feature complete enough that its practitioners can be regarded as developers) is Matt Neuburg's AppleScript: The Definitive Guide (from which the earlier citation comes). [1] If you've puzzled over how to get something working properly in AppleScript and have been amazed at how indispensable AppleScript can be to generate a custom workflow using macOS applications, the command line, and your favorite programming language behind the scenes (Perl, JavaScript, Objective-C, etc.), you really cannot do yourself a bigger favor than getting a hold of Neuburg's book. [0] https://books.google.com/books?id=x5AE8cxocdAC&pg=PA76&lpg=PA76&dq=applescript+%22component+manager%22&source=bl&ots=gvK45a33_b&sig=NTeOWMqzC979lr865waEyjV6eOE&hl=en&sa=X&ved=0ahUKEwiOmba3irjbAhWJIHwKHWZCA9MQ6AEIMDAC#v=onepage&q=applescript%20%22component%20manager%22&f=false https://books.google.com/books?id=x5AE8cxocdAC&pg=PA76&lpg=P... [1] https://www.amazon.com/AppleScript-Definitive-Guide-Matt-Neuburg/dp/0596102119 https://www.amazon.com/AppleScript-Definitive-Guide-Matt-Neu... EDIT: remove extraneous word. Add period. Change “Applescript” to “for Applescript developers”
cgb223 8y ago
There might be a great opportunity there to write a github with open source documentation for both It’d be an awesome way to contribute to the community and I’m sure it would look great on a resume
- hhas01 8y ago
  Nope. Already been tried (https://github.com/JXA-Cookbook/JXA-Cookbook https://github.com/JXA-Cookbook/JXA-Cookbook) and failed. I can count on the fingers of one hand all the people on the planet who could’ve delievered the user documentation essential to driving JXA’s early adoption and success, and there’s a reason none would touch it with a 20ft pole. The JXA that shipped in 10.10 was a defective half-baked POS that was immediately abandoned to rot. Even if contributors knew enough about JXA and application scripting to produce quality documentation, who’s going to read all these new JXA docs when it’s already failed to win any users after 4 years on the market? I lead-authored Apress’s Learn AppleScript 3rd ed, so know just what a Hell it is to get right. And I desperately wanted to do THE book on Automating your Mac with JavaScript—cos I knew JXA’s success or failure would decide the future of Mac Automation. (Also, MILLIONS of JavaScript users == 100,000s of book sales!:) But I simply couldn’t write a usable book about unusable shit. So don’t waste your time. Mac Automation as we know it is already dead; it just hasn’t stopped twitching yet.

neurobashing 8y ago

The "JavaScript for Automation" stuff is extremely incomplete, and to make matters worse, whatever dingus in XCode generates the documentation only knows about AppleScript, so sometimes you get object methods called properties and in any event the return type is wrong, etc. Basically made it work well enough for a few things that ship on a default OS X install and stopped.

crooked-v 8y ago
It also has the problem that there's no straightforward way to use external packages at all, which is a killer for efficient Javascript use.
- hhas01 8y ago
  This. This. And Absolutely This. npm integration was an absolute must-have to ensure popular adoption; even I could see this straightaway. Alas, as last Apple bastion of Not Invented Here, the Mac Automation team insisted on rolling everything themselves. All problems I told Sal about before JXA ever shipped. Told him about lots and lots of problems, which he pretty much ignored. Even wrote and sent him a quick-n-dirty JavaScript OSA implementation (https://sourceforge.net/projects/appscript/files/ https://sourceforge.net/projects/appscript/files/), by which time the man didn’t even have the common manners to say “thanks but no thanks”. A charming chap who talks great game, but a thin-skinned martinet. There was no technical reason JXA could not have been 99.9% as good as AppleScript at application automation, and a million times better at everything else. 100% PEBKAC.

jorvi 8y ago

Since Apple acquired Workflow I still have some small hope they’ll create a unholy fusion between AppleScript, Automator and Workflow for both iOS and macOS..

Eric_WVGG 8y ago
Well, we just came a step closer :) #wwdc2018

infogulch 8y ago

> The future of initiatives like Siri needs robust inter-app scripting. That's a really good point. Siri would have enormously benefited from a robust, powerful automation ecosystem. Even if they don't use it directly it could have been the base for all Siri actions and the distance from automation to Siri would be much smaller than going all the way to Siri from where we are now. Apple missed a big opportunity.

hhas01 8y ago
+1 That Apple still can’t put 1 and 1 together shows just how utterly ignorant they are of the mind-bogglingly powerful product technology they’ve been sitting on for the last 25 years. The great irony is that unlike painfully tedious low-level object-oriented API/IPC systems like DOM, CORBA, and SOAP, the Apple Event Object Model (the IPC architecture used in “AppleScriptable” applications) is driven via RPC using simple, high-level relational QUERIES. VERY powerful, amazingly (when it works right) elegant. Apple event IPC has its issues—inconsistent implementations, notoriously inadequate interface descriptions, and a security model rocking it like it’s 1995—but it’s still remarkably close to being Siri-drivable, and has the massive benefit that it’s already implemented in hundreds of apps and is free for the taking. (Or would be, if Apple hadn’t left Sal to run it into the ground.) .. Not coincidentally, I put together a proof of concept for a hybrid Logo/AppleScript replacement a couple years back, designed from the start not just to enable traditional text entry, but also to be skinnable in a Workflow-like GUI or even driven by voice. Other commitments got in the way, but POC files are here: https://bitbucket.org/hhas/entoli/src/master/README.txt https://bitbucket.org/hhas/entoli/src/master/README.txt Key USP: true whitespace support in command names, making them very easy for non-programmers to read and write, particularly with modern autosuggest+correct+complete assistance (command interfaces are fully introspectable too). Add Apple event capabilities (https://bitbucket.org/hhas/swiftae/src/master/ https://bitbucket.org/hhas/swiftae/src/master/) and wrap some friendly end-user tools around it, it’d be very powerful indeed. Classic turtle example: Turn right 135°, pen down, move forward 2.5mm, turn left 90°, move forward 20cm, pen up. Named “entoli” (phonetic Greek for “instruct” or “command”) in HT to Seymour’s Logo, but also nicknamed “SiriScript” for fairly obvious reasons. :)

mistersquid 8y ago

AppleScript is an incredible tool that has many warts, perhaps the largest being how idiosyncratic its implementations are from application to application (each app defines its own AppleScript dictionary which is, essentially, a framework library). There are also many idiosyncrasies due to how scripts are run by the AppleScript component manager and state may or may not be maintained between execution depending on whether the script has been compiled on the local machine, is run inside AppleScript Editor, is run in a particular version of AppleScript Editor, which version of AppleScript is on the local machine, etc. etc. [0] Apple's official documentation is helpful, but the real documentation for AppleScript developers (I feel AS is feature complete enough that its practitioners can be regarded as developers) is Matt Neuburg's AppleScript: The Definitive Guide (from which the earlier citation comes). [1] If you've puzzled over how to get something working properly in AppleScript and have been amazed at how indispensable AppleScript can be to generate a custom workflow using macOS applications, the command line, and your favorite programming language behind the scenes (Perl, JavaScript, Objective-C, etc.), you really cannot do yourself a bigger favor than getting a hold of Neuburg's book. [0] https://books.google.com/books?id=x5AE8cxocdAC&pg=PA76&lpg=PA76&dq=applescript+%22component+manager%22&source=bl&ots=gvK45a33_b&sig=NTeOWMqzC979lr865waEyjV6eOE&hl=en&sa=X&ved=0ahUKEwiOmba3irjbAhWJIHwKHWZCA9MQ6AEIMDAC#v=onepage&q=applescript%20%22component%20manager%22&f=false https://books.google.com/books?id=x5AE8cxocdAC&pg=PA76&lpg=P... [1] https://www.amazon.com/AppleScript-Definitive-Guide-Matt-Neuburg/dp/0596102119 https://www.amazon.com/AppleScript-Definitive-Guide-Matt-Neu... EDIT: remove extraneous word. Add period. Change “Applescript” to “for Applescript developers”

cgb223 8y ago

There might be a great opportunity there to write a github with open source documentation for both It’d be an awesome way to contribute to the community and I’m sure it would look great on a resume

hhas01 8y ago
Nope. Already been tried (https://github.com/JXA-Cookbook/JXA-Cookbook https://github.com/JXA-Cookbook/JXA-Cookbook) and failed. I can count on the fingers of one hand all the people on the planet who could’ve delievered the user documentation essential to driving JXA’s early adoption and success, and there’s a reason none would touch it with a 20ft pole. The JXA that shipped in 10.10 was a defective half-baked POS that was immediately abandoned to rot. Even if contributors knew enough about JXA and application scripting to produce quality documentation, who’s going to read all these new JXA docs when it’s already failed to win any users after 4 years on the market? I lead-authored Apress’s Learn AppleScript 3rd ed, so know just what a Hell it is to get right. And I desperately wanted to do THE book on Automating your Mac with JavaScript—cos I knew JXA’s success or failure would decide the future of Mac Automation. (Also, MILLIONS of JavaScript users == 100,000s of book sales!:) But I simply couldn’t write a usable book about unusable shit. So don’t waste your time. Mac Automation as we know it is already dead; it just hasn’t stopped twitching yet.