5 ms·

AppleScript contains some amazingly powerful APIs, but is nearly impossible to write. Having a Javascript (successor?) implementation is going to unleash its f

by 3JPLW 12y ago

AppleScript contains some amazingly powerful APIs, but is nearly impossible to write. Having a Javascript (successor?) implementation is going to unleash its full potential. I could see it becoming much more widely used and supported by third party apps. This is wonderful. In the same cycle that they release a brand new language, they begin the deprecation process for their (only?) other proprietary programming language in favor of an existing language. Pretty cool.

judk 12y ago
As braindead as the language was, the real problem with AppleScript was the bizarre object model, so the Object help doc was full of nonsense methods that did nothing useful. Finding the one method doExactlyOneSpecificThing that matched what you need was always a low-probability event. The opposite of the UNIX philosophy and modular design.
- rmrfrmrf 12y ago
  Yep. Script Debugger was almost a requirement for doing any serious AppleScript hackery. You can explore an open application's exposed objects and tell Script Debugger to paste the path to it into your current script. Way better than guessing when you need to `tell x` in order to expose its properties or whatever. The most underrated thing to me that made it all worthwhile, though, was Remote Scripting. I think the full potential of it has yet to be realized, and hopefully JavaScript will allow some impressive future developments.
- riffraff 12y ago
  is this going to be solved by writing it in javascript though? Looking at the sample code in this page: Mail.outgoingMessages.whose({subject:'JavaScript'}) is doesn't look much better.
  - obituary_latte 12y ago
    Looks pretty straightforward to me. Do you know what the equivalent AppleScript is? Edit: found a stack overflow question/answer [1]. It's doing a little additional work beyond searching for mails with a particular subject, but even just the searching functionality is much larger and more convoluted that the single line of js you referenced. [1]http://stackoverflow.com/q/8156120 http://stackoverflow.com/q/8156120
  - meowface 12y ago
    I never understood the cutesy naming schemes. What's wrong with .filter or .where.
    - erikano 12y ago
      I agree, but I guess .filter or .where could be more difficult to understand for beginners.
    - nilliams 12y ago
      Agree. Hopefully (?) it's just JS by the point we get to `Mail.outgoingMessages` so it should be fairly straightforward to mix-in underscore's methods into whatever their 'collection' representation is, the same way Backbone does [1] to give you map/filter/which etc. [1] http://backbonejs.org/#Collection-Underscore-Methods http://backbonejs.org/#Collection-Underscore-Methods
    - turingcar 12y ago
      In fact, you can use either “whose” or “where”, and the AppleScript language guide refers to this as “Filter”: <https://developer.apple.com/library/mac/documentation/applescript/conceptual/applescriptlangguide/reference/ASLR_reference_forms.html#//apple_ref/doc/uid/TP40000983-CH4g-BAJJHEFE> https://developer.apple.com/library/mac/documentation/apples...
  - coldtea 12y ago
    This is about as simple as an API goes. What did you expect to see exactly? doWhatImThinking();
    - riffraff 12y ago
      It's not ease of use I'm talking about, I was referring to API discoverability/ease of finding what you need. Since the javascript code looks isomorphic to outgoing messages whose subject is "JavaScript" I'd think that the issue is not mitigated by a different syntax.
  - rmrfrmrf 12y ago
    tell application "Mail" set msgs to every outgoing message whose subject is 'JavsScript' end tell So, yes :).
  - jimbokun 12y ago
    Looks very Ruby-esque.
- Camillo 12y ago
  You're not actually supposed to have doExactlyOneSpecificThing methods in AppleScript. Instead, you are supposed to have a small number of verbs that can operate on a large number of objects and their properties. It was REST before there was REST. Unfortunately, this design principle was often misunderstood by those writing scripting interfaces for applications. It also didn't help that Apple provided very little support for implementing the language's rich query model, which led to many applications only implementing one or two ways to access objects, often with bugs. That was the source of most of the annoyances with AppleScript.
sriku 12y ago
AppleScript was originally conceived to be easy enough for non-professional programmers to read and write, with the history of Hypercard behind it. This is for those rare occasions when they needed to automate something that they do with multiple applications manually. At one point, you were able to hit "Record", do the things that you needed to be automated and boom you get a script that you can begin to massage into something reusable. You didn't need to be a programmer to read this recorded script and you didn't need to know English to read/write it either (it was available in other languages). It looks like Apple realized that automation is the core problem they need to solve and made .. Automator instead, which is based on the same underlying piping - OSA. edit: Back in 1998/99, I even wrote a web server entirely in AppleScript - it was a platform for our research lab to share, debate and record ideas.
- wlesieutre 12y ago
  Automator even has the same "record" functionality for repeating tasks in a UI[1]. The direct Automator actions like "scale image" are cleaner when they exist, but including Automator actions with 3rd party applications didn't catch on as much as it could have. Some apps have them (Pixelmator comes to mind), but for the most part it doesn't have the support that AppleScript used to. It's a bit sad that we now have easier automation (via IFTT) in a huge pile of webapps than many native programs where it hasn't improved in the last 10-20 years. [1] http://www.macosxautomation.com/automator/features/virtual-user.html http://www.macosxautomation.com/automator/features/virtual-u...
  - sriku 12y ago
    The core of AppleScript is a protocol defined as the OSA. This, as Camillo pointed out, is super close to REST and that suggests a possible evolution of the underlying idea as a glue system between "web apps" including desktop apps. Actually, even an 'evolution' isn't necessary, since AppleScript can directly work with Objective-C frameworks, instantiating objects, calling methods, etc. So this gluing between the desktop world and the networked world already exists.
- tlrobinson 12y ago
hrktb 12y ago
Applescript was only a front end for OSA, for instance there is/was a working perl front end for OSA. The reason it never really took off is mostly due to OSA itself, and not the scripting language I think. For instance most of the Adobe product don't care about OSA and offer a Lua extension mechanism instead (even there, I feel they only cared avout filters and publishing modules). Or even iPhoto had severe limitations on what could be done through the scripting interface. The Finder has perhaps the most useful interface, but anything done there can also be done in the shell IMO. There must be other apps exposing very useful functionalities to OSA, but I haven't see many.
gcanyon 12y ago
Others have touched on this farther down, but this always sets me off: AppleScript is not confusing because of its native syntax. It's confusing because of the inconsistent, often contradictory, incomplete, and sometimes just insane dictionaries provided by the various apps you access with AppleScript. Switching to JavaScript will do exactly zero to fix that. However, there appears to be new functionality inherent in the implementation, including better integration of native code (oddly, the examples are in ObjC instead of Swift), and I assume this will be faster than AppleScript. If this increases the popularity of writing scripts, then perhaps app-writers will improve their dictionaries.

by 3JPLW 12y ago

judk 12y ago

As braindead as the language was, the real problem with AppleScript was the bizarre object model, so the Object help doc was full of nonsense methods that did nothing useful. Finding the one method doExactlyOneSpecificThing that matched what you need was always a low-probability event. The opposite of the UNIX philosophy and modular design.

rmrfrmrf 12y ago
Yep. Script Debugger was almost a requirement for doing any serious AppleScript hackery. You can explore an open application's exposed objects and tell Script Debugger to paste the path to it into your current script. Way better than guessing when you need to `tell x` in order to expose its properties or whatever. The most underrated thing to me that made it all worthwhile, though, was Remote Scripting. I think the full potential of it has yet to be realized, and hopefully JavaScript will allow some impressive future developments.
riffraff 12y ago
is this going to be solved by writing it in javascript though? Looking at the sample code in this page: Mail.outgoingMessages.whose({subject:'JavaScript'}) is doesn't look much better.
- obituary_latte 12y ago
  Looks pretty straightforward to me. Do you know what the equivalent AppleScript is? Edit: found a stack overflow question/answer [1]. It's doing a little additional work beyond searching for mails with a particular subject, but even just the searching functionality is much larger and more convoluted that the single line of js you referenced. [1]http://stackoverflow.com/q/8156120 http://stackoverflow.com/q/8156120
- meowface 12y ago
  I never understood the cutesy naming schemes. What's wrong with .filter or .where.
  - erikano 12y ago
    I agree, but I guess .filter or .where could be more difficult to understand for beginners.
  - nilliams 12y ago
    Agree. Hopefully (?) it's just JS by the point we get to `Mail.outgoingMessages` so it should be fairly straightforward to mix-in underscore's methods into whatever their 'collection' representation is, the same way Backbone does [1] to give you map/filter/which etc. [1] http://backbonejs.org/#Collection-Underscore-Methods http://backbonejs.org/#Collection-Underscore-Methods
  - turingcar 12y ago
    In fact, you can use either “whose” or “where”, and the AppleScript language guide refers to this as “Filter”: <https://developer.apple.com/library/mac/documentation/applescript/conceptual/applescriptlangguide/reference/ASLR_reference_forms.html#//apple_ref/doc/uid/TP40000983-CH4g-BAJJHEFE> https://developer.apple.com/library/mac/documentation/apples...
- coldtea 12y ago
  This is about as simple as an API goes. What did you expect to see exactly? doWhatImThinking();
  - riffraff 12y ago
    It's not ease of use I'm talking about, I was referring to API discoverability/ease of finding what you need. Since the javascript code looks isomorphic to outgoing messages whose subject is "JavaScript" I'd think that the issue is not mitigated by a different syntax.
- rmrfrmrf 12y ago
  tell application "Mail" set msgs to every outgoing message whose subject is 'JavsScript' end tell So, yes :).
- jimbokun 12y ago
  Looks very Ruby-esque.
Camillo 12y ago
You're not actually supposed to have doExactlyOneSpecificThing methods in AppleScript. Instead, you are supposed to have a small number of verbs that can operate on a large number of objects and their properties. It was REST before there was REST. Unfortunately, this design principle was often misunderstood by those writing scripting interfaces for applications. It also didn't help that Apple provided very little support for implementing the language's rich query model, which led to many applications only implementing one or two ways to access objects, often with bugs. That was the source of most of the annoyances with AppleScript.

sriku 12y ago

AppleScript was originally conceived to be easy enough for non-professional programmers to read and write, with the history of Hypercard behind it. This is for those rare occasions when they needed to automate something that they do with multiple applications manually. At one point, you were able to hit "Record", do the things that you needed to be automated and boom you get a script that you can begin to massage into something reusable. You didn't need to be a programmer to read this recorded script and you didn't need to know English to read/write it either (it was available in other languages). It looks like Apple realized that automation is the core problem they need to solve and made .. Automator instead, which is based on the same underlying piping - OSA. edit: Back in 1998/99, I even wrote a web server entirely in AppleScript - it was a platform for our research lab to share, debate and record ideas.

wlesieutre 12y ago
Automator even has the same "record" functionality for repeating tasks in a UI[1]. The direct Automator actions like "scale image" are cleaner when they exist, but including Automator actions with 3rd party applications didn't catch on as much as it could have. Some apps have them (Pixelmator comes to mind), but for the most part it doesn't have the support that AppleScript used to. It's a bit sad that we now have easier automation (via IFTT) in a huge pile of webapps than many native programs where it hasn't improved in the last 10-20 years. [1] http://www.macosxautomation.com/automator/features/virtual-user.html http://www.macosxautomation.com/automator/features/virtual-u...
- sriku 12y ago
  The core of AppleScript is a protocol defined as the OSA. This, as Camillo pointed out, is super close to REST and that suggests a possible evolution of the underlying idea as a glue system between "web apps" including desktop apps. Actually, even an 'evolution' isn't necessary, since AppleScript can directly work with Objective-C frameworks, instantiating objects, calling methods, etc. So this gluing between the desktop world and the networked world already exists.
tlrobinson 12y ago

hrktb 12y ago

Applescript was only a front end for OSA, for instance there is/was a working perl front end for OSA. The reason it never really took off is mostly due to OSA itself, and not the scripting language I think. For instance most of the Adobe product don't care about OSA and offer a Lua extension mechanism instead (even there, I feel they only cared avout filters and publishing modules). Or even iPhoto had severe limitations on what could be done through the scripting interface. The Finder has perhaps the most useful interface, but anything done there can also be done in the shell IMO. There must be other apps exposing very useful functionalities to OSA, but I haven't see many.

gcanyon 12y ago

Others have touched on this farther down, but this always sets me off: AppleScript is not confusing because of its native syntax. It's confusing because of the inconsistent, often contradictory, incomplete, and sometimes just insane dictionaries provided by the various apps you access with AppleScript. Switching to JavaScript will do exactly zero to fix that. However, there appears to be new functionality inherent in the implementation, including better integration of native code (oddly, the examples are in ObjC instead of Swift), and I assume this will be faster than AppleScript. If this increases the popularity of writing scripts, then perhaps app-writers will improve their dictionaries.