Overview

10 Early Thoughts on the Swift Programming Language

2 Comments

As of the time of this writing, just about 48 hours ago, Apple unveiled the Swift Programming Language. Normally, there would not be so much buzz about a new language, but due to Apple’s relative dominance in the mobile, and decent presence in the desktop market it is probably safe to assume that this language will at least have an impact on some businesses.

At codecentric, knowledge leadership is one of our core values and thus it is no surprise that some of us started reading the language guide right away. I am one of those curious ones and have to admit that I did not finish the whole book (860 pages…) before starting to play around with it.

Actually, I think this is encouraged by Apple as the new Version of Xcode (6 beta), which is needed to try out Swift, provides you with “Playground”. Basically this new feature is a REPL, an interactive toplevel or language shell, that allows you just to write some code and evaluate its results on the fly. Swift makes this especially easy since it provides you with a global scope in which you can write code without any need for classes or main methods.

Despite the fact that I would encourage you to jump into the Apple provided language guide “The Swift Programming Language” directly, I also invite you to take a look at our Swift playground repository. Aside from other interesting tidbits regarding the language, we also compiled a short tutorial. It is aimed at people already familiar with other programming languages, such as Java, and just gives a very brief overview in about 350 lines of code on the basics of the language. Go ahead and take a look, especially if you just want a very condensed version of the first few hundred pages of the book.

Aside from announcing the repository, I would like to use this blog post to give my personal opinion on some of my preliminary findings. Background info: I have done a lot of programming in Ruby, Java and Objective-C before. I limited myself to five points “for” and “against” to keep this brief.

5 Things I Like

The syntax. I have been a fan of Objective-C’s syntax mainly because of the named parameters in methods. While Java gives you foo(true, false, 0, 1, null), calls to objC methods are much clearer. So are the ones in Swift. I also like much of the other syntactic stuff, eg. -> for announcing return types, tuples, the clean closure syntax as well as the ? and ! notation, which brings me to the…

Handling of nil (null). I think it is quite fundamental that the language requires you to address nil explicitly and that nil is not a pointer to nothing but a invalid value, rather. The way you can handle values that might be nil using ? (question mark), which even can be chained, is very nice and reminds me a bit of the try method from Rails.

Strictness. This is probably (what isn’t?) a matter of taste, but I like it when the compiler tells me right away that I have done something which I should not have. This usually does not happen in script languages (unless you are using a really good IDE). Also, I think, eg. type safety and other “strictness features“, encourage good programming principles and well written code.

The Playground. It is just convenient to being able to have some place to just try stuff out and Apple did a great job here, allowing you a remarkable amount of insight into what your code does. At first, I thought this would be something like irb in Ruby but it really is much more and well done.

Its (future) adoption rate and support. As mentioned above, these days, there seems to be new programming language coming out every day. I guess most of you have taken a look at some of these but aside from the mainstream, none of them seem to receive much attention or actually become relevant for day to day business. With Apples mobile platform dominance and decent desktop business this will be much different. This language will not be mainstream soon, but there will be many more job openings requiring Swift knowledge than eg. Rust, which is quite similar. I like this because I think, all in all it is a nice modern programming language, despite the things that I am about to mention in following section.

5 Things I Am (at Least) Skeptical About

Any and AnyObject. It seems, when using the Cocoa API, which still relies on Objective-C and C you sometimes get return values of AnyObject. For example dequeueReusableCellWithIdentifier(String) does not return a UITableViewCell?, as I would have expected, but AnyObject! (note the !). This can actually hide an objC nil value. I guess usage of these will be reduced in later API releases.

Extensions. I kind of do not like the “patching“ of classes in Ruby. Now you can bring your own methods and even initializers to existing classes in Swift, as well. I could not find documentation on about how conflicts are resolved when two extensions try to provide the same methods. I guess it will be just an compile time error, which could make it (very) hard to use third-party provided frameworks, since everyone will patch their own convenience methods into String and Array.

Array. Speaking of which, Array shows in my opinion some strange behavior when extended in size. If a and b reference the same Array and you append to a, b will still reference the old Array and a will now be an entirely different object. This might be related to the fact that you seem to be allowed to make assignments to self within an object. A bit odd.

Dynamic(ness). While Objective-C seemed quite dynamic to me, the strictness (which I liked, I know) seems to disallow features such as calling methods by name of getting values of properties whose name you only know in a String. From reading the manual I would not know how to write a JSON to Object mapper, for example. Maybe I missed this, maybe this going to be implemented later on.

Stuff that seems to be missing. First and foremost: No access control? Seems a bit odd to me. Also I could not find out how to make properties read-only from outside the class scope, also exceptions and errors are not really covered. The docs say something about errors at runtime that might happen but not how (or even if) you can react. Also no mention of a multithreading mechanism. I guess there will be wrappers around for NSThread, but NSArray for example provided nice closure (or block) ready methods to iterate in parallel over its elements. I could not find some replacement to this, yet. There is probably a lot more that is just not there, yet, so I would not stress the missing stuff too much.

Wrap-up

To summarize, I think I personally would like to write code in Swift. Especially seeing it just as a replacement for Objective-C in OS X or iOS development, the language reduces a lot of “boring” overhead. However, when I think of a new idea – whatever it is – to shout out, “Yes! I am going to do this in Swift!”, the language – at least for now – lacks in some areas I deem important.

Have you tried it yet? Let us know your findings in the comments!

Kommentare

  • TechZen

    9. July 2014 von TechZen

    The ability to patch classes is one of the oldest core functionalities of Objective-c. Most often used are Categories which allow arbitrary functions to be attached to any existing class, even system supplied ones. Swizzling allows even more aggressive patching akin to monkey patching under Ruby

    The Swift Extension functionality, AFICT, just bundles all the old Objective-c functionality and provides some new functionality e.g. adding subscripts.

    But your right, it’s a great way to shoot yourself in the foot. “We great power comes great responsibility”

  • ios training in chennai

    Awesome blog! I really loved it. I liked your long posts and they are all very useful.

Comment

Your email address will not be published. Required fields are marked *