Hacker News Reader

Comment by mbauman | Hacker News Reader

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.

View on HN

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.

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

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.

That reminds me... the first "web app" I ever built was a home automation interface, hacked together with AppleScripts, because that's all I could figure out how to do on my Mac in high school (circa 2001). I don't remember how the webserver portion of it worked (but I definitely didn't implement it myself)

I was trying to remember that as well, but I think I now do - it's the "Internet suite", which has a CGI handler implementation.

MacHTTP / WebStar from StarNine by Chuck Shotton! He was also VP of Engineering at Quarterdeck, another pioneering company.

http://www.astronomy.pomona.edu/archeo/WebSTAR%20Doc.pdf

http://infomotions.com/musings/tricks/manuscript/0800-machtt...

http://tidbits.com/article/6292

It had an AppleScript / OSA API that let you write handlers for responding to web hits in other languages that supported AppleScript.

I used it to integrate ScriptX with the web:

http://www.art.net/~hopkins/Don/lang/scriptx/scriptx-www.htm...

The coolest thing somebody did with WebStar was to integrate it with HyperCard so you could actually publish live INTERACTIVE HyperCard stacks on the web, that you could see as images you could click on to follow links, and followed by html form elements corresponding to the text fields, radio buttons, checkboxes, drop down menus, scrolling lists, etc in the HyperCard stack that you could use in the browser to interactive with live HyperCard pages!

That was the earliest easiest way that non-programmers and even kids could both not just create graphical web pages, but publish live interactive apps on the web!

Using HyperCard as a CGI application

http://aaa-proteins.uni-graz.at/HyperCGI.html

http://pfhyper.com/hcfaq/hcfaq4.html

http://www.drdobbs.com/web-development/cgi-and-applescript/1...

  The following is taken from the LiveCard web site
  (http://www.royalsoftware.com):

  "LiveCard is a HyperCard add-on that enables remote users to browse
  and interact with HyperCard files, called "stacks", on your web
  server. Once installed, you'll be able to serve any HyperCard stack
  without extensive preparation - often with no preparation at all.
  This means you have all the advantages of HyperCard as part of your
  server solution, plus you can now serve those stacks to anyone on
  the Web, regardless of whether they're using a text- or
  graphics-based browser and regardless of their platform: Macintosh,
  Windows, UNIX, whatever."

  "LiveCard implements a CGI (Common Gateway Interface) between
  Macintosh servers, such as WebStar, and HyperCard. It makes the
  HyperCard interface available as high-resolution, compressed
  image-maps and HTML form elements, and transforms user gestures in a
  web browser to a format HyperCard can understand. LiveCard
  translates between HTML, HTTP, and HyperCard "on the fly," requiring
  little or no preparation of the HyperCard stack. LiveCard generates
  HTML dynamically - as stack content and functionality changes, these
  changes are reflected live in the remote users browser."

  What does this mean for you? Well, if you have access to a Macintosh
  web server running WebStar, MacHTTP, or similar server software that
  is cgi-aware, you can serve your stacks using LiveCard. LiveCard can
  generate an HTML forms page using the text fields on the card, an
  image map with stack graphics and buttons that responds to user
  clicks (although the buttons can't highlight), or a combination of
  the two. In addition, each generated page has a header and footer
  that can be set by scripting...and is HTML aware. This gives an
  incredible amount of flexibility.

  Note that LiveCard requires a Macintosh web server (not really a
  criticism... I love Mac servers...but you do have to have access to
  the server, and it *has* to be a Mac, since LiveCard is
  HyperCard-based). And to fully realize the potential of LiveCard,
  you need to learn some new commands...but there aren't too many, and
  they make sense. Plus, the examples provided are very helpful. At
  this point in time LiveCard has a limited ability to work with
  QuickTime...you can kludge your way around the limitations, but if
  your stack relies on a lot of QuickTime, you have to do some serious
  modifications. Rumor has it that future versions will have more
  QuickTime functionality. But for static graphics (color spoken
  here!), there are no modifications.

  Where LiveCard really shines is in the area of forms and databases.
  I created a stack to be used for a course I was teaching...very
  simple, with about 5 text fields for the students name, college,
  major, and a topic they were interested in. I then just dragged this
  stack into my server folder where LiveCard resides. That was it. I
  called up my page on a browser (remember, any browser, any
  platform), went to the LiveCard page, clicked on the link to my
  stack (automatically created by LiveCard), and there was a
  forms-based page with all of the fields...including their labels. I
  filled the page out and hit submit. Voila...the data appeared on the
  stack residing on my server. Now that is cool.

  Pros: Can serve your stack mostly without modification. Can use
  externals in the stack. Browser is *completely* platform independent
  since a plug-in is not required. Data can be easily transferred
  between web page and stack. Leverages existing HyperCard stacks,
  especially databases and order processing.

  Cons: Requires a Macintosh web server. Limited ability to work with
  QuickTime. Can be a tad slow. Lose button highlights and card
  transitions.

  3. Convert your stack to a SuperCard project. Allegiant (makers of
  SuperCard - http://www.allegiant.com) has recently released
  Roadster, which is a plug-in for Netscape navigator. Roadster is in
  public beta at this time (December '96), and is available for both
  Mac *AND* Windows 95. Can anyone say cross-platform? Before you get
  too excited, remember that you first have to convert your HyperCard
  stack into a SuperCard project. This is fairly painless
  however...unless you use externals. Externals present two problems
  for the SuperCard/Roadster approach...they don't always convert, and
  more importantly, at this time Roadster does not support *any*
  XCMD's. This is due to security concerns (you could do some nasty
  damage to a client computer...kinda like a java applet gone bad). A
  future intranet version of Roadster may show up that supports
  externals. Another potential problem is that Roadster only supports
  a single window. Now this might not be a problem for HyperCarders,
  since one window is the norm. But for dedicated SuperCard people
  that have grown used to multiple windows in projects, some tinkering
  has to be done.

  Since Roadster is a plug-in, you get some more good news and bad
  news. The bad news is that people have to download the plug-in and
  install it into their Netscape Plug-ins folder before they can view
  your project. The good news is the plug-in is free, and your project
  runs in the browser exactly as it does on the desktop...buttons
  highlight, transitions work, etc... And perhaps even more
  importantly, Roadster is available for Windows, so you can finally
  get your stack into the hands of the unfortunate Intel-laden masses.

  Pros: Project looks and runs just like on the desktop.
  Cross-platform. Ability to transfer information via forms commands.
  Ability to cache and preload graphics. Very good with external media
  such as QuickTime, audio, etc.

  Cons: Have to convert your stack. Browser requires plug-in. Lose all
  functionality of externals.

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.

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.

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

I never understood the cutesy naming schemes. What's wrong with .filter or .where.

I agree, but I guess .filter or .where could be more difficult to understand for beginners.

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

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/apples...

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

doWhatImThinking();

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.

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

So, yes :).

Looks very Ruby-esque.

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.

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.

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.

Reply on news.ycombinator.com