Swift is here. And about time too.
Apple launched Swift during its recent World Wide Developers’ Conference. The beta version of it was released for developers . We had a sneak peak into the language and we wanted to share with you all what we feel about Apple’s new language.
We were plagued by seemingly cumbersome and debatable syntax, inconvenient pointers and endless arguments with Java developers about how messaging mechanism is not as bad as it looks like. It all ends here … or maybe not just yet. Apple will continue to support Objective-C for a foreseeable future. We just have an alternative. Is it a better alternative? Has the tech-giant just dilly-dallied with the syntax and delivered a new programming language with an apologetic smile, because it had to? Let us find out.
We shall go on about analyzing Swift in three phases: one, we shall see Swift as an independent programming language, see its features and understand how it fares against other modern languages; two, we shall discuss in the context of iOS Application Development, see its coexistent predecessor, Objective-C and what was wrong with it; three, how Swift’s introduction could solve such problems (or not).
What is this Swift, anyway?
Swift was introduced as being fast, modern, safe and interactive programming language. When I was watching WWDC, I was really excited when Apple, (not so humbly) boasted about Swift’s performance when compared to other programming languages; when they said I didn’t really have to write tons of code just to achieve null safety; when they claimed Swift to be at par with other programming languages from the perspective of modernity. After having my hand at development using Swift, am I so excited now? Not so much.
Swift is a pretty modern language. I say “pretty” with a certain amount of care because, it comes with its own garbage. Quite literally, in this case. Sadly, to manage memory Swift doesn’t use Garbage Collection, it uses Automatic Reference Counting instead. That means, you don’t have to manage ALL the memory by yourself. But, you would have to manage more than you would in any other stable language, say Java — and that is kind of bad.
Swift does not have access modifiers. In my view, a true Object Oriented language (but, what IS a true Object Oriented language, anyway? That’s a debate for another day) would have its components put in a carefully tailored container, exposing properties and features only when they have to. Alas, in Swift, all your instance variables are public — anybody can access your instance variables and manipulate them the way they see it fit. Apple has promised to provide this feature in the future — and I’ll be watching them.
I really like its other features: Generics, a powerful do-it-all-in-one kind of mechanism; Type Safety, though there is Type Inference in Swift, you CAN initialize a variable with a particular data type, but you can’t change it in the runtime; Closures, treating methods as first class objects; Multiple Return Values; and so on. You will find these in any other modern programming language and they are great. I encourage readers to read in depth about these features. They are very interesting and easily achievable in Swift.
Objective-C. The bad.
People, when are first introduced to Objective-C, they run away and far. I think the reaction, that Objective-C is bad, coincides with these two reasons: 1. Its syntax is very unfamiliar 2. Developers who wanted to build iOS apps had to learn Objective-C because Apple pretty much said, “It’s this or nothing, man”.
But, it is my personal opinion that Objective-C’s syntax is awesome. Its message sending syntax is advantageous than the traditional object.method() syntax. All though copied shamelessly from Smalltalk, reading code in Objective-C is like reading a sentence, with parameters prefaced with their purpose in the message. So cool.
No, syntax isn’t the problem with Objective C. It is its persistent adherence to the general C principles that is the culprit. The underlying frameworks like Grand Central Dispatch, Blocks, Webkit etc., are still written using C/C++ which are at the system level, where higher level concepts like a true object system just cannot belong.
In addition, Objective C has other problems: including a lack of method visibility methods, lacks class namespacing (although interestingly protocols exist in their own namespaces), lacks a proper importing system, suffers from C’s support of library linking because it lacks its own. It has header files, has a weak abstraction for dynamically sending messages, the code must be compiled and re-run to see changes, and the list goes on… In short, Objective-C wasn’t it.
Swift > Objective-C ?
Perhaps, the most welcome change in the new paradigm is its shift from C-dependancy. “Objective-C without the baggage of C” was what Apple said when they presented Swift. With that, they have proved that despite doing so, they still could maintain their performance driven culture that the company is known for.
Apart from that, Swift has namespaces, doesn’t have header files and we have Playground! No more do we have to compile the whole project to see the changes. All you have to do is write your code in a scripting-like environment and see the changes right away. For all those of you who jumped from your seats with wonderment, thinking that Apple’s Swift is interpreted, let me tell you, it’s not. Playground, does exactly what they say it does, “Type a line of code, and the result appears immediately” and nothing more. At the end of the day, you are compiling your project, after having “played” with your code snippets.
While the completely revamped syntax is sure to lure new developers, conventional developers like myself, would not be too excited about it. Yes, Swift is less verbose and you can put your point across with less amount code … Oh, maybe we are just too used to Objective-C.
With the introduction of Swift, Apple has clearly solved some obvious problems that Objective-C faced. But, some fundamental issues still do exist that we hope to be addressed in the future versions of the programming language. I am looking forward to write clean, concise and effective code using Swift in a platform that we all love and admire.