On Monday Apple introduced Swift, a new language that is, mostly, very nice, leaving aside the fact that another language with the same name has already existed for a while (Apple has a history of ignoring previously used name or even trademarks). Swift has a modern, clean syntax, all essential capabilities that a modern language would need, and is mostly devoid of various kinds of gnarly monstrosities that are a mainstay of Objective C (square brackets for function calls, err, “messages”, is but one of them). And yet… for most developers, it changes nothing.
Here’s why: it’s completely tied to Apple’s platforms and products. That is, of course, by design. Oh, sure, you probably will be able to use GCC someday and compile a Swift program on its own on any platform – but most of its power lies not in the language itself, but in the tight integration into Apple’s proprietary API. In this sense, it’s an incredible choice for one-off iOS or OS X projects, or projects that are guaranteed to always stay in that ecosystem – because once you tie yourself to one vendor’s high-level APIs, you’re trapped for life. Most large, serious projects would never take that risk, and so will opt to stick with something more portable – most likely C++.
We went through this transition in our experience, too. A long time ago, we wrote a number of applications that relied heavily on Microsoft’s Windows-only .NET framework for UI and other functionality. In case you haven’t used it, .NET is incredibly well-designed and programmer-friendly, and can be used with pure C++ to boot. The year was 2006, and it was a totally, 100% safe bet. Windows ruled, OS X sat at around 7% percent market share on the desktop, and there never was nor would there ever be any need for any other operating systems to be used… until the iPhone was introduced the following year, and things began to slowly change. Looking at where we are now, there’s iOS, Android, Windows, OS X, a number of Linux flavours, and Window Metro – and that’s just listing the most popular operating systems.
If you’re working on a serious product, tying yourself to just one of those would be madness (and not the Sparta kind) – you’re either limiting yourself to forever being in a niche marketing with limited opportunities for growth or to creating multiple clones of your projects, one for each operating system, each with its own bugs, quirks, and maintainability issues.
Hence, most larger projects will continue to be created in compiled, non-platform specific languages. The only real difficulty here is UI – but even that could be solved by relying on one of the cross-platform libraries such as Qt. Or our own UI library which we may break out of Ormr and introduce later – admittedly, it still needs a bit of work and a lot of docs to be usable by anyone other than us; it is, however, very fast, runs on both OpenGL and DirectX, is completely platform-independent, and can be saved/loaded from simple XML-like configuration files. But we’ll see about that in the future. :)
Oh, and welcome to our blog. :)