Using Swift as a Scripting Language - TidBITS

Comment on this news article

Using Swift as a Scripting Language - TidBITS

http://news.google.com/news/url?sa=t&fd=R&ct2=us&usg=AFQjCNF5L8otmK50rPnyklhxmNfnn97ehQ&clid=c3a7d30bb8a4878e06b80cf16b898331&ei=HJftU7CEI4ztwAG_tYHIBg&url=https://tidbits.com/article/14971

He’s not really using Swift Language as a scripting language, he’s really just compiling very slowly from the command line using the REPL. The example of using NSWorkspace to set the desktop looks Applescript-ish but its really a part of the Objective-C API that been around since the NextStep days. As the post author Flip W. himself says, it’s more “scriptish” than script.

Not that it isn’t useful, but it’s a creature betwixt and tween, neither as flexible and forgiving as a traditional scripting language, nor as fast a compiled. Useful at the extremes, not the middle, where traditional scripting tools shine.

By definition, scripting languages run inside of and automate a specific app/process. This is not always obvious because we tend to think of, say, a shell like bash or sh as being part of the OS but they’re just programs. Shell scripts manipulate their shell app and nothing else. Ditto for “languages” like perl, python or ruby. When you run ruby myscript.rb your telling the ruby app to run the script. The big advantage there is that the parent application e.g. “ruby” handles things like memory and final error catching.

Applescript is part of a small subset of technologies that does scripting across different applications as part of it’s core function. Inter-application/process communication is usually just tacked on to most other “scripting” languages. Applescript by design exist more to let apps share data and logic than to script any particular app. That make sit fairly unique.

In case of complied languages, no parent application is needed because the compiled code is a stand alone process/application. It’s up to each program to manage it’s own memory, errors, and code dependancies. Swift is properly classified as a compiled language. You can’t do anything in Swift that you can’t do in Objective-c and that includes sending Apple events.

Swift is an innovation in the regard that it is a compiled language that comes with a quisi-REPL. The REPL is its own app that doesn’t actually run Swift as much as it shows you it compiling Swift while executing data. It saves the state of each step as well so you can go back and forth over the same area of code without restarting from the beginning. It’s definately a powerful tool and really, really neat but under the hood it’s not akin to the perl, ruby or python apps or the REPLs.

In my experiments, you can’t really do much with the REPL so far except see how snippets of Swift code behave. It’s a training and exploration tool, not a tool for directly performing actual work. Even if they extend the REPL, there’s really no point to keeping the finished code inside the REPL. Instead, compile it and get the speed benefits of compiled code.

Swift, despite looking a lot like a modern scripting language, doesn’t have that smooth scaling to the mid-sized range. Under the hood, it looks a lot more like C++ than anything i.e. it’s a rigid, structured language. It has duck typing and optionals but just about everything else is nailed down. For example, it does’t have Objective-C’s ability to message or deal with unknown selector/method calls. It would be hard to use it to write a metalanguage/DSL in Swift which is easy in Objective-C and most “scripting languages.” Swift is designed for secure, reliable, high performance, compiled software.

Swift isn’t a replacement for Applescript because it can’t communicate with other applications any easier than Objective- can. I would doubt it could be flexible enough to be a replacement for shell scripts, perl, python ruby etc either. One of the strengths of traditional scripting languages/apps is that you can start with just a few lines of code performing a real end task and then gradually tack on features as you need, evolving the app over time. That will be harder to do in Swift because Swift like’s things nailed down.

Sure, you can plink around in a playground or REPL to get a feel, but trying to do a more than a couple of hundred lines of code that way would get burdensome in a hurry. Very quickly the relative rigid nature of Swift would start to make it easier to just switch to plain Xcode compiling and go on. Neither can easily strap on bits of pieces of code like you can in ruby or Applescript. Everything beyond a few dozen lines seems to require structure.

I’d be happy to be wrong about this and besides, the language is still in development. Things could change.

But, in theory…

Because of the REPL, there no reason why someone couldn’t write library to wrap up the Objective-C interface for OSA in Swift, that might in the end act very much like Applescript inside an application. If you could embed the REPL in an application you could in principle use Swift to control the app. If you had access to the OSA commands and an easy way to translate dictionaries to Swift, you could do inter-application communication as well.

It’d likely be a fairly big job but in the end you might have something powerful. It’s on my list of things to look into.

Model: Macbook Pro Retina, 15-inch, Late 2013, 10.9.3
AppleScript: 2.3.2
Browser: Safari 537.78.2
Operating System: Mac OS X (10.8)