First impressions from Swift programming language

Swift first impressions featured image

Hello fellow programmers!

A language for a programmer is his/her ultimate medium of expression, we are spending thousands of hours editing the code, thinking in the code (sometimes even dreaming in the code :) ). So it’s no surprise that introduction of new programming language from Apple was the most exciting event for us at the WWDC conference this year.

After spending some time on analysing this new programming language we have a few spots that we want to share with you. We are really excited about Swift. It looks like a much cleaner language then Objective-C. Below is our list where + means pros, - cons and +/- something in between ;).

 

General

+ no need for semicolons

+/- ranges – Although we really enjoy the addition of ranges, the syntax for it is a bit confusing. It is really easy to miss one additional dot character.

 

Error handling

+/- assertions – We are not sure about the decision of disabling them in the production code. Although you should eliminate situations like that in the production code, if you happen to forget to do that, they can provide you with a nicely formatted feedback.

- no exceptions – We don’t see any easy way to control exceptional flow of your application. Was it a design decision?

 

Variable and constants

+ var for declaring variables

+ let for declaring constants

+ tuples – You can use them with optionals and enums for error handling

+ type inference

+ optionals – Really good protections against nils, the motivation for such a solution has a good explanation here: http://deanzchen.com/the-best-design-decision-apple-made-for-swift

 

Operators

+/- == for equals, === for identity check – getting used to this change can be painful at start. Also to define your own equals you need to use operator overloading.

+/- operator overloading – you can override an operator for your types, but you do it by a global function

 

Functions

+ there is no visible distinction between a function, a method and closure – you can now do a lot of functional programming stuff (functions are first class citizens – you can have a function as a parameter to another function, you can return a function from another function, hooray!)

+/- functions with more than one argument – We find the new syntax of calling methods and functions a bit confusing and inconsistent. The first parameter without a label, next parameters with labels (unless it is an initializer and you haven’t specified other rules with # and _ characters)

 

Classes

+ automatic imports

+ default values for properties

+ is – shorter than isKindOfClass and still self-explanatory

+ as, as? – really simple and safe (because of the optional mark) type casting

+ AnyObject, Any

+ generics – welcome type safety in collections :)

+ subscripts – nice syntactic sugar

+ override annotation – the compiler can warn you about accidentally overridden methods

+/- only properties, no instance variables – if you override your getters and setters you don’t have access to the instance variable. Probably you need to declare an another property to store your value (or is it an instance variable then, like in C#?)

- class keyword for static (type) functions – why not one keyword for classes, structs and enums?

- no access modifiers – this is the most problematic issue with Swift right now. You can still use conventions (underscore in the name for private methods), but it is nice to have some mechanism to control that. We heard that it will eventually have it (https://devforums.apple.com/thread/227288).

- no (or bugged) method overloading – right now you can write functions with the same names and different parameter types, but at runtime only the first one will be used (for all types)

 

Structs and enums

+ value types – structs seem to be excellent for little domain types (http://en.wikipedia.org/wiki/Value_object)

+ enums – you can encapsulate all your switches in one place

- mutating – it seems to be really weird to have immutable structure which sometimes is mutable

- array – it is really hard to understand when two arrays are no longer the same

- static for static (type) functions – why not one keyword for classes, structs and enums?

 

Summary

As you can see we identified much more pros than cons. Readability and clarity of Swift is much higher than Objective-C, it looks that it will be a real joy to write applications in this new programming language. The biggest pros for us, except elegance and clarity is incorporation of functions as first class citizens. It looks that learning functional programming paradigms was not in vein – now we will be able to use at least some functional programming idioms in Swift :D. Also we love the way Apple tackled the nil problem – optional values is a bold decision that should greatly improve reliability and maintainability of iOS applications. And last but not least: let and var keywords for constancy and variable declarations, finally there is a language that doesn’t assume by default that you want a variable. In fact, the opposite is true: what you want is usually just a constant and now we have a very nice way to express this by the let word. Also there is a beautiful symmetry here: when you want a variable you have to declare it with var. So there is no default, you always have to use var or let, two 3 letter words that will indent the name of your constants or variables by exactly the same number of characters.

Kudos to language designers. Thank you!

  • raky

    Great info thnaks

  • http://matter2energy.wordpress.com/ Maury Markowitz

    “+ let for declaring constants”

    In the few languages that have used LET over the years, it’s meant “var”.

    Would it really have been too much to use “const” or even “con”? That is far more obvious.

  • http://matter2energy.wordpress.com/ Maury Markowitz

    “- no (or bugged) method overloading – right now you can write functions with the same names and different parameter types, but at runtime only the first one will be used (for all types)”

    Interesting… I ran into the same thing in VB.net. If you call your assembly from COM, which we do because it’s a VBA object, only the first method is visible. This is a bit of a drag because it means we had to make a really complex “first method” that decodes the inputs and then dispatches to the actual polymorphic versions.

    “- mutating – it seems to be really weird to have immutable structure which sometimes is mutable”

    Yeah, that one confused the heck out of me too. It just seems random.

  • Szymon

    Why don’t you mention about performance of swift language? Comparison with objc would be great.