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.