During the WWDC 2014 event this week, Apple unveiled a new programming language called Swift. This is meant to complement the Objective C programming language that has been serving Apple developers for the past 20 years and eventually replace it as the main tool for apps creations both on iOS devices and Macs. Getting rid of the “C” part, as Federighi put it during the keynote, is quite an understatement. The transition from Objective C to Swift looks to me more like the transition from programming in Assembly to programming in C back in the ’80s (or in the late ’90s if we look at the embedded control industry). Swift takes many more things from Python, Ruby and the many other ‘scripting’ languages in use today than Java and C# did in the previous generations and goes well beyond.
There is one major difference though between Swift and all of the above languages, it does compile to a binary executable.
The Swift designers did care about ease of use and interactivity but were not willing to compromise on performance. So while Java, Ruby and Python eventually compile to byte-codes (an intermediate binary of sorts for a ‘virtual machine’) that needs to be interpreted at run time, Swift emits actual binary code for the target machine. Portability (across the iOS and OS X platforms) is obtained by using an LLVM based compiler which can be (easily, if you are Apple that is) retargeted to different CPUs as needed and through the extensive use of carefully architected libraries.
What has all this to do with the embedded control world?
The embedded control industry has always been lagging behind the main computing (and personal computing) industry by at least a decade but eventually has always followed all the major trends. As micro controllers have become more powerful and the memory resources (especially RAM) become more available, Java, Lua and even Python have been starting to show up in some application areas. User interface design is one such area where the use of object oriented programming and garbage collection (just to mention two relevant characteristics of the new languages) can help significantly reduce development time and keep bugs at bay. I have verified myself such benefits when porting the Pymite project to the PIC32 and comparing the GOL library to a Python equivalent implementation.
Unfortunately the performance penalty incurred by the use of virtual machines limited any further growth of the field of application of such languages. The solution offered to Java users (on desktop applications) has been the use of a Just in Time (JIT) compilers, the complexity and size of which, is unfortunately well outside the scope of current micro controller implementations.
In the Python world this has meant the birth of the PyPI project, a Python interpreter/compiler (written in Python itself) that also attempts JIT compilation, and the definition of RPython, a subset of the language that lends itself to better performance and strong optimisations. Once more these options were not available to the current crop of embedded controllers, hence the birth of the micropython project where additional annotations, truly a re-cycling of syntactic elements of the language (decorators) are used to provide strong hints for a compiler (to target binary) for selected code segments. The result, in my opinion, is not pretty, not portable, and eventually ends up loosing most of the benefits that the original adoption of the language was promising to bring to the table.
Now Swift could change all that. Swift was designed from the bottom up to be compiled for performance and thanks to the LLVM compiler, the portability is still there without the cost of the VM interpreter or the complexity of a JIT compiler. Can’t wait to see Swift re-targeted to a (small) microcontroller for a real embedded control application!
