Swift

Jun 4, 2014 8:52 PM

Tags: swift

This is a topic that doesn't really fit my usual bailiwick of Domino programming, nor is it something I'm particularly qualified to comment on, since the most Objective-C programming I've ever done was some putzing around years and years ago with a weird idea for a pseudo-database that didn't even involve Cocoa, but I'm going to talk about it anyway.

I'm really excited about Swift.

In case you don't follow Apple circles, Swift was one of the fire hose of announcements at WWDC on Monday. It's a new programming language designated to replace Objective-C, billed as "Objective-C without the C", and can be thought of as Apple's Go.

So why am I so excited about it? Part of it is that I've been flirting with the notion of diving into Cocoa development proper, and this provides a perfect impetus. But beyond that, it tickles my programmer brain in a great many ways.

Low level + dynamic

The primary thing that piques my interest is the way it blends the best of what in olden days were referred to as "systems" and "scripting" languages. It's not the first language to do so, but it'll be among the few to get widespread adoption. It's C without pointers (mostly); it's functional programming without the Lisp; it's Objective-C without the brackets and @s; it's Ruby/Python without the speed loss; it's ML/Haskell/etc. without the "what the hell is this?".

What this means in practice is that it doesn't shy away from syntactic sugar. It's extremely common to want to make literal arrays and maps (Dictionaries in Cocoa parlance), and so Swift has clean syntax for those. They want to really emphasize closures, so the syntax gets cleaner the simpler the task is. They want strong typing, so they use type inference to get the result without all the "oh, come on, you know what I mean!" feeling you get from writing Java.

Good for programmers and compilers

It's striking just how many of the syntactic sugar bits and the defaults of the language are geared both towards improving programmers' lives (with easier code and bug prevention) and improving compiler optimization. It seems like it's a product of the modern state of compilers: whereas C was made during the infancy of computing and is designed to allow the programmer to really turn the screws in tons of crazy ways (see: pointer arithmetic), Swift is designed to take advantage of the fact that the bounds for what makes a good program are now well-known, and by restricting "dangerous" operations, the code is not only safer but also much more predictable.

One example of this is something that most current languages have adopted: for-all loops. In languages without them, it's contingent on the programmer to write the looping logic themselves. In pre–for-all Java, for example, this meant either using array indexes or Enumerators/Iterators. Those ranged from sort of a pain and potentially inefficient (indexes) to probably fast but horrendously ugly (the others). But for-all loops fix that: not only is the syntax much easier to type and is much clearer in intent, but now the compiler can choose the most appropriate method of iteration.

Swift is full of this, from its focus on immutability to its use of the "override" keyword to its integration of functional-programming idioms.

Type inference

I mentioned this already, but it deserves its own section. I've long had a very conflicted view on type systems. On the one hand, I appreciate the values of a Java-style strict type system - the consistency, the prevention of errors, the self-documentating nature - but good lord is Java a huge PITA to actually write sometimes. I can't even count how many times I've written a line like this:

List<Map<String, Object>> someListOfMaps = new ArrayList<Map<String, Object>>();

Gahhhhh. Every time! Never versions of Java have improved on this (though we as Domino programmers likely won't see that for a while), but it's still a drag. Moving to a strongly-typed-but-declaration-free language like Ruby is such a breath of fresh air. Not because I specifically want to assign objects of different types to the same variable, but because I don't have to fight the compiler over nuts-and-bolts of getting the right class name down.

The kind of type inference Swift uses makes Java-style strictness palatable. You get all the benefits of strict typing, both to you and to the compiler, without having to write "Map" five hundred times per source-code file.

LLVM as .NET or the JVM

LLVM is the just-above-the-metal virtual machine that Apple uses on its devices, and this sort of marks its coming-out party as a multi-language platform in the vein of .NET or the JVM. Swift files compile down to the same object types as Objective-C, so you can mix and match them in the runtime, much as you could mix and match multiple .NET languages or Java and Scala. In practice, this means that diving into it in an existing Cocoa app is much easier than having to rewrite the whole thing, while it also means that someone like me who isn't well-versed in the framework can still make use of the decades of Objective-C knowledge online.

Conclusion

So in conclusion: I'm just real excited. This looks fun! It's like a best-of setlist from all modern languages built on top of a giant framework that lets you build apps immediately. You should give it a look too - at the very least, watch the end of the WWDC keynote, where it was introduced.

Commenter Photo

Sven Hasselbach - Jun 5, 2014 5:21 AM

I agree. Swift looks very interesting. Hope that I find some time to play with it,

Commenter Photo

Ralf M Petter - Jun 5, 2014 7:00 AM

Looks very promising, but i do not like that swift has no real garbagge collector. In the times of 64 bit quad core processors in your handy the small performance overhead of a garbagge collector should be no problem.

Commenter Photo

Jesse Gallagher - Jun 5, 2014 9:56 AM

I don't know the technical details, but as an outside observer I gather that Apple went with ARC instead of Java-style GC based on their experience in Objective-C. Objective-C actually had (and may still have) a garbage collector you can enable, but I recall reading that the tradeoffs weren't worth it. ARC seems like a good compromise, and at least for the time being I take it that they think it covers what's needed.

Commenter Photo

René Winkelmeyer - Jun 5, 2014 12:56 PM

Swift uses ARC (Automatic Reference Counting) for it's Garbage Collection as it's in ObjC since iOS 6. If you 'need' to manually dealloc something you can still do it. For example in the deinit() function.

 

But ARC is a first class citizen in ObjC and so it'll be within Swift.

Commenter Photo

Dan Sickles - Jun 6, 2014 2:31 AM

The collections are weak. Map? Filter? Reduce? Sets? Immutable collections? Parallel collections? I like most of the language features but it still encourages too much imperative coding. This seems like an oversight given how much has been borrowed from functional programming. Even Java (8) is reducing imperative coding by adopting more functional patterns, especially the collections.

I will be comparing to RubyMotion which just announced future support for Android. I'm thinking that apple may consider the proprietariness(?) of Swift to be it's best feature. I hope not.

Commenter Photo

Jesse Gallagher - Jun 6, 2014 8:51 AM

I think Swift's marriage to Cocoa as its framework is a double-edged sword. Is does indeed mean that the language/environment leaves a number of potential great features on the table, but they've been using the advent of blocks in Objective-C to gradually beef up the data structures in a Smaltalk-y sort of way (for example, NSSet). Swift should have access to those as-is and I hope that they make them a bit more "Swift-native" over time.

New Comment