Mac developers musing on Apple's new Swift language

At WWDC, Apple released the first version of Swift, the company's new development language. Developers are taking a look-see at Swift and offering some initial opinions.
Written by David Morgenstern, Contributor

The Swift platform and what it will offer developers is one of the most important announcements last week at the Apple Worldwide Developers Conference (WWDC). Many programmers found the syntax of Objective-C hard to get used to, so Swift may provide a productivity boost to some.

Apples Swift programming language

While most developers will look to future projects for implementing Swift (meaning at least a year off), some said they are moving ahead more quickly. For example, developer and writer Marco Arment said in a blog post that he would take a while to grok the new behaviors as well as its standards and expectations.

In an interesting and uncharacteristic move, Apple is opening all its WWDC 2014 video presentations to the public; last year only registered developers had access to them. Check out the Introduction to Swift by developer publications engineers Tim Isted and Dave Addey.

On his blog, Michel Fortin talked about Swift's safety features.

Apple says it’s designed for safety. It’s important to note that the design of Swift doesn’t prevent memory corruption that could happen due to multithreaded code at all, however. I find it striking that there’s no mention of threads or concurrency at all in the language documentation. Maybe they’ll just outlaw threads, but that’d be surprising.

Besides this multithreaded hole, the rest of the language seems to be safe from memory corruption bugs. There’s no way to temporarily escape the safeties (like Rust’s unsafe block), so any unsafe thing you may want to do will have to be in C or Objective-C.

There were some posts with interesting discussion about Swift and scripting. Clark Goble at Clark's Tech Blog had several long posts about the introduction of Swift and a first look at its performance. He suggested heading over to GitHub and checking out the surprisingly large amount of Swift code there.

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)

In an interesting post, the programmer known as Dr. Drang pointed to Javascript taking a place alongside AppleScript as an application scripting method in OS X Yosemite.

I’m not a big fan of JavaScript, but it’s certainly a more conventional language than AppleScript. I’ve forced myself to become conversant in AppleScript because it’s been the only game in town, but that doesn’t mean I like it.

Still, the devil will be in the details. The biggest problem with AppleScript has always been with the applications that implement it. Each app gets to decide which features get exposed and what they’re called. This has led to similar concepts getting different names in the dictionaries of different apps. I doubt that JavaScript will solve that problem.

Clark wondered whether he would bother with Javascript for Automation with the arrival of Swift.

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 its 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.

Editorial standards