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.
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.
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)
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!
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.
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.
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.
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.
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.
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.
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 cloud apps, will OSX app developers still take the time to expose scripting functionality?
> 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.
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”.
Using words instead of punctuation isn't so bad --- I would be willing to learn a creole pidgin in exchange for being able to program without punctuation characters and using Voice Recognition. But three-word keywords like "is equal to" just make it impossible to intuit the AST from the language, and intuiting the AST is ultimately what makes a programmer feel comfortable with the languages. In this regard, AppleScript was like SQL but worse.
Python, OTOH, strikes a decent balance (assuming de-punctuating is your goal), avoiding punctuation by using keywords for 'and' and 'or' and 'not' , without making the grammar incomprehensible.
AppleScript is not a solid argument against natural language derived programming languages in general. AppleScript's problems have more to do with the fact that it looks like it should be flexible and powerful but in reality it is fairly limited and inflexible (and its documentation and error reporting are terrible, compounding its problems).
I think AppleScript's problems have more to do with the fact that it relies too much on external parties to do its stuff. The moment you do
tell application "foo"
every bar whose third baz is frob
end tell
whatever you write in that tell phrase gets executed by application "foo" (the logic runs in the process, and has to be written by the implementers writing the "foo" application). Implementing that flexibility is lots of work and hard because Apple did not supply much support libraries (1). Because of that, all implementations were incomplete (and differently so) and buggy. That "and differently so" was the main reason one cannot get comfortable writing AppleScript. Even if the above worked, there was no guarantee that, for example
tell application "foo"
the third baz of every bar
end tell
worked.
The essence of AppleScript goes very far:
- The editor imports syntax from "foo" the moment it sees that tell application "foo" block.
- When compiled, it converts that into a standardised binary format (an Apple Event)
- When run, AppleScript sends that event to "foo", and "foo" parses and executes it.
In essence, it turns application "foo" into a service that shows its internal state in its GUI (in 1993).
(1) in their defence, I don't think they could have written good support libraries in the language of the day. A few C++ 'interfaces' in header files might have helped, though.
Yes, implementing the object-oriented Apple Event Object Model (the conceptual model used to refer to properties and elements in another application) can be challenging to implement in a non-OO language like C. These days, Cocoa Scripting (in the Foundation framework) provides most of the code to map from Apple Events to Objective-C method calls, and using a language like Objective-C makes writing the rest of the code much more straightforward.
HyperTalk was brilliant because everything seemed to just naturally work. The grammar and object model were both highly intuitive – you really could just guess the right syntax.
AppleScript and HyperTalk are aesthetically very similar but every time I have to write something in AppleScript I get oddball parse errors that I can never decipher and I need to randomly try things until an approach succeeds (for reasons I don't understand) or I give up.
Where HyperTalk was friendly and forgiving, AppleTalk is punishing.
I loved HyperTalk, but my experience with it was that:
A. Almost any English sentence was grammatically valid.
B. Almost none of those sentences did what you expected.
I find AppleScript a more regular language overall. I think the biggest difference is that HyperTalk was built in to the HyperCard environment, and therefore most of the “language” was in fact just HyperCard-supplied functionality, whereas AppleScript has very little built-in functionality, and sometimes this surprises people when they discover that it’s up to some other application to decide what the behavior of the script is.
SQL is fantastic for relational data - it maps pretty closely to relational algebra.
About all I'd change is placing the column names after the table/object names - "FROM table1 SELECT col1, col2" instead of "SELECT col1, col2 FROM table" because it makes code assist features easier. (Microsoft did this with LINQ)
SQL makes sense, but at its core, it's a query language, not a programming language. You can do lots of arbitrary computation with it if you want and use it for things it's not good at, but for its intended purpose, it works pretty well.
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...).
If anyone wants to do stuff similar to this on earlier versions of OS X (but arguably even more generally) or on iOS they should look at one of my projects, Cycript, an Objective-C/JavaScript hybrid with a highly-bridged Foundation/JavaScriptCore object model that can inject code into running applications.
(I expect to have the ability to introspect and manipulate Swift objects in the near future as well, and have a talk on preliminary research of low-level Swift object runtime metadata at #AltConf a couple days ago. The console will also support some of Swift's syntax, such as the named-argument-style method calls.)
The Apple thing only works on 10.10 (which most people reading this wouldn't be using currently), so I am saying that there is an option for earlier systems. Cycript actually doesn't work on 10.10 right now (well, it does, but it is frustrating to use as you have to keep saying this. before global variavles) due to a change made in JacaScriptCore that I am unhappy with (talked to some people at Apple, filed a bug with WebMit, and am checking with a friend of mine on the ECMAScript committee), but I have a reasonable workaround I can use for non-Cydget use and for Cydget crazy one-off Substrate hacks are fair game, so I should have everything fixed soon for a new release.
Oh Javascript. This has been said so many times before, but why, oh why, has the world converged on this particular language?
Why aren't there saner alternatives to Javascript in browsers? We have so many languages at our disposal, why choose Javascript? Why don't people realize that web programming is not great because of Javascript but despite Javascript?
We are bound to Javascript on the web because browsers, for whatever reason, don't support anything else. But we don't have to make matters worse by dragging this weirdo language unto the rest of the programming world.
But who am I kidding, AppleScript may be one of the few languages actually worse than Javascript.
You already know all the good stuff about weak typing and equality.
But let me give you a few recent examples I stumbled over:
- Javascript can not format numbers with leading zeros.
- Handling binary data is increadibly painful.
- Object oriented programming is really convoluted.
- Lack of classes and modules makes code structuring hard.
True, it could be worse. But Lua, Ruby, Python, Perl, Scheme, Clojure, and many others are much better languages with very similar feature sets. And then there's a whole host of languages with different features. I just don't see why you would Javascript in an environment where all these other alternatives are available.
"Because JavaScript is the language of the web browser, and because the web browser has become the dominant application delivery system, and because JavaScript isn't too bad, JavaScript has become the World's Most Popular Programming Language. Its popularity is growing. It is now being embedded in other applications and contexts. JavaScript has become important.
Microsoft and co ditched ES4.Let us be reminded that the only vendor pushing for it was Adobe.
So no it couldnt have happened with a better language,in fact it didnt,because whatever vendors say today,they dont want the web to be too powerfull.
Really? I don't see anything particularly wrong with Javascript... I mean, sure it's no PHP, but compared to travesties like Lua (1-based, seriously? What year is it again?) and bloated, convoluted semantic messes like Python and Ruby... well there aren't many choices left!
Google, Mozilla, Microsoft, and Opera (and obviously Apple) haven't exactly been jumping at the opportunity to deprecate Javascript in or out of the web. I mean hell, now we have technologies like Node and asm.js that make Javascript the fastest dynamic language in existence! People are even using it in embedded hardware now! So it can't be nearly as bad as people say.
A lot of people in this thread have misconceptions about what AppleScript is and what it means for JavaScript to be an alternative. I recommend watching the WWDC session [1] if you can, and skip to 16 minutes in (through minute 20) for a quick explanation of what this actually is.
TL;DR shell scripting for the GUI, not a way to build Mac applications (which you can already do with JS).
Edit: video link
Double edit: Looks like I'm slightly wrong about using JS to build apps this way. You can bundle scripts as applications, and OSA can create windows and controls, so you could hypothetically build whole apps this way. But I'm not sure I would want to.
Given Apple's well-known antipathy to the idea of browser engines other than WebKit and scripting languages other than JavaScript on iOS (yes, yes, I know you can find Python/Lua/Lisp/whatever apps on iOS; I mean as a general rule and for inter-app automation), could this be a prelude to allowing some sort of sandboxed-app automation interface on iOS? That is, allow a JavaScript implementation running on iOS to "drive" apps via this object model?
(Genuine question here. I have no idea whether I'm blowing smoke or whether this is a plausible long-term direction for Apple to take iOS.)
Genuine answer here. There's no need to apologize for not constantly immersing yourself in the workings of Apple platforms. :-)
JavaScript is just another interface to Apple's "Open Scripting Architecture (OSA)." Previously, AppleScript was the only way to use it. The fact that they added another language indicates nothing about whether OSA will ever come to iOS. My guess is it won't; the new extensions APIs will likely handle any inter-app communication Apple wants to allow, because they are designed with iOS's sandbox model in mind already.
Put another way, Javascript is to AppleScript with respect to OS X automation, as Scala is to Java on the JVM. The existence of Scala does not indicate that the JVM will be ported to the Haiku OS. (There may be a better analogy but that's what I came up with.)
There are other language interfaces to OSA. Frontier's UserTalk was an early implementation (and much more useful than AppleScript IMO) IIRC, there are also Python and Ruby bindings as well.
Javascript in this case has nothing to do with web browsers. It is simply a scripting language used to manipulate OSA (Apple's cross-application automation API in Mac OS X). Since OSA is not part of iOS, this likely won't affect iOS at all.
You actually can use Javascript to automate iOS apps running in Instruments (one of Apple's developer tools). This is used for automated UI testing in the iOS simulator or while your iOS device is tethered to a Mac. This has been around for a couple years and there's no indication that it will ever be permitted in released applications. There's actually no reason to enable it – it's only useful for snooping on apps (good for developers, bad for users).
For developers, I think you can write ui automation tests in javascript for your own app during debugging/testing.
In the general case, for published apps, I'm not seeing it happen. Apple seems to be super focused on sandboxing and separating components on iOS. Even with the new iOS8 extensions, everything needs to be user triggered and even then, extensions live on separate islands.
It's doubtful they'll change that model since it would defeat the "you can't break your idevice even if you tried" feeling for end users and the app store.
so, I'm a little confused here - more than a year ago, the Gnome Project picked Javascript as its primary dev language and it was linked here on HN (https://news.ycombinator.com/item?id=5169599)
That entire thread is around how Javascript is a bad paradigm for desktop. But, this entire thread is how amazing javascript is going to be for OSX.
Let me add that the JS programming model of Gnome is what powers http://extensions.gnome.org - and I have my own extensions in there. Also (and correct me if I'm wrong) the "GObject Introspection" mechanism is fairly analogous to OSA.
So, is there a underlying technical or implementation issue that makes it good on OSX and bad on Gnome ? use case? technology ? OSA ?
Applescript is used for automation of already existing applications which will still be written in C++ or Objective C. Applescript, a proprietary language with no other uses, is just being replaced by a much more common language in Javascript so people won't need to learn a new one to automate apps. People don't generally write applications using Applescript and they probably won't be using Javascript, so there's little overlap.
In GNOME Javascript is being used to write the applications in the first place. There is total overlap between Javascript and C/C++.
People see the GNOME choice as both redundant and reducing performance of desktop apps while people see the Apple choice as simply using a common language instead of a proprietary one for scripting.
not entirely true. Gnome has a first class language - Vala [1] - that is for writing performant system level applications. And the community is quite active as well - https://github.com/trending?l=vala
If you think of automation, there have been attempts at bringing flow based programming to the Gnome-JS engine (think of it as Quartz Composer integrated into the desktop) [3] - plus the fact that http://extensions.gnome.org is about as automatic as you can get to customize the desktop.
Is it a difference in positioning ? Because honestly I'm a little befuddled on why all the developers on HN get supremely excited about JS on OSX... and not something like NoFlo.js integrated into Gnome.
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.
Because then there is no way of conveying the order of the parameters. In this case, it's ambiguous whether the method we are calling is colorWithRedGreenBlueAlpha, colorWithGreenBlueRedAlpha, etc.
I'm going to miss AppleScript - in both obvious senses of the word. It was a language I used to swear by, and at. I spent hours getting scripts to work, so I've became used to the language's infelicities, but was always frustrated by the lack of tools. Here, for example, is how I gather you're supposed to change the case of a string:
on change_case(this_text, this_case)
if this_case is 0 then
set the comparison_string to "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
set the source_string to "abcdefghijklmnopqrstuvwxyz"
else
set the comparison_string to "abcdefghijklmnopqrstuvwxyz"
set the source_string to "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
end if
set the new_text to ""
repeat with this_char in this_text
set x to the offset of this_char in the comparison_string
if x is not 0 then
set the new_text to (the new_text & character x of the source_string) as string
else
set the new_text to (the new_text & this_char) as string
end if
end repeat
return the new_text
end change_case
I'm assuming that this will be easier using JavaScript... :)
There has been no statement that AppleScript is going away or being replaced by JavaScript for Automation. This is simply a case of offering users more choices.
AppleScript’s primary target audience is first-time and casual programmers. (Of course, there are professional programmers writing applications and utilities in AppleScript, too.)
You know what's pretty cool? This potentially allows native MacOS applications to be written in JavaScript... Not that I can see any reason to do that.
You can build double-clickable "applets" in AppleScript and JavaScript, but the OSA interface isn't really made for app development, just automation.
However, they do expose all Cocoa and Obj-C APIs to JavaScript, so anything is possible! They even do a demo of a standalone temperature converter at the end of the WWDC session.
I'm pretty familiar with ObjC-Javascript integration and have been working with it for a while. This change offers a nice direct system interface for automation, and one that has access to all of Cocoa.
I also didn't intend to put Javascript down at all - its more that the more complex part of building a MacOS app is working with Cocoa, and Javascript will make that more complex, rather than simpler, just because of the impedance mismatch.
I'm not sure there's a compelling use case for building such apps, but it's still pretty cool!
I think you were being downvoted because some people (myself included) roll their eyes when they hear about Javascript yet again. It goes double when there is a good language already out there (I accept Objective C with its warts. Swift actually has me excited to make something).
It actually kind of cool. And the Temperature Converter example showed a lot of the dynamic nature of the objective C runtime. This one presentation actually piqued my interest in looking at os x scripting.
After a quick search I couldn't (readily) find any links about writing Mac apps in Javascript. The Strongloop seems to be for iOS7 only. Where would I find out more about this?
As an aside: if you want to use JS /today/ as an OSX Window Manager (hotkeys, resizing, switch screen etc), you should check out:
https://github.com/sdegutis/Phoenix
I've been using it for a couple of months now, and it's been glorious! So being able to do more things in JS makes me very excited.
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.
> Scripting additions (plugins for scripts) can be used to enhance the functionality of applications. The OS has a set of standard scripting additions available. These offer things like speaking text and user interaction dialogs.
I was watching the talk and thinking all the time, Apple just discovered OLE Automation.
Yes, I know that Open Scripting Architecture is also quite old, but having now JavaScript bindings and the types of demos they made, just reminded me of it.
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.
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.
The one thing I still like about AppleScript is the GUI scripting. I don't know of any other way to control the mouse position, clicking, and keyboard input using a programming language.
One time I had to fill out a few thousand pdf files and print only select pages from them (like pages 2-4 and 14-22) for a client. I used applescripting because it was easy to write (took about half an hour) and worked consistently. Are there any other ways to do GUI scripting in OSX?
If I were a Mac user I could really get behind this if only for the fact that it means support for any language that can compile to Javascript (particularly Clojure)
You know, Apple essentially made a new way to build full-fledged Cocoa applications using a dynamic interactive language. You could literally write a whole GUI app in a single JS file without even touching Xcode. That's... kinda awesome.
I remember that Windows have had very powerful JavaScript scripting for ages (windows xp or earlier), later they forgot about it and created Powershell. Interest ing to see apple now using the same idea on their platform after so many years.
Haven't wrapped my brain completely around this yet, but I wonder if it's going to allow for some cool (and/or dangerous?) crossover write-once-run-in-browser-or-locally apps.
I don't think that's the case. AppleScript is the equivalent of shell scripting for GUI appls.
You don't write applications in AppleScript; you use AppleScript to control other applications in an automated way.
You can write AppleScripts with simple dialog boxes and such, just as you can write interactive bash scripts. And while you could theoretically implement an application entirely as a shell script or batch file or AppleScript, it'd be a bit like mowing your lawn with a pair of scissors.
While never particularly popular, both Apple (AppleScript Studio and subsequent AppleScript Xcode templates) and third parties (FaceSpan) have provided full IDEs for developing applications with AppleScript.
Incidentally, I'd still mostly agree with your comment, as the underlying script runtime isn't really designed with application development in mind. For example, I'm pretty sure Xcode debugging support for AppleScript doesn't even include breakpoints or related features like single-stepping (Apple's Script Editor certainly doesn't), and that Script Debugger had to pretty much implement its own AppleScript runtime to support these features.
On another side note, while Yosemite is the first time Apple has supplied or supported JavaScript as an OSA language, third parties have integrated the Mozilla JavaScript engine into OSA in the past in what I believe is an abandoned project (Google "JavaScript OSA").
This is cool because as a programmer I found AppleScript difficult to pick-up quickly. However, after a recent foray into writing scripts for iPhoto and iTunes, the api's and documentation of those apps totally turned me off.
I'll be interested once I see some succinct JS to show me most played songs in last week, or recent photos imported from iCloud.
This is just so insanely insane. I have such mixed feelings about this.
On one hand, it's really exciting that Apple is taking these huge steps in making our lives as programmers easier. And yeah, I wish they had done this when JSTalk came out, but better late than never.
On the other hand, it really sucks that JavaScript is the new universal scripting language. Swift and JavaScript are now the two blessed languages on Apple platforms. I mean, I get why, but man, JS is just so awful.
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.