It’s been almost a week since Swift was announced. Initially there was huge euphoria about Apple finally releasing a new language. Now that people have been using it a bit longer there is a little more griping. Some of the griping is just plain silly. This is beta 1 so complaining about bugs is a bit much. I’ve found at least a dozen ways to crash Xcode using a Playground or the compiler when using a Project. But that’s just not unexpected. Some features don’t work. Subscripts in particular seem quite finicky. I’ve found a few other features such as named parameters which don’t work quite the way the iBook suggests they should. Again, this isn’t unexpected. There have been quite a few grumblings on Stack Overflow and Twitter about speed. That’s a bit more worrisome given that one of the major selling points of the language was that it wasn’t just as fast as ObjC but faster. Yet in practice a lot of code even with all optimizations on seems slower. I suspect a lot of that is also aspects of it being beta. Yet there are a few worrisome concerns such as how the String class is designed. At this stage though I think it’s really far too early to make judgments. If there are still speed issues in August then I might think twice before doing significant Swift code this year.
The word from WWDC is that Swift is definitely a work in progress. Apple’s saying that even the syntax should be thought of as in flux. That is they reserve the right to make syntax changes making earlier versions incompatible. I’d be shocked if they actually do that except on esoteric features. It does indicate that the language is in a state of flux. If I were to predict a syntax change it would be the range syntax for for loops. Right now they have 0…5 and 0..5 for loops going 0 to 5 and 0 to 4 (excluding 5). That’s bound to lead to hard to catch errors and I’d be shocked if it isn’t removed. An other place there may be changes is over named parameters. Right now you can place an underscore character before the parameter to use a traditional C or Java like function calling instead of named parameters ala ObjC. Just going by Apple’s iBook, there are some inconsistencies here. It’s easy to figure out through trial and error the right way. But a bit more consistency would be nice.
Going beyond all that what is my perception? I rather like it. Even if we ignore most of the unique Swift features and treat it mostly just as a different syntax for ObjC (something more like Eero than a true new language). In fact, I’d argue that initially you are best off ignoring most of the unique Swift features and think of it more as ObjC. That part of the language seems to work much more reliably. To my eyes it is much easier to read. I know some ObjC diehards are saying the lack of verbosity makes it harder to read. I don’t see that. In fact one criticism I have is that so much still uses Cocoa naming conventions that too much remains verbose. I think the rule that the most used methods/classes should be terse has not been a rule Cocoa has followed well. (Especially in terms of string handling)
What’s been useful is heading over to GitHub and looking at all the existing Swift code. (There’s an amazing amount already) One that’s interesting is attempting to do functional programming in Swift. I think this is a place where some extra language features would be much appreciated. I doubt we’ll see anything this year though. I’d be shocked if we see it even next year. As I’ve said I’d love Swift to include some of the features of Python’s generators. There are already some very nice extensions to the default language classes.
There are many remaining missing features. For instance while there are native arrays and dictionaries there are no native sets. You might say that’s not a big deal given NSSet. Still it would be nice to be native and even better to allow strong typing of sets rather than the rather non-existent type checking with NSSet. As I said I would love a yield statement in order to create generators. I kind of wish some of the coercions worked a little differently. For instance getting a string version of a dictionary value is a little convoluted. You have to do dict[“key”] as? AnyObject as String rather than dict[“key”] as? String which seems more obvious.
One feature I’ve not seen discussed a lot are optionals and forced unwrapping. Swift’s ability to have no value at all (somewhat similar to Python’s None although more powerful I think) is quite exciting but also a bit difficult to wrap ones mind around at first. You can make any type into an optional by suffixing a ? to it. So Int? means that the type is an Int or it has no value at all. To treat a variable that is an optional type as if it were the formal type (that is you know it’s not nothing) you just put an exclamation point on it. You can also use ? while working on the value of an optional type and everything after the ? is ignore if it’s not a value (nil for strings for instance). I’m still trying to figure this all out. I think it will simplify a lot of things. However it’s also a place I wish there were a good cheat sheet so I could check to make sure I’m doing it right.
Expect a lot of bugs and errors due to using optionals wrong.
A big question to my mind is whether I’ll even bother using Javascript for Automation since Swift is here. I’ve not yet really tried scripting with Swift. However the REPL and the Playgrounds give one a lot of nice flexibility for playing around with scripting. Further since Apple’s Javascript is apparently using it’s own idiosyncratic Scripting Bridge there’s not really a lot to be gained over Swift by going with it. I’ve not tried Javascript for Automation yet. Yosemite’s beta 1 is still rough enough that I didn’t really find it usable enough on boot. And Parallels (at least my version) won’t properly install it in a virtual machine. I suspect I’ll be holding off for a while. In the meantime I can play with Xcode 6 thankfully under Mavericks.
Unfortunately trying to get Swift and the ScriptingBridge working together is an exercise in frustration at the moment. At least I’ve not figured out how to make it work. What gets returned from SBApplication.applicationWithBundleIdentifier seems an AnyObject that Swift just won’t let you work with. Hopefully this will be fixed in the next beta.
“What gets returned from SBApplication.applicationWithBundleIdentifier seems an AnyObject that Swift just won’t let you work with.”
SB uses dynamic class generation rather than static glue files, which has always struck me as a problem waiting to happen. I think early versions used static glues, but this was changed after someone in Apple mgt. imposed a one-API-fits-all policy, where SB should be used by scripting languages as well. Given that Swift, unlike ObjC, actually appears to have a type system, I wonder if such runtime voodoo would/should even be allowed.
You could always try objc-appscript with Swift, just to see if it works. You might have to muck about with the code a bit as it’s not been updated since ARC was introduced, so I don’t know how it’ll get on with that. But at least it’ll be amusing if it works, though I’m tired of telling them “I told you so” as they never listen anyway. Hey, you could even try porting the whole thing to Swift, just to see how that goes.
It’s a shame objc-appscript’s hamstrung on just a few crucial legacy Carbon APIs like AESend() which lack Cocoa equivalents. I wonder sometimes if we’d have had more luck pressing Apple to fully wrap those last few C functions in NSAppleEventDescriptor. While the appscript project failed in its larger goals, at least then the libraries could still’ve been a fully supported third-party option instead of dead-in-the-water legacyware.
If I ever find some spare time I may just try messing with AppKit. I know there are a few forks on github but I don’t know what’s been done with them.
Swift works well with the ScriptingBridge when you simply use SBApplication instead of something like MailApplication
e.g.
let mail: SBApplication!
mail = SBApplication.applicationWithBundleIdentifier(“com.apple.mail”) as SBApplication
if !mail.running {
mail.activate()
}
works like in Objective-C
Did you try that under beta 2? Because I swear I tried that in a Playground in beta 1 and it wouldn’t work. Of course a lot of stuff with Swift is working in beta 2 that wasn’t under beta 1. I’m hoping to get back to playing with Swift this weekend and see how much of what I tried before is now working. I know multi-argument subscripts now works, for instance. Thanks for letting me know though.
You can use the scripting bridge. You need to make a header file of the target application.
sdef /Applications/iTunes.app | sdp -fh –basename iTunes
then add that header file (in this case iTunes) to your Swift app.
add import ScriptingBridge
Add this header file:
Titles “yourappname-Bridging-Header.h”
//
// Use this file to import your target’s public headers that you would like to expose to Swift.
//
#import “iTunes.h”
run some code in swift:
var iTunes : AnyObject = SBApplication.applicationWithBundleIdentifier(“com.apple.iTunes”)
var test = iTunes.currentStreamTitle
println(test)
The only issue I have run into is some names like ‘play’ conflict I have not found a workaround.. you can use play pause() though bu is slow as it restarts internet streams and does not have instant on.
That works on some things but not others. With scripting System Events the header won’t even import correctly. Xcode beta flags a ton of errors (which aren’t really errors). Even fixing those it still has problems.
If you are just scripting an app this isn’t a problem. If you are using GUI scripting to get around app limits (as you pretty much have to do these days with most apps) then using Swift is pretty much dead until these issues are fixed.
(I’ve not had time to submit the bugs yet – I’ll probably wait until the next beta drops, supposedly early next week, to see if they’re fixed)