Channels ▼
RSS

Design

Swift, Objectively


Last week, at its annual developer confab, Apple unveiled a new language for development on Mac and iOS platforms. Called Swift, the language is intended to replace Objective-C as the principal Apple-sanctioned language for development on its platforms. While I am a fan of new languages, especially those that bring new capabilities to the programming sphere, I'm finding it hard to be wildly enthused about Swift, save for the fact that it replaces a cumbersome language that should have been dumped years ago. On the latter aspect alone, Swift is indeed welcome and surely will be quickly adopted by Apple developers.

Swift was designed and developed in secret. The latter aspect is rather remarkable: I can find no one who had any inkling that Swift or any new language was going to be presented by Apple at the conference. Such tight security is a curious choice for a language under development, even for notoriously secretive Apple: Why not get developer feedback before casting the syntax and semantics into stone? Conversation with the intended users is the preferred path for new languages: D, Go, and Rust are all built with feedback from a community of early adopters and testers. In fact, that feedback is frequently touted as the principal reason for creating a community. In the case of Swift, not only is it not in Apple's DNA to solicit this feedback, but in some sense, Apple didn't need it because the company took no risks with the new language.

Swift simply brings together features common in existing, popular languages, then creates binaries via the LLVM compiler infrastructure, whose design we explained last year. As Chris Lattner, one of the core developers of both Swift and LLVM wrote accurately, it borrow features from Objective-C, Rust, Python, Haskell, C#, and Ruby. In this sense, it is the salade niçoise of languages. The benefit of this choice is that adoption should be fairly easy; the down side is that (as we know so well from C++) features imported for purposes of compatibility and familiarity with existing idioms tend to become plagued with vexatious limitations as the language evolves to fit new needs.

That being said, I like several choices Apple made with Swift:

  • Automated memory management
  • Safety (variables are always initialized before use, arrays and integers are checked for overflow)
  • Closures
  • Generics
  • Inferred types
  • Basic functional programming patterns

The world is moving increasingly away from the model adopted in C and C++, in which the developer is given unlimited capability to do almost anything, but then saddled with the responsibility to constantly clean-up after himself. The complexity of today's applications make it nearly impossible to do 100% accurate clean-up, and as a result, language designers are rightly favoring automation of basic housekeeping functions (such as memory management) and the ability to flag violations (such as access past the end of an array). Swift embraces this new safety, which makes sense in an application language.

The inclusion of closures (lambdas), inferred types, and basic support for notions of functional programming also are consistent with current trends. These features appeared previously in Java 8, Groovy, Go, Ruby, and Rust. However, the absence of concurrency features in Swift runs counter to recent language trends. Support might well be added later via libraries, however the omission of any indication of this is puzzling, even troubling.

More troubling even than the lack of concurrency is that Swift is proprietary and closed: It is entirely controlled by Apple and there is no open source implementation. This is a problem for several reasons, the most important of which is that Apple has not shown itself to be a good steward of programming languages. Its handling of Objective-C was poor. The language grew by accretion of ugly syntactical elements. Rather than cater to developers' needs, Objective-C added features that Apple wanted for purposes of its own agenda — regardless of how ungainly they were. For this reason alone, developers for Mac and iOS platforms will surely want to convert existing projects to Swift as quickly as possible. (Contrast this with the evolution of the other major proprietary language, C#, which has steadily improved under Microsoft's adroit stewardship.)

There is no doubt Swift will be successful. While it does not appear to do anything engagingly novel or uniquely well, its set of features is reasonable and a big step forward for Objective-C developers. But Apple's continued insistence on a closed ecosystem is a missed opportunity to interact productively with developers.

—Andrew Binstock
Editor in Chief
alb@drdobbs.com
Twitter: platypusguy
Google+


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video