1. We are here at GoTo Con Aarhus 2014, I’m sitting here with Marc Prud’hommeaux, Marc who are you?
I’m an independent iOS developer, I’ve been developing for iOS every since the SDK first came out and before that the Mac, and I have a line of my own apps in the AppStore that interoperate with relational backend databases like Oracle or MySQL, and the big project that I’m working right now is a data visualization tool called Glimpse, it allows people to create flexible visualizations to export HTML5 and allows people to communicate some of their backend data on the web.
2. And you write this for iOS in Objective C?
That’s right, well originally it was for iOS in Objective-C, iOS and the Mac, but I recently adopted Apple's new Swift language and I got ahead and ported all my code over to Swift.
3. Sounds like a big project or a fun project?
Yes, started out as a big project especially because the early days are Swift, the early betas could be difficult to work with because sometimes you didn’t have as great IDE support as you could later on, but in recent times I’ve translate the bulk of my code over now and I find I'm a lot more productive than I was in Objective C purely.
Well you can translate it class for class and you can do it incrementally because with a Swift you are able to mix a match Objective-C classes with Swift classes, so in theory you can start out with your simple model classes, and you can port them over to Swift and then you can go from there. I went the route of mostly doing a rewrite, taking some of the good ideas from that version of the app but taking advantage of some of the more functional paradigms that Swift allows and using those to, I feel, robustify and tighten up a lot of the code and my codebase.
5. So when you say robustify, make it more robust, how is Swift conducive to doing that?
Well it’s very strongly typed, it has Generics which is something that Objective C has lacked, but every other modern compiled language has had for quite a while, so for example with Generics you can really tighte up your code and say this list type contains just strings and you don’t have to ever think about what might happen if it didn’t have a string, the compiler guarantees all that for you. So when you have Generics and when you have the additional type safety that comes from a language with a very sophisticated typed system, you can have code paths you're absolutely sure will always result in what you were expecting without having to do a lot of branching and testing.
6. What’s the Generics implementation in Swift, is it like Java or like C++?
It’s closer to Java, you know you specify container classes and you can say, they take type T and that can subclass various things, you have a little more power and flexibility because you can take multiple generic types like with the dictionary and you can said those two types are interrelated in some way like one type is related to the other type and that it accepts a subtype for the first type as a parameter, so you have a bit more flexibility than you do in Java, it’s actually a lot closer to the Scala language which is a language that targets the JVM but comes a lot more from a sort of functional/object oriented hybrid paradigm.
You don’t have primitives, you have the equivalent of, say, Java’s boxed primitives in Swift, so Integer not int, and the nice thing about that is, it allows for optional type support, so that by default types do not accept nil, so in a lot of code you write it in Objective C, when it accepts a object parameter, there's a lot of boilerplate “If it's nil then return nil, if it's not nil then return something magical” and similar if it accepts a primitive, if it is zero or negative one, or MAXINT or MININT,, sort of special magical values that means “Do out of band handling”. In Swift when you have an optional type you can just treat those as if this is absent. So for example if you are searching for location in a list of some objects you’ll get back an optional and if it's nil it doesn’t exist, but by default all of the types are not optional and so you are really able to avoid a lot of that nul checking and not getting into weird bugs where you know you are passing a message to something but that thing was null and it takes a lot of debugging to figure out what’s going on.
8. What’s the module situation in Swift?
So modules have been advancing in Objective-C for the past few years, I believe it was two years ago that they first introduced module support from within Objective-C and exposed a lot of their own module interfaces as things you can dynamically import, and then the software performs automatic linking for you in XCode, by default it's configured to automatically link in those modules, so you don’t need to do a lot. With the advent of iOS8 and Swift 1.0, you are able to define your own modules so you can define one sort of set of frameworks that has a module and has its own namespace and then for another framework you can just import those modules and work with them, and it’s really nice for breaking up your code into separate frameworks, which additionally iOS now has as well, frameworks did not exist before iOS8 and it really helps for, modules helps for increasing the modularity of your code, and you can also cross platform modules which is really useful for me because right now I’m working on a cross platform Mac and iOS application and I’m using a lot of shared code that is just compiled down to a single framework.
9. So share between Mac and iOS?
You still need to be aware of platform differences, you know if you have a framework module for the Mac you can't import UIkit and things like that, so you do need to be aware of the context in which you are running, so often it will be for data model code and maybe for business logic code and things like that and for the UI code, then you’ll probably wind up having your own either frameworks specific to the platform or else you will just write that into the application itself.
Well I would say a lot of the functional aspects of Swift really change the way that I develop in Swift, functions are first class objects, they are equivalent to blocks in Objective-C but they are a lot more powerful, you can pass them to methods that are functions as you can in Objective-C, but functions can very easily return functions, function currying is something that comes from the functional programming language world which most languages, maybe Scala has a little bit, but I don’t think you can do it certainly not in Java and I don’t think you can do it in C#, and that really allows you to think in terms of high order functions and how you are going to be, your application will be composing functions and other functions and it will be more like a data flow that you can code more declaratively, and combine that with Swift's emphasis on immutable data structures, you can really, there is no pure function mechanism in Swift in the same way there is in Haskell.
But if you are operating just with functions and with immutable structures, you essentially have a system of pure functions and what that really allows you to do, is allows you to automatically parallelize your code without having to worry about shared mutable state and maintaining the locks and all the nightmares that can come with that, which is very useful for me because my Mac version of the App, I’m using all the cores simultaneously to perform the processing of various scenarios at the same time and I can as long as I’m pushing my immutable data structures through that, don’t really have to even think about managing that or locking on it.
So it’s not like, it’s probably the closest would be Clojure which is Rich Hickey’s language, Lisp variant that targets the JVM, has a lot sort of the lazy copy on write aspect to it, so in Swift with the structure, a structure in Swift is like a class, but a class is a reference type meaning that's essentially just passing the pointer to the object around and you don’t * in Swift and it’s a huge leap forward but they are still pointers. Whereas a struct is actually a value type meaning that it’s copied then it’s passed around, so that when you, if you have a structure that is something that you pass through the function, you never need to worry that other function is going to modify any other properties of that and then change it out from under you.
Now in theory it sort of, behaves as if everything was copied, the compiler does make optimizations when it knows that no one could conceivably be altering these things, then maybe it doesn’t copy your list of ten million items just because you passed it to a function that's just calculating the average of all of those values, but essentially all that complexity is shielded from the developer, so as long as you program in a certain style you can be basically certain that your immutable data structures won’t be changing out from under you, which makes concurrent programming a lot easier and makes asynchronous programming a lot easier, it really helps out in a lot of the areas where the former sort of procedural and object oriented mechanisms fall down a little bit.
I mean it is largely different clothes, there's nothing that you can magically do in Swift that you can’t do in Objective C, since that you are running in the same runtime, have the same libraries for concurrency, it doesn’t automatically provide you things, you know you might be referring to something like C# async support, there's nothing really quite like that in Swift yet. So you wind up using the same underlying frameworks for concurrency management, you'll be using Grand Central Dispatch which manages your simultaneous processes for you, but the big changes are with the addition of first class functions and with immutable data structures you can really not have to worry about a lot of the complexity that you once did.
No, I’m delighted, I’ve long been a big fan of the movement towards more functional paradigms coming into programming languages especially with languages like Scala and Clojure and things like that, and I really think it’s a huge step forward, it’s a matter of great debate right now in the development community, I think a lot of people adopted it very rapidly and the then the honeymoon was over and maybe they had a little bit of a hangover and missed some of the dynamic dispatch features of Objective-C that you’ve largely lost in Swift, but I personally feel that it’s far and away more productive and I write safer code and I just spend less time, less time worrying about bugs with simple things like nulls and with you know wondering is a type in my Array really the types that I expect and things like that. It’s all very fluent to Objective-C programmers but you do wind up writing up a lot of boiler plate code that you might not always be aware of how much time you are spending, but when I go through and look at the equivalent classes that I’ve written in Swift and Objective-C, my Swift classes are much more compact and much more readable than my Objective-C classes.
14. It’s a very interesting experience report, and where do we find your products on the web?
My company is called Imphatic, my line the database products is called DataGlass and my data visualization app version 1.0 for the iPad has been available for the iPad for a while, and 2.0 is coming soon and it will be 100% Swift.
Werner: Excellent, thanks a lot Marc!
Marc: Great, thank you very much!