Thoughts on Swift (Part 2)

This is part 2 of my “Thoughts on Swift” post. See part 1 here

Immutability inconsistency

Swift has some really weird behaviours when it comes to what counts as immutable and what doesn’t. The following twitter post explains and demonstrates it very well. Note: These are *designed* behaviours and are functioning as expected as per what is in the language guide. Ugh…


A Couple of Quick Additional Oddities

  • Enumerations can have methods etc. Simply feels a bit odd to me, but probably ultimately very useful given the right circumstance. I expect abuse of this feature to be prevalent 🙂
  • Swift has the concept of Extensions (Categories in ObjC) and although I use features like this, I always feel like I’m maybe breaking the second principle of SOLID, namely, “Open for Extension Closed for Modification”. I mean this in the sense that when you are adding functionality to an existing class without deriving from it, you ARE modifying it and not extending it. i.e. The *original* class now has a different set of behaviours to what it had before – calling it an “extension” is a slight of hand.


A key part of any language is not so much to do with the syntax and features that it offers, but more to do with the adoption of said language by developers. A particular language can live or die depending on what libraries are available for it. This concept spreads to toolsets as well as languages, just think of the many “out of date” scientific tools that are still in common use. Sometimes systems become so large or so “embedded” in a particular industry/market that it requires seismic shift in that particular industry to jolt it into action to update and/or move away from it.

Despite my initial misgivings of Swift (these posts have been on the negative side), I know I’ll end up developing with it. The primary reason for this is that I can well imagine ObjectiveC is going to have little-to-no real development on it moving forward. I however don’t anticipate anyone bothering to do rewrites of their ObjC libraries to Swift, as Apple have made it so there is neither a benefit nor a penalty for doing so.

This is smart and should drive adoption of Swift at a pretty decent rate, at least amongst developers inside the Apple ecosystem already. It doesn’t do much to entice more in I don’t think.

I think, for a while at least, I’ll probably sit on the side and watch Swift develop before launching into it “full-on”. For the moment, let’s enjoy seeing recruiters starting to post job ads asking for 3+ years Swift experience eh? 🙂


One thought on “Thoughts on Swift (Part 2)

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

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s