In 2010 when development of Swift started, I was contemplating the future of Mac development on this blog.
My predictions was that Apple would not adopt an existing language, but build their own. I thought about whether they would make a new managed language platform like Microsofts .NET, but I concluded that was unrealistic:
Creating something similar to .NET is unthinkable. It is a huge undertaking and Apple is too far behind to compete with established platforms like Java and .NET.
But Apple had other strengths I concluded that they could utilize:
Cocoa is a very well designed framework and the Objective-C runtime allows fairly easy interaction with other dynamic languages. Microsoft was never in such a fortunate position. Creating a COM object was far more complicated than creating an Objective-C class. That made .NET more of a necessity
Microsoft mainly did their development in C/C++ using COM objects. But that was a much poorer basis for a language than Objective-C as COM had no concept of inheritance and is not message based. Win32 wasn’t really anything to build the next generation language on. So they had to create .NET as entirely new platform. Of course that also had the benefit of making them much freer in how to design .NET.
Apple did not have that freedom, but they had Objective-C and Cocoa, which was actually possible to build further on. Due to the message passing model it was a lot easier to integrate Objective-C with another language than C or C++.
Apple has gotten a lot of criticism for sticking with a fairly unknown language in the industry like Objective-C. Many are of the opinion that C++ would have served them better. I think Swift proved the doubters wrong. C++ with its extreme complexity is an extremely difficult language to bridge to other languages. It would have been a practically impossible task to build something like Swift on top of a C++.
It was the rising popularity of languages such as Scala and Clojure on the Java platform which made me see how alternative languages had a chance if well designed. Playing with the Nu created by Tim Burks was what convinced my that what Apple should and would do was to create an entirely new programming language build on top of the Objective-C runtime (object model). Tim Burks elaborated on the complexities of creating RubyCocoa which was trying to allow you to use Cocoa using Ruby. Because the semantics and practices of Objective-C and Ruby are quite different it is very hard to get a satisfying integration.
Apple’s previous failures trying to adopt existing popular languages
Using an existing language had been tried multiple times by Apple. Best known was their attempt to replace Objective-C with Java. In the early 2000s Java was made a first class citizen and Apple’s flagship product for creating server side software WebObjects was rewritten from Objective-C to Java. Apple even tried to make Python and Ruby first class citizens. PyObjC e.g. was included with the Mac OS X 10.5 Leopard release in 2007. However none of these alternative languages gained much popularity. To me as a Objective-C/Cocoa developer it was plain to see why. Having to write:
myLittleDuck.makeSomeNoise_eyesClosed_onOneFoot_(quack, True, True)
[myLittleDuck makeSomeNoise:quack eyesClosed:@YES onOneFoot:@YES];
Was not attractive. It look messy and unreadable. Java, Ruby and Java didn’t have syntax which meshed well with the Smalltalk inspired syntax in Objective-C. Java was even worse not being dynamic many common patterns in Cocoa didn’t work. Java developers have also ever since MS tried to adopt it for Windows development, been critical of using non cross platform frameworks for development like Cocoa. Apple thus effectively abandoned existing alternative languages after they failed in the market place (Java bridge deprecated in OS X 10.4). This was my thinking that lead me to conclude in my blogpost 4 years ago:
My prediction is that if Apple has a new more modern language in the works for rapid application development on Mac, it will be based on LLVM and the Objective-C runtime like MacRuby, but will take the same approach as Nu in that it will be designed from the ground up to work with Objective-C and complement it.
Swift features I correctly predicted
With respect to language features and general direction of language I got some things wrong but I’d say I got a lot right:
- Built on top of Objective-C runtime model.
- Using LLVM (but I wrongly assumed it would be JITed).
- Type inference using static typing.
- Native support for Objective-C named parameters.
- More functional
- Emphasis on shorter and simpler code as found in Go, Ruby, Python etc. In Swift they dropped parenthesis in if, while, switch and for loops.
- No fundamental new features not seen in existing languages.
I think the last point is important, because I’ve seen comments about Swift were people criticize it for not bringing anything fundamentally new to programming. It was obvious 4 years ago and it should be obvious today as well that you don’t bring in new experimental features in a programming language for industry. Swift only contains features which have already proven themselves.
What I got wrong
Swift isn’t JITed as I suspected. Knowing the iOS security model I would not have predicted JITing today, as it makes checking signatures of running code impossible and requires code pages in memory to be read and write. But I didn’t know anything about this in 2010.
Native Concurrency support
No native support of Concurrency. I actually think my predictions will be right eventually with this regard. It is just that this will be added later. Having GCD syntax for concurrency might not be first priority.
In my defense ARC didn’t exist (released 2011) when I made my prediction and nobody had expected it to work as well as it did. Certainly not Apple otherwise they would not have created GC for Objective-C and then deprecating it a few years later.
Multi language platform
I thought LLVM might get some higher level abstractions to work a bit more like .NET as a platform for multiple languages. I don’t believe this will happen anymore. For a couple of reasons:
- The promise of .NET never really panned out. Few projects ever used multiple languages. C# completely dominated. Adding other languages proved harder than expected. E.g. .NET was made specifically for statically typed languages to adding stuff like IronPython was hard. You see the same on the Java platform in that Groovy gets bad performance.
- Apple are not really into offering a lot of alternatives. They have very few options for computers and cell phones. They like to find the best approach and stick to that.
Future predictions for Swift
As I said I am certain concurrency will come. It is simply such a big thing now than no modern language is going to not support this.
However there are some things which doesn’t exist which I am certain wont come either. E.g. Exceptions because:
- Cocoa is not exception safe.
- New languages in recent years don’t seem to embrace exceptions as happily as they once did.
- The support for optionals, multiple return arguments and enum types provides many potentially good facilities for handling errors.
I think we will see Apple making changes to Cocoa in the coming years to see error handling more hashed out.
As for peoples usage of Swift, I predict a very rapid adoption. How can I be sure?
- A lot of Objective-C developers today came to the platform because they wanted to do iOS development not because they wanted to use Objective-C. As much as I love Objective-C I realize that most people really dislike it. Swift is much more what people are used to and like.
- Objective-C doesn’t offer anything that Swift doesn’t do better. Well Objective-C offers seamless integration with C, but that matters just to perhaps less than 10% of developers.
- Unlike when .NET was introduced or Go for that matter. There are no new APIs to learn. Okay it is a new language, but pretty much everything else stays the same. This lets developers keep their multiple years of investment into learning Apple API’s. The risk is low.
- Apple has clearly said this is the future.
They didn’t say it was a supplement or alternative to Objective-C. From experience we know Apple is serious when they say something is the future. In the past they have shown themselves willing to lose customers going forward according to plan despite protests. They lost a lot of customers in their hardware transitions, Motorola to PowerPC and PowerPC to intel. They lost customers when deprecating Carbon in favor of Cocoa. Even though it meant one of the platforms most prominent products Adobe Photoshop would not get an upgrade.
And finally Swift isn’t just minor improvement like Python 2 to Python 3. Swift is a large improvement, so developers will make the switch because they will see real tangible benefits in terms of productivity and lower bug count.