Live data from Hacker News

JavaScript as an alternative to AppleScript on OS X Yosemite

developer.apple.com

61–70 of 126 posts

Re: JavaScript as an alternative to AppleScript on OS X Yosemite

#61
post #49

Earlier quoted context omitted.

Could there be any reasonable situation where one might want to load jQuery within this environment, though? (Although, I suppose, you could use another var for jQuery, such as, uh, 'jQuery' ...)

jQuery is a DOM manipulation library, it is not useful to script OS X apps. ...unless one of them exposes a HTML DOM to the scripting layer, now that I think of it.

Scripting a web browser, perhaps? :)

    tell document to write "hello world"

Re: JavaScript as an alternative to AppleScript on OS X Yosemite

#62
post #14

Earlier quoted context omitted.

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.

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.

This is about as simple as an API goes. What did you expect to see exactly?

doWhatImThinking();

Re: JavaScript as an alternative to AppleScript on OS X Yosemite

#63

I love AppleScript because whenever somebody asks, "Why don't they make programming languages more like English?" all you need to do is show them AppleScript. The functionality exposed by OSX apps via AppleScript is often incredible, but the language itself is annoying. The question is whether or not applications will support it. With the emphasis shifting away from OSX desktop applications to cross-platform and clou…

You show them AppleScript and SQL and they say "Wow, what was I thinking, english is a terrible basis for a programming language."

Well, if they think that about SQL, they are wrong.

SQL is more like math than natural language. That it is declarative doesn't make it like Applescript.

Re: JavaScript as an alternative to AppleScript on OS X Yosemite

#64
post #41

Earlier quoted context omitted.

SQL is pretty damn simple.

Why are there no production-quality implementations of the newest standard then?

1) He didn't say "implementing it" is simple. Just that the language (using it, getting started with it) is simple.

2) Vendors get a lot of benefits by NOT providing a standard implementation (lock-in, for one).

3) It's not like everybody runs around implementing every new standard that comes out. Vendors have their own timelines and priorities. Heck, we've waited how many years for CSS3 to be implemented? (and it's still missing full support...).

Re: JavaScript as an alternative to AppleScript on OS X Yosemite

#65
Not sure why people would still want to use JavaScript to interoperate with Cocoa interfaces, Swift is easy enough to be used as a scripting language and it was designed to work nicely with Cocoa.

To me it makes more sense to either go completely native with Swift and Cocoa / Cocoa Touch or use hybrid model where HTML 5 content is embedded with the new WKWebView API (aka WebKit 2).

WebKit 2 framework will become public in iOS 8 and OS X 10.10 which means hybrid HTML5/Native apps will be able to run with full speed thanks to JIT, split process model and other optimisations.

Re: JavaScript as an alternative to AppleScript on OS X Yosemite

#66
The problem with AppleScript isn't so much the language as much as the OSA[1] itself which is really hit-or-miss depending upon how much functionality any particular app chooses to make scriptable, much less actually document in its dictionary.

As to AppleScript's deficiencies, in the past I've used py-appscript[2], though apparently it's no longer developed.

1. https://developer.apple.com/library/mac/documentation/apples...

2. http://appscript.sourceforge.net/py-appscript/index.html

Re: JavaScript as an alternative to AppleScript on OS X Yosemite

#67
post #14

Earlier quoted context omitted.

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.

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.

    tell application "Mail"
        set msgs to every outgoing message whose subject is 'JavsScript'
    end tell

So, yes :).

Re: JavaScript as an alternative to AppleScript on OS X Yosemite

#68
post #5

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 langu…

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.

Re: JavaScript as an alternative to AppleScript on OS X Yosemite

#69
post #68
post #5

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 langu…

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 int…

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-u...

Re: JavaScript as an alternative to AppleScript on OS X Yosemite

#70
post #14

Earlier quoted context omitted.

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.

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.

Looks very Ruby-esque.
Post reply on HN