Monthly Archives: February 2015

My Defense of Swift

**Note: I am using an example in my blog of a post written by a developer in our community. I have noticed many posts with the same thoughts expressed in them and I am in no way attacking this particular person, who I respect a great deal. I want to preface this with saying I am in no way attacking the author of this piece or trying to single him out, so I hope he will not be offended that I am offering a counterpoint to his post.**

This morning I had someone send me a link to this article and asked me what I thought about it.

Honestly? I am kind of sick of everyone crapping on Swift.

I am tired of everyone saying the language is broken and that you can’t write real applications with it because it’s half baked and unusable.

I don’t mean to keep waving my credentials around, but I am working on a project where we are rewriting our software in Swift. We are not writing the usual weather app/something that pulls data from an API. This is some heavy duty crap. We are writing this on the Mac. We are using a serial port to connect to outside hardware. This is a legacy project that is on its third rewrite that has been around for ten years. So far we have not encountered anything that we can’t do in Swift that is being done in the original software.

For the last month or so I have been bashing my head against a project where I am implementing libXML in our project (which I am going to write a blog post about shortly.) Taking a really under documented C library where the sample code is written in Pascal and trying to get it to work in Swift has been a demoralizing massive pain in the ass. I have had to deal with all kinds of horrors that I didn’t know existed or were abstracted away so that I would usually never have had to deal with them again.

However, doing those things has made me a better developer. Just because I came into Cocoa programming after ARC doesn’t mean that I have no reason to think about it or know how it works.

I started learning programming three years ago. Prior to that, I didn’t know how to write a “for” loop without looking it up online. I was one of those noobs that people hate on Stack Overflow who ask how to do incredibly simple and stupid things. Learning programming was hard. It forced me to fundamentally change the way I think about the world. It was also hard because I had a lot of people who had been doing it longer than I had who were crapping on me because I didn’t know who the Gang of Four were or why we do the MVC pattern, or even what MVC means.

There are a lot of things that we think are easy and intuitive that aren’t either but we think they are because they are familiar. My boss told me about working with a woman who had a PhD but had never used a computer before. Our structure of navigating through folders and files is “intuitive” to us because many of us have been doing this for bordering on 30 years.

If you have been doing imperative programming since you were 12, then yeah, some of this stuff is going to feel complicated and unfamiliar. If you don’t have a painful, visceral memory of the pain it took to learn programming the first time, you might think that all of this stuff is complicated and broken and wrong.

I, however, do remember how hard learning programming was. I find learning functional programming and figuring out Swift to be no more difficult than it was learning Objective-C. It’s different. It isn’t broken. Yes, there are some things that will be refined over the next few years, but Objective-C wasn’t born completed either. It evolved over a period of years as Swift will evolve.

I got into programming because I wanted to learn how to solve complex problems. I am excited about Swift because it affords an opportunity to solve a complex problem in a different way than we did before.

I am worried that people’s opinions of Swift are being influenced by a few people’s bad experiences with it. When I have tried to advocate for Swift because of the work I am doing, I get my experiences brushed off because of my boss. I am told that of course Brad Larson can use Swift to control robots. He’s a genius. Us normal people can’t use it because it’s too complicated.

Again, there is a difference between broken, complicated, and unfamiliar. If you go into Swift thinking it should be just like Objective-C, you are going to be disappointed. If you go into it knowing that it is unfamiliar and that you have to fundamentally approach things a different way, then you might be okay with it. If programming was easy, then everyone would be doing it. Just because something is different than the way that you are used to doing something doesn’t mean that it is wrong.

I hope that people who are discouraged will eventually change their mindset about how to approach Swift or some other hybrid language with functional features. Life gets boring if you just do the same thing over and over again in the same way. Programming is a young discipline and we haven’t yet reached the point where we absolutely know that the way we are doing things is best. It will continue to grow and evolve and change. And that’s a good thing.

Functional Programming in Swift: Chapter 2- Thinking Functionally

*Note: I strongly recommend following along in the book with this blog post. I am not going to be recreating the diagrams or the code here, so if you don’t have the book open when you are reading this post, you will be very confused and I would not like that.*

This first full chapter of Functional Programming in Swift introduces one of the most important new concepts in Swift: Higher Order Functions. I will get into higher order functions in a moment, but first I would like to give a little bit of context as to what the example of the chapter is about.


The example used for this chapter is called Battleship. I, like many other people, associate Battleship with the board game. Since many programming textbooks use common games with known rules to teach programming concepts, it was understandable that many people thought that this example would be about the board game Battleship. This is not the case.

Back in 1994, the Office of Naval Research was exploring rewriting some of its defense software. Like any good agency, they didn’t want to just pick a programming language out of a hat. They wanted to benchmark which language would be the most efficient language to use for this project. They were concerned with a few factors:

– Development Time
– Lines of Code/How Concise is the Code
– Human Readability
– Maintainability

For a very long time, functional programming languages were considered to be impractical for real world applications. They were an interestring curiosity and another approach to programming, but the enforced static nature of functional languages and the lack of mutable variables seemed to doom functional languages to never be implemented in actual projects.

This study proved that a purely functional language could not only be used effectively in a real application, but also proved that this approach could be even better than an imperative approach.

If you look over a lot of the examples in this chapter, you will notice a lot things that are not present in our traditional games of Battleship:

– Checking the range of your weapons
– Avoiding engaging enemies too close to your ships
– Taking the location of friendly entities into your equations

These are not things we think about when playing the board game Battleship, but they are incredibly vital things to consider if you are a naval ship engaged in battle with actual enemy combatants. These are not small considerations. You don’t want to accidentally frag your fighter jets when you are aiming for an enemy ship. Any targeting program that you design must account for all of these considerations.

This beginning chapter takes this example and shows how Hudak and Jones were able to work around these constraints in a functional manner that was more efficient and easier to maintain than the traditional imperative way of approaching these problems.

Imperative Complexity

Our initial calculation is very simple. We are assuming our ship is at a location and we are trying to determine if another point is within range of our ship. Our range is represented by the radius of a circle and we are simply passing the location of our ship (position) and the distance we can shoot (range).

We are then using the Pythagorean Theorem to determine if our target point is within range of our ship. a squared plus b squared equals c squared. In our case, target.x squared plus target.y squared should be less than or equal to our range squared. Our first function is taking the square root of the two target coordinates and returning it only if this qualification is met.

In order to keep things clear, we are using a type alias so that we don’t have to remember that the CGPoint object is our position and the CGFloat is our distance. We will see type alias again, so don’t forget it.

So far, so good.

As the program grows in complexity, it becomes harder to continue to maintain the function. We keep adding additional parameters and constraints. I am going to honestly say at this point I developed code blindness and stopped looking at the code. Suffice it to say, this once simple function grows to a large mess of spaghetti that kind makes me weep for the future of human civilization.

I am not going to untangle the spaghetti code because we aren’t supposed to be doing this anyway and I am not going to encourage you to write unmaintainable code. Bad Swift developer!!

Going to skip ahead to the functional way to deal with these constraints.

The Functional and Rational Approach to This Problem

There is one very important thing to remember about functional programming versus imperative programming:

– Imperative programming is about telling the computer how to do something.
– Functional programming is about telling the computer what to do.

In the above spaghetti code, we were getting over wrapped up in how the conditional logic would deal with all of the various contingencies of our problem. If our point is in range but it is also too close to a friendly, what do we do? It is easy to get overwhelmed by the complexity of implementation.

So let’s take a step back and ask what are we actually trying to do, without thinking about how it will get done.

We want to know if our point is in a region where we can target it.

Remember when I told you to remember type alias? We are bringing it back here. A type alias allows you to assign a label to an existing type so that if you have multiple objects/properties/variables that are all the same type, you can assign a label to the one specific instance of that type.

We know that strings and numbers and classes are all types, but there is another thing in Swift that now qualifies as a type: a function.

Functions in functional programming are values, no different than strings or structs. They can be passed around and referenced exactly the same way you would work with any other kind of value. The best analogy I can think of for this is a string. In C we didn’t have real strings. Stings were an array of chars that were eventually, in later languages, encapsulated into their own type. As you work more with functions as their own discreet values, it should get less weird to think of them in this way.

We can create a type alias for a specific function type. In the example in the book, we are creating a type alias for a function that takes a Position as a parameter and returns a Bool.

So instead of our initial function that uses the Pythagorean theorem and returns the result of that calculation, we are instead returning a closure that performs the calculation. Closures are simply unnamed functions. Basically we are taking the logic we had before and putting a nice, shiny function wrapper around it. We are wrapping a riddle inside of an enigma.

Why would we want to do this?

Let me give you a real world example of this in practice:

I work at a company called SonoPlot. My boss, Brad Larson, wrote a blog post about our project to rewrite our robotics control software in Swift. Since we are dealing with interacting with hardware, there are a lot of things that can go sideways that you don’t have to deal with when you are working with just software. Sometimes something goes screwy when we are communicating with the hardware and if we just send the command again it will go through just fine. Other times, the hardware is disconnected.

We don’t always know which one of these situations we will be in. We don’t want to keep sending commands to our robotics if they are not connected or on. Alternatively, we don’t want to tell the user that the robotics are not connected when they actually are.

To get around this situation, we created a special function called “runCommandAndAttemptSoftRecovery()” that takes a function as a parameter. We wrap many of our hardware functions in this function. “runCommandAndAttemptSoftRecovery()” will try to run the function we are passing in and if it doesn’t pass, it will attempt run the function again. If the function fails a second time, we handle the error.

Sometimes you will have some functionality that is important to apply to many parts of your project, such as our hardware commands. In times like those, being able to pass a function into the function makes it possible to reuse a piece of code in ways that weren’t possible with Objective-C or an imperative language.

In the example in the chapter, we are trying to figure out a way around the creepy spaghetti code and conditional logic. Rather than creating one Frankenstein’s Monster of a function that has to account for all of these things, we are creating a lot of small functions that account for discreet parts of this problem.

We check if the point is within range of the circe. We check the offset. We write a function that combines known areas that are in range so that they are in one data set instead of two. Each of these functions returns a function of the same kind, so they can work together to narrow down more discreetly if a point is within range of the battleship without hitting a friendly craft.

This is a rather difficult example to explain and I will honestly say that at this point I can only explain it on a high level. I strongly recommend looking at the final code and referring back to each individual function to see how they work together. There are truly reusable functions in the final function that behave differently based on their inputs and parameters. Sometimes looking at a final piece of code and following the logic through its various rabbit holes is the best way to understand how something works. That’s why we dissected frogs in high school biology class, even though I swear some of my teachers were sadists….


This is an introductory chapter. It isn’t expected for you to genuinely grok all nuances of functional programming from this.

Here are the points I would take away from this chapter:

  • Start thinking about what you want your code to do rather than how you are going to implement it.
  • Start trying to mentally break things down into smaller pieces. Instead of having some big, scary function full of state and conditional logic, think about what you are trying to do in smaller steps.
  • Get used to the idea that functions can be passed around like variables. Think of functions as things that take one thing and turn it into something else. If you have a piece of wood, that can be turned into many different things. It can be a table, a desk, or a bookshelf. If you think of a function that takes a piece of wood and returns a piece of furniture and think about how each piece of furniture can be different, this might give you a better idea about how to conceptualize passing functions in Swift.
  • Don’t get discouraged!! This is a different way of thinking. It isn’t going to be intuitive. I have been working on this for nine months and I have barely gotten to the point where this chapter makes sense. That is one reason I am doing these posts. This is just to get your feet wet with some functional concepts. You are not expected to fully understand everything at this point in time. If you feel dumb right now, join the club. You’re not the only one. Just keep working at it and eventually something will click.

I wanted to recommend some resources I am using to try and work through this book to get these concepts to make more sense:

I will try to add to my list of resources as I encounter new ones. If people have sources they particularly like and want to make me aware of them, please ping me at @redqueencoder

Again, if a lot of this is still super confusing, that’s fine. You’re in the right place. We’re all trying to figure out how to please our new functional overlords. It will take a while and no blog post anyone is going to write is going to make this immediately intuitive. Think back to when you learned programming for the first time. It took a while, didn’t it? Learning how to think takes some time and some work. Don’t get down on yourself. Keep at it.

Up next, we are tackling some Core Image. Stay tuned!!

Doctor Who: Series One- Dalek



Ah yes, the inevitable Dalek episode. It was always coming. It would be like having a Star Trek series without Klingons. It just wasn’t going to happen.

It’s hard to remember a time when the Daleks hadn’t been run into the ground. After half a season of new villains, it’s kind of nice to see a familiar face. We are also treated to a few breadcrumbs about the Time War that destroyed the Time Lords.

The Dalek

I do have to admit, I was a little more thrilled at seeing the Dalek than I thought I would be. Even though the species has been retconned and run into the ground, the moment when the lights come on and the Dalek starts yelling “EXTERMINATE!!” is still incredibly exciting. The reveal was done incredibly well and this has helped this episode age pretty well.

It can be hard figuring out a good way to reintroduce an old character to audiences who may not be familiar with the source material. Seeing how genuinely terrified Eccleston looks after handily dealing with a bunch of crises over the last few episodes is one of the reasons this episode is still so effective.

I realized that nearly every Dalek episode from New Who follows the same theme of them finding a Dalek that seems to be different than the other Daleks, one that has feelings and is capable of growth. The companion tries to convince The Doctor that this one is a special, unique snowflake. The Doctor gives the Dalek a chance, only to find out he was right all along. It’s really repetitive. It’s like watching Lucy snatch away the football from Charlie Brown.

I haven’t watched any Old Who, so not certain if this repetitive theme was actually a new idea back in 2005.

The Doctor

Eccleston does a tremendous job of selling The Doctor as someone who can be genuinely menacing. He spends a lot of time in the series being cuddly and adventurous, but this episode really drives home the point that The Doctor is a powerful being who has killed people in the past. He is the sole survivor of a war that wiped out two races of people, one of which was his own. The first few episodes sell him as the lonely god, the last of his kind. This is the episode where you realize that he is the one responsible for him being the last of his kind. His confrontation with the other last member of a wiped-out species is incredibly tragic.

On one hand, you can point to him and say that he made choices. He pulled the trigger that wiped out two species and he survived. What does he have to complain about?

It’s incredibly difficult to make the hard choice and to live with its consequences.

The Doctor’s interaction with the Dalek force him to process and deal with something he’s been running from since “The End of the World.” He doesn’t want to think about how he is responsible for a mass genocide. He wants to heal and explore. He didn’t want to be put in the position of destroying his own people. He wants to forget. This theme is explored in much greater detail during the 50th anniversary special, but it’s bones are established here, in this episode.

Facing uncomfortable reality.

Facing uncomfortable reality.

The scenes watching him torture the helpless and ridiculous looking Dalek are kind of disturbing. We’re used to this idea that The Doctor saves people and does impossible things. Watching him sink to a level of torturing a helpless creature and enjoying it is terrible.

I am actually interested in how many times The Doctor does terrible things. I know he’s done many over the course of the new series, but every time we encounter one it’s always disturbing.

On some level we expect The Doctor to be better than us. He’s not a human. He has lived for a thousand years. We expect him to be above all of our petty, meaningless concerns, to be more than we are. Watching him behave like a beast who enjoys tormenting the Dalek is terrible, not just because the act itself is terrible, but because the person doing it should be beyond such behaviors.

Adam Mitchell

We’re going to get into him a little more in the next episode, just wanted to mention that we are going to see him again.

Henry Van Statten

It’s nice seeing what the British think about Americans, but all things considered, if the Daleks were real I could totally see some asshole one percenter being the person who collects extra terrestrial artifacts.


This was an important episode in that it brought an iconic villain back to the Whoverse. I guess I didn’t have as strong of a reaction as I thought I might all things considered. The episode was good, but its impact has been blunted over the years by seeing the same Dalek story over and over again. Supposedly this Dalek and The Doctor are the last of their kind, yet the Daleks keep coming back over and over again. Why is it that the Daleks can keep coming back over and over again, yet the Timelords are irretrievably lost in time and space and meaning? Hell, we found out a year ago that they are still out there and not a peep about them in the current season. Well, except for The Master, but let’s not get into his own problems right now…

Up next, we have “The Long Game,” in which we find out what happens when The Doctor picks up someone who isn’t really meant to be a companion.