Apple's new language, Swift, will be welcomed by developers primarily as an antidote to working in Objective-C. But Apple's continued insistence on a closed ecosystem is a missed opportunity.
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 enthusiastic 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.
Prior to joining Dr. Dobb's Journal, Andrew Binstock worked as a technology analyst, as well as a columnist for SD Times, a reviewer for InfoWorld, and the editor of UNIX Review. Before that, he was a senior manager at Price Waterhouse. He began his career in software ... View Full Bio
We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.