JavaScript as an alternative to AppleScript on OS X Yosemite

Does this mean AppleScript will actually be documented now? The problem historically has been code is written from random examples, without actual reference docs that make it possible to discover what's available.

The thing i'm not totally sold on is that for arg-free alloc/inits, you can forego 'calling' those methods at all so you get code like `task = $.NSTask.alloc.init;` but sometimes you have code like `ObjC.super(this).init;`. So although you're actually initializing a new object, casually glancing through the code makes it seem that you're actually just accessing a property on NSClassName. Jstalk/cocoascript i think get this right with `NSWhatever.alloc().init()`.

Still, it's a bit weird and it makes me think that the poor folks working on this didn't know what the swift folks were doing because if they had, i suspect that the cocoa-bridged syntax would feel even more natively javascripty than it does right now rather than what's here. For comparison

    // in swift
    var color = UIColor(red: 0.61, green: .71, blue: .23, alpha: .8)

    // in js for automation
    var color = $.UIColor.colorWithRedGreenBlueAlpha(.61, .71, .23, .8);
    
    // but why not use objs for named args?
    var color = $.UIColor({red: 0.61, green: .71, blue: .23, alpha: .8})
    

Of the two, the swift feels the most js-native to me because you can easily hallucinate the {}s from the third example. But even if you're creating a js bridge and you're apple, why even force people to deal with alloc/init anymore? Even the registerSubclass syntax feels like a concession

Don't get me wrong, I think it's great that we're getting better applescript support via js, but it's definitely an area where the implementation feels like a step back from cocoascript and jstalk, at least with both of those the syntax highlighted when you were engaging in nonidiomatic behavior but at least both tried their best to paper over it.

What should have been a lightweight approach actually feels more heavyweight than writing equivalent code in swift instead, which makes me sad because i like js and i would have really liked for this to have been more approachable.

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.

In fact, you can use either “whose” or “where”, and the AppleScript language guide refers to this as “Filter”:

" rel="nofollow">https://developer.apple.com/library/mac/documentation/apples...

For the record, AppleScript is not “natural language programming”; it is merely more similar to English than most programming languages. As with most mainstream programming languages, human terms (usually English) are used for keywords like “if”, “then”, “else”, “while”. It still has a very limited and structured grammar, like most programming languages.

In deference to the expressive flexibility demanded by humans, it does provide a few alias terms (“=“, “equals”, “is equal to”) and a few places where something can be written either left-to-right or right-to-left (“name of document” vs. “document’s name”), but even that is common in other languages. e.g., document.name vs. name(document), foo(bar.baz()) vs. bar.baz().foo(), and C’s support for both ”! && ||” and “not and or” operators.

Obviously, tastes vary, and I’m not trying to convince anyone that they should like something they don’t, but often people who complain that AppleScript is unlike languages they are more familiar with have only taken a cursory look at examples of AppleScript and are unaware that it has a syntax that is in fact similar to other languages. The primary differences are that it is very light on punctuation and prefers using descriptive words over abbreviations, because its goal is to be approachable for first-time and casual programmers. Even for AppleScript experts, this often helps make understanding or maintaining code easier.

Personally, I’d like to see AppleScript support some more “compact” syntax, like square brackets for array references, but I do not think it’s reasonable for AppleScript’s target audience to have to learn the meaning of “a ? b : c” before they can read simple conditional statements like “if a then b else c”.