Having visited a lot of my regular developer forum hangouts this week, there has been a lot of posts on these other sites regarding Apple’s new “Swift” programing language.
I think the lack of response, Mark, is the result of not knowing enough about it. I’ve downloaded the manual, but can’t say I understand how it will integrate with AS. One feature worth noting is that Swift can be run interpretively, line by line.
This is what I wrote in reply to a similar question elsewhere:
At this stage at least, it probably doesn’t at all. ASObjC is a way of calling methods on Cocoa classes; what’s done with the results of doing that is standard AS. You use repeat loops, not for loops, you concatenate strings with &, etc, etc. Many of the things that Swift looks to be bringing to the programming table are irrelevant in the context of bridging to AppleScript. Of course it could all change some way down the track, but at this point it would seem a lot of effort for not a lot of reward.
On the other hand, some kind of “do Swift script” command might have interesting possibilities…
After browsing the manual myself, you could at first think it is a language for console applications, but after reading in more depth, you can see that Apple does seem to intend it to be used as a GUI application development language, to sit along side Objective-C.
I was’nt thinking so much about it complimenting Applescript, more of wether it could be a replacement for ASOC, like everyone here I have invested a lot of time and effort into ASOC, and still enjoy the simple pleasures of vanilla Applescript.
After looking at the syntax of Swift, it seems to me that an Applescripter could adapt to it very quickly, and the fact that ASOC will probably never be ported to iOS, it does beg the question, should us scripters be looking at Swift as a replacement for future App development ?
I know it is still to early to say for sure, but I feel that this could be the futre for Apple developers and scripters, especialy if you can see the day when Apple’s portable devices and desktop computers use the same operating system.
It’s certainly food for thought, and personally I’m very excited to see what the final destination for Swift will be.
And Shane, I hope you’ve got started on the new Swift learning / training book.
As I’m a big fan of your ASOC books.
FWIW, I think that, longer term, they see it as much more than that.
Well it could, but then so could Objective-C.
Is the average scripture really comfortable with things like closures, generics, currying, etc, etc, and still happy to drop back to Objective-C when needed? I don’t really think so.
As an alternative to Objective-C: yes. As an alternative to ASObjC? Not unless you want to get a lot more serious about programming.
Beneath that beguiling introduction, Swift is a very serious language, and will become more so. Writing a book on that is way out of my league.
I guess only time will tell as to the future of Swift, and software development for Apple hardware.
Like you Shane I think Apple have big plans for the Swift language, possably even as a replacement for Objective-C, as that language is decades old, I cant’t beleive they have been developing the Swift language for the past four years, without having the future decades in sight.
Also I don’t know if anyone noticed the pre release notes for OSX 10.10, it looks like Apple are also adding JavaScript language scriting and automation capabilities.
As both Applescripter and ObjC developer, I look at Swift as Apple’s long term future. Just as ASOC extensions slowly crept into vanilla ASOC, and now full ASOC bridge and libraries, Swift will be a full complement, and probably complete replacement for ObjC. It might be 5 years or more. But Swift will be developed and evolve quickly and if past is prologue, Apple will flush out the old and fully embrace the new at some point. Any ObjC devs would take heed to learn swiftly (haha) the new language.
Chatter on the ASOC-dev list about the JS-ASOC bridge leaves me wondering about ASOC since the underlying Apple-event framework sounds like it has not changed much. Actually making apps more scriptable, easily, would make me happy. Adding AS support is super-arcane and confusing currently. But I have no hopes Apple really will put a lot of focus on that.
I tend to agree with you on most points, I too beleive that the new Swift language is intended as a future replacement for Objective-C, which they inherited/purchased as part of NeXT, although I won’t be dissapointed with that myself, as I’ve never particularly liked the Objective-C language syntax.
As for the future of AS I really don’t know, but the introduction of Java Script in OSX-Y sends alarm bells if you like AS as I do, although I know it’s a bit of a mess these days, but I can’t help like it’s quirky nature.
The future of ASOC has to be questioned as well, as I don’t beleive that it will ever be ported to iOS, and you have to imagine Apple not doing a lot more development on it either, although I personally prefer it to Objective-C, even with it’s limitations, and it’s similar quirky nature like vanilla AS.
In saying all that, I don’t believe scripters should be worried, because I do beleive that Apple will always want to cater for the scripting and automation crowd.
Although it might be a case of learning new ways to do what they do now, but that could be open for debate, and we will never really know that for sure just now, only time will answer that question.
So for the moment we shall have to watch this space.
Why? Surely more potential scriptures, whatever the language, can only encourage developers to make their apps scriptable, and that would be a good thing for AS.
I did’nt mean alarm bells for me personally Shane, I’ve used Javascript in the past in my MS operating system days, and don’t have any issues with using it again if Apple steer things in that direction, but what I meant is in the sense that the future of AS scripting language could be brought into doubt, which I would miss, along with many others I suspect.
But none of us really know at this stage, but for sure there are no garentees for any currently used programming or scripting language, with these latest announcements from Apple.
I totally have missed this post but I haven’t mentioned shift because it has no direct relation with AppleScript nor AppleScriptObjC. AppleScript is completely developed in C, as the biggest part of AppleScriptObjC but we don’t discuss that language either here while it’s the most important language for AppleScript as writing Scripting Additions.
The correct naming is in fact AppleScript English Dialect. I’m nit picking on this one because AppleScript and it’s dialect are completely two different components that works on top of each other instead of working together. in the past 3rd parties have tried to introduce the JavaScript syntax on top of AppleScript but there were not enough people using it. The end of the AppleScript English dialect (also the name of the first AppleScript Language Guides, I have one from 1994) simply doesn’t mean the end of AppleScript. I’m not saying it doesn’t mean that, just that it doesn’t have to mean that. It can mean the end of the AppleScript interpreter but still doesn’t have to mean the end of the AppleEvent manager which is also part of the AppleScript umbrella.
I’m also back (2 days from now) to writing my own scripting addition. Back in Mac OS systems I did an attempt earlier but as some of you know the main event loop wasn’t developed to deliver high performance and you couldn’t send much events through your system (100 each minute). The last Snow Leopard update for scripting additions has made some drastic changes. I completely dropped leopard and earlier script addition support and it’s also a lot faster. I can send 10,000 events withing a second on my 3 year old MBP i7. It can seem for an AppleScript writer that it’s falling apart but you can see there is still a lot of development if you’re doing more than just writing plain AppleScript code.
Still all my arguments doesn’t make your conclusion/expectation false, it could be that AppleScript is completely gone in next OS version. But there is still a lot of development under the AppleScript umbrella and I don’t think that’s all going to waste. Yes, AppleEvents are maybe outdated but they’re working properly and standing no-one in it’s way. In fact the “open with…” functionality is still using AppleEvents, even in Mavericks as many other non-scriptable applications all rely on AppleEvents.
You are confused between ‘dialects’, which was an early internationalization feature of the AppleScript component, and JavaScriptOSA, which was a third-party language component by Late Night Software with a built-in (though flawed) Apple event bridge; i.e. no relation or connection to AppleScript itself.
IIRC, Apple added support for a few localizations, such as French and Japanese. In theory, this meant a native French speaker could use Script Editor write an AppleScript entirely in their native tongue, save it as a compiled .scpt file, then hand it to an English or Japanese speaker who would then see the script displayed in their own tongue when they opened it in Script Editor.
Apple dumped dialects once they realized that adding new localizations turned out to be far harder than they thought it would, especially for languages that have very different grammar rules (e.g. written Japanese contains no spaces so relies on complex word breaking rules instead). Plus, of course, it wasn’t enough just to localize AppleScript’s own keywords: each scriptable application would also need to include localized dictionaries. And you can imagine how developers already suffering the high cost of implementing Apple event support in the first place would’ve reacted to that. And even assuming all keywords were successfully translated, that would still leave user-defined identifiers and comments in the original author’s tongue.
So, great idea on paper, way too difficult and costly to pull off in practice - especially after Apple management gutted the AS team and its resources shortly after its first release.
One dialect they did add that might have been worth keeping was the “programmer’s dialect”. This used brackets, braces, and other symbolic characters in place of AppleScript’s English language-based keywords in order to make it look more approachable to existing programmers with a C/Pascal background. But I don’t think that or any other localization ever made it into a public OS release, so we’ll never know how that syntax might’ve gone down with developers in practice.
Here’s Dr William Cook’s HOPL paper about AppleScript’s early history; it’s well worth a read:
So anyway, there’s no way Apple can remove the AppleScript component after 10.10 comes out, because current AppleScript users - especially those in the print industries - have a huge amount of existing AppleScript code that will not run on anything else. They may eventually decide to move it to legacy or deprecated status and encourage everyone to begin using JavaScript instead, but there’s still no way they could yank it completely until several more years have passed unless they want those users beating down their door with pitchforks and flaming torches.
(The other thing I’d say is that JXA’s AE support as demonstrated in WWDC’14 was rubbish compared to AppleScript’s own. But we’ll see if that gets sorted out by the time 10.10 and/or 10.11 ship. It ain’t all over till the fat bloke sings…)
You’re totally right… I always thought that AppleScript English dialect was another scripting component than AppleScript Japanese dialect. Thanks for pointing that out.
I’ve read that paper a few years ago to get better insight how AppleScript will works internally. It’s indeed an very interesting paper. The most beautiful paragraph from that paper to me is:
