By:
Comments Off

A Familiar Form

Last week, Apple introduced a brand new programming language for iOS and OS X development, called Swift. During WWDC, I attended every Swift presentation and spent time in the labs chatting with the engineers responsible for this new language. While I've had less than a week's exposure to this new language, I have some thoughts.

Generally, I'm impressed. Swift is the kind of radical departure from the existing Objective-C language that I was hoping for. Sure, it's a radical departure, but is it radical enough?

Swift gets rid of a lot of cruft of Objective-C syntax while keeping some of its key features, like named parameters, around. But it also keeps around things that aren't necessarily a good thing. Let's take a look at a basic example.

func compute (x: Int) -> Int {
    return x*x
}

compute(4) //prints 16

This is a basic function definition and a corresponding invocation. A few things jump out that should be familiar to Objective-C developers. First, we have brace brackets delimiting the scope of the function. Lots of languages do this, but plenty don't, as well. We also see a familiar, C-like syntax for invoking the compute function.

Swift could easily have looked like this, a more Haskell-friendly syntax.

func compute x: Int -> Int 
   x*x

compute 4 //prints 16

Less familiar, sure, but would be just as valid if you're designing a whole new language.

When I asked an Apple engineer about these kinds of constructs, his answer was that familiarity with existing Objective-C developers was an important factor in the design process of the language.

Familiarity is important, certainly. We need existing developers to embrace Swift in order to avoid a situation where this new language languishes. However, while it's important for the sake of developer adoption, will it lead to the best language possible?

Maybe. Maybe not.

I feel that Apple may be making compromises on the language design for the sake of familiarity with developers, sacrificing what could be an even better syntax for the sake of developer penetration. Maybe this is the right choice, maybe it's not. I hope that they know what they're doing, and I hope that future revisions of the language aren't burdened with these familiarity considerations.

/Ash Furrow /Comments Off
By:
Comments Off

ReactiveCocoa 101 at AltConf

I had a great time this week presenting about ReactiveCocoa at AltConf. Check out the video here.

/Ash Furrow /Comments Off
By: Comments Off

Swift Initializers

Swift, Apple's new programming language for iOS and OS X, makes several significant departures from Objective-C. What I found to be particularly interesting are the new semantics surrounding object lifecycles. Here are the key points:

  • Formalizing convenience and designated initializers.
  • Formalizing sequence of operations for initializers.
  • Enforcing language-level, compile-time enforcement of these new semantics.

I'm going to cover each of these in depth, with examples. Let's dive in!

Initializers In-Depth

In Objective-C, things are pretty loosey-goosey when it comes to how you construct your initializers. For instance, you could call super, or not, or call init on an entirely different class. You can set up ivars and properties before you init, even though you're not supposed to, and while you're actually not supposed to access methods or properties inside any init method, everybody does. It's really the wild west.

That's not the case in Swift. Swift has a very clear, specific sequence of operations that are done in initializers. Let's start with some basic examples are work our way up to a general case.

Let's take an object A. We'll define it as follows.

class A {
    var x: Int
    init(x: Int) {
        self.x = x
    }
}

Notice that A does not have a superclass, so it cannot call a super.init() function as it does not exist.

OK, so now let's subclass A with a new class named B.

class B: A {
    var y: Int
    init(x: Int, y: Int) {
        self.y = y
        super.init(x: x)
    }
}

This is a departure from Objective-C where [super init] would typically be called first before anything else. Not so in Swift. You are responsible for ensuring that your instance variables are in a consistent state before you do anything else, including calling methods (which includes your superclass' initializer). Neato.

But there's one more hitch. Say that we want to make sure that x is always set to a value computed by a method in our class? We can't call a method on B until we call super's init. We'd actually write something like this.

class B: A {
    var y: Int
    init(x: Int, y: Int) {
        self.y = y
        super.init(x: x)
        self.x = self.generate()
    }

    func generate() -> Int {
        /* return some value */
    }
}

That's right. If you want to access a superclass' property,you must do so after calling super.init() in order to give the superclass a chance to set them first.

In general, a Swift object initializer looks like the following:

init(/*parameters*/) {
    // set own properties, if necessary
    // call super.init()
    // set superclass' properties, if necessary
}

Convenience and Designated Initializers

Swift formalizes the common Objective-C pattern of designated initializers into something checked at compile-time. This is actually really, really cool. Let's take a look at a new class hierarchy.

class A {
    var x: Int
    convenience init() {
        self.init(x: 0)
    }
    init(x: Int) {
        self.x = x
    }
}

init(x: Int) is the designated initializer for this class and all other initializers in A must have the convenience. Convenience initializers can call other convenience initializers, or the designated initializer.

Let's take a look at a subclass. This is where things get interesting.

class B: A {
    var y: Int
    convenience init() {
        self.init(y: 0)
    }
    convenience init(y: Int) {
        self.init(x: 0, y: y)
    }
    init(x: Int, y: Int) {
        self.y = y
        super.init(x: x)
    }
}

Convenience initializers in a subclass may only call other initializers in their own class. Only the designated initializer may call an initializer on the superclass.

Missing Objective-C-Style Semantics

Swift departs from Objective-C initializers. Consider the old style initializer.

-(instancetype)init {
    self = [super init];
    if (self) {
        // setup
    }
    return self;
}

There are a few distinctive parts to a classic Objective-C initializer. First, you need to assign self to something, either your superclass' initializer or another initializer on self. Then we check if the reference to self is valid (maybe the initializer that we called returned nil). We do some setup, then we must return self.

In contrast, Swift initializers are very straightforward. Initializers don't return self, so you don't need to return self. Cool! However, this has a implication. In Objective-C, if initialization fails, we can return nil in order to indicate that failure. Since Swift initializers don't return a reference to self, this approach is not possible.

I spoke with an Apple engineer at the Swift Lab at WWDC and asked about the pattern. He indicated that this was not currently possible. Instead, we should use factory methods that return an optional type.

class A {
    class func anything() -> A? {
        return A()
    }
}

He indicated that they're working on building something into the language, since initializers are the preferred way to create instances (as opposed to factory class methods). For now, this works well if you need this kind of failing initializer pattern.

Neat! Swift has really embraced the conventions that Cocoa and CocoaTouch developers already know and incorporated them into the language-level with compile-time checks.

/Ash Furrow /Comments Off
By:
Comments Off

Initial Thoughts on Swift

Yesterday, Apple announced a brand new programming language as a replacement for Objective-C called Swift.

Super cool. I wrote about replacing Objective-C a few months ago, and I'm glad to see this update from Apple. Here was my list of criteria for a "good" replacement:

  1. It shouldn't use pointers, structs, header files, anything C-based
  2. It should be a memory-managed language (No ARC, not retain/release, no Core Foundation)
  3. It should have native, unicode strings and native collections
  4. It should be concise
  5. It should have named parameters

It looks like everything except memory-management has been checked off, and I haven't played around with it enough to determine if it's new memory management system is up to snuff, but from what I've seen so far, I am very impressed with Swift.

I'm very impressed with Apple's book on Swift. It's great that this stuff isn't sealed under NDA.

I'm planning on writing at least one book on Swift, which will be out in the coming months. While I'm impressed with the resources Apple has released, I think that there is room for some third-party resources, too.

/Ash Furrow /Comments Off
By:
Comments Off

Feels

It's been a while since I've written on here, in part because I've been busy at work, in part because I've been on other writing assignments, and in part because my depression has gotten the better of me since adjusting my medication a few months ago.

However, the past week has been amazing. I've been in San Francisco in the lead up to Apple's WWDC next week. I've been spending time with some amazing people and making new friends, while growing closer to existing ones. I've been so filled with energy after seeing so many mates again for the first time in years, in some cases. It's been great.

I met with a doctor a few weeks ago to adjust my medication for something better suited for me. I think it's starting to work. I've begun talking openly about my depression with my friends (previously it was only really mentioned on this blog), and they've all been super-supportive. I'm lucky to be surrounded by such awesome people.

Anyways, you probably won't hear from me again for a few weeks. I'll be busy at the conference, and then writing some iOS 8 tutorials which'll stay under wraps until the NDA lifts. I'm confident that I'm turning the corner on this and, while it's been really hard over the past few months, I feel like I'm on the mend.

/Ash Furrow /Comments Off
By:
Comments Off

Core Data Course

I'm really excited to tell you all about my new Core Data Course at Treehouse.

The course covers the basics of Core Data and includes steps to create a re-usable, general-purpose Core Data stack. It covers what managed objects are and where they live in a typical Core Data stack, and much more. I had a blast recording this course and I hope that you enjoy it.

Check out the trailer video for more.

/Ash Furrow /Comments Off
By:
Comments Off

Mobile Couch

Last week I was on the Mobile Couch Podcast discussing ... you guessed it, ReactiveCocoa! This is similar to my iPhreaks episode, but is more introductory. Plus I love an Australian accent. Check it out!

/Ash Furrow /Comments Off
By:
Comments Off

Up and Running with MindSea

Earlier this year, I worked with a fantastic company in Halifax named MindSea. I had a great time working with them remotely and I did a little write-up about my time with them, talking about proper abstractions and modularization. You can read my post here.

/Ash Furrow /Comments Off
By:
Comments Off

Science of Happiness

This morning I watched a very interested TED Talk on happiness, which is obviously very relative to me given yesterday's blog post.

In the Talk, Dan Gilbert discusses the idea of synthetic happiness, the concept that we can manufacture our own happiness, even if we don't get what we want.

We smirk because we believe that synthetic happiness is not of the same qualty as what we might call natural happiness.

This really struck out to me. It reminds me of another TED talk discussing the paradox of choice, the phenomenon where people with more choices are less happy because they're worried that they won't make the correct choice.

We are apparently really bad at predicting our own happiness due to something called impact bias: we overstate the impact that getting what we want will have on us. Instead of striving to always get what we want, focusing on our mental states of mind will have a far deeper, longer-lasting effect on our happiness. Cool.

/Ash Furrow /Comments Off
By:
Comments Off

Depression Sucks

So yeah. I blogged earlier this week about a lot of things, including how I was tapering off my medication.

Mmhmm.

Yeah, it turns out that that's actually really really difficult. Like, insanely difficult.

...

Really difficult.

Up until a month ago, I had been on two drugs. I completely tapered off one of them a few weeks ago (huzzah!). Then I halved my dosage of the other one. Oh boy. I did so mid-last week and spent most of the Easter weekend asleep or lying down staring at the ceiling because I didn't have the energy to do anything else. It was debilitating.

So then this week rolls around and I get to the office. Sort of. I spent Monday in my pyjamas doing my best to stay focused on coding. It was one of the hardest days I've had in a long time. I find myself losing focus on what I'm doing, easily distracted.

I still have emails waiting to be replied to – really simple tasks – that I just can't do. I'm struggling to find the motivation to get out of bed in the morning to do a job that I really really love doing.

You even find yourself crying but you don't know why? Imagine that feeling – of not understanding why you're sad – but constantly, all day, draining you of energy and motivation. The slightest setback during any task is throwing me way off.

I've never really talked about how bad my depression really got. In the Fall of 2012, when I was under insanely intense pressure at work, I was contemplating suicide on a daily basis. My wife was doing a work term away from Toronto, so I was living on my own, working 70-80 hour weeks for two months. The only thing that I could do to stop those compulsive thoughts was to tell myself that no one would be around to look after our cats if something happened to me.

This past weekend has reminded me of that time. I find myself questioning weather or not I was ready to take this step. On the one hand, I wanted to stop taking medication because I felt that it had helped me get through the roughest patch – to get enough energy to fight depression using self-talk techniques and meditation. On the other hand, maybe halving my dose of the second drug came too soon. I haven't been diligent about meditating since moving to Amsterdam, so I really need to get back on that.

I'm going to give it some more time, since I am getting better as time moves forward. However, going from my half dose down to nothing is going to be really, really hard. Since I have a lot of travelling in May and June, I might leave that next step for July. We'll see.

/Ash Furrow /Comments Off