Thoughts on Swift (Part 1)

WWDC, it always serves something up for you to think about, worry about, be excited about (or complain about?). This time around we got the unexpected news of a new language being released, Swift. Naturally I was interested in this, so I’ve done some reading on it and summarised some (This is heavily truncated compared to what I initially wrote) my thoughts below.

 

Why?

I have to admit, I was rather surprised to see a new language being announced. I still am to an extent. I’m not really sure why Swift exists at the moment. I mean, is it a tacit admission that Objective C has faults and it’s easier to develop something from the ground up rather than try and “morph” ObjC into something new? Or is there something else going on here?

A friend of mine posited the following as a potential reason for the language’s existence:

[Swift is] Apple’s apology for Objective C’s syntax.

He might have a point… ObjC certainly can feel like an alien environment when you first approach it, unless you happen to have a very particular path of experience. However, given that ObjC supports standard C syntax (duh) and you can run your code through as Objective C++ to allow line-by-line ObjC and C++ it feels that there is clearly space in both the language and the compilers to support further morphing of ObjC rather than something entirely new.

There has been a fair bit of progression in Objective C in recent times, obviously the presence of iOS has accelerated this immensely, the growth of the OS X market has played its part too. Prominent areas of development are the inclusion of code blocks and technologies such as ARC (Automatic Reference Counting) – these have both made their way into Swift in one form or another.

 

Pros and Cons

Swift simplifies a lot of common tasks, and it does them in a syntactically sensible and logical way. Iterating through ranges by using the Range operators in (1…5) is a welcome addition. Implicit typing is certainly part of the coding zeitgeist and for when you still need explicit type declaration, you do it in a JS-style way var 5.5 : float.

Optional chaining as a way of avoiding forced unwrapping is a great way of slimming down code. As daft as it sounds I’m actually quite happy that they used a question mark as the way of marking this up too, it feels “correct”. What I don’t like is how Swift is stricter on what counts as a boolean return (e.g. for use in an expression for an if statement) than what other languages would be. By way of an example, this will produce a compiler error:

let i = 10
if i
{
// code here
}

I get the logic in forcing things to be a boolean response, I just don’t like it.

Swift still doesn’t solve the main problem that has stopped ObjectiveC pushing itself into the top-tier of languages in terms of adoption, it still locks you into the Apple ecosystem. In fact, not only does it not succeed in solving this problem, it doesn’t attempt to solve it. It’s locked itself into the Cocoa frameworks tightly.

 

See part 2 of this post here.

Advertisements

One thought on “Thoughts on Swift (Part 1)

  1. Pingback: Thoughts on Swift (Part 2) | Fortune's Farm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s