Tags

,

Sorry, Taylor Swift’s fans. No beautiful pictures for you. We are talking about Apple’s new programming language for iOS and OS X. Revealed last month, Swift already generates a lot of good buzz. After finishing the “The Swift Programming Language” book, here are some of what I learned.

For years, iOS and OS X programmers don’t have many choices for native application development. Objective-C is the language. Although it is good, Objective-C shows its age compared to new languages or other quickly-evolving main-stream languages. Swift finally makes iOS programmers feel living in a modern world. But first of all, Swift is still largely based on Objective-C and it actually uses Objective-C runtime. It is good indeed as we can reuse a large number of Objective-C libraries. Besides, Objective-C programmer won’t feel painful moving to the new language. Meanwhile, Swift does steal a lot of nice features from other languages. Let’s go through some of them in what follows.

The first small but nice change is dot-notation style. Objective-C uses a Smalltalk-like syntax for method calls, which many C++/Java/C# programmers don’t feel comfortable at beginning. This little change will help attracting the programmers of these popular languages. Recall that the similar change helped a lot to the popularity of Ruby, which mimics the object system of Smalltalk. A large talent pool is always important to corporations, right?

Objective-C is a thin layer on top of C. Thus, all error-prone features of C are preserved. In contrast, Swift puts a lot of emphasis on safety:

  • Strong typing
  • No pointers
  • Optional types, which handle the absence of a value. Optionals are safer and more expressive than nil pointers in Objective-C. Swift still has nil but it is not a pointer — it is the absence of a value of a certain type.
  • Variables and constants are always initialized and array bounds are always checked.
  • Overflows are trapped as a run-time error (If necessary, overflows are allowed with the special arithmetical operators &+, &-, &*, &/ and &%).

As most new programming languages embrace functional programming (Google’s Go language is a notable exception), Swift includes several functional features. First of all, functions are first-class objects in Swift so that one can pass functions as parameters to other functions, and return functions from functions. Since Swift is strongly typed and functions are values, every function has a type, consisting of the function’s parameter types and return type. Functions can also be written within other functions and nested functions can capture values from their enclosing function. Functions are actually special cases of closures. Similar to nested functions, unnamed closures (i.e. lambdas) can capture values from their surrounding context. One can write closures in a clean and clear style with the support of inferring parameter and return value types, implicit returns from single-expression closures, shorthand argument names, and trailing closure syntax.

For algebraic data types, Swift supports tuples that group multiple values into a single compound value. We can use a tuple type as the return type for a function to return multiple values. In fact, functions without a defined return type return a special value of type Void, which is actually an empty tuple written as (). Swift also has enumerations whose cases can have associated data. So they are like variants in functional languages but more in an object-oriented flavor because they can have computed properties and instance methods. We can match tuple and enumeration values in the switch statements. Like pattern matches in functional programming, there is no implicit fall through now.

With type inference that deduces the type of an expression automatically, Swift requires far fewer type declarations than Objective-C. Other nice features include generic programming, operator overloading (new operators can also be created), extensions (add new functionality to an existing class), unicode support, etc.

A surprise to me is that there is no exception handling in the language level. It is still possible to raise NSException objects but we cannot catch them in Swift. Although Apple’s frameworks don’t use exceptions for error handling, I still don’t get why a modern general purpose programming language chooses not to support it.

Overall, Swift is not revolutionary but it is relatively small and easy to learn. With functional features, type inference, generic programming, enhanced safety and OOP, it surely offers more productivity than Objective-C.

Advertisements