Stop mutating, evolve

Forgive a slight divergence. I’ll bring it back to software development before the end.

A friend of mine is an arborist. He takes care of a large forest, trimming and culling trees. He’s quite good at it and enjoys it, but he’s worried about job security. He thinks cabinet making would be a good career move. He likes to work with wood, and high-end cabinets are very expensive so there’s clearly a lot of money there. I’m a hobbyist woodworker, so we were talking about it.

My dad has always been an engineer, but by the end of his career he had three-letter titles starting with “C”. And all my life he’s taught me lessons, but the most important ones to me professionally were never about technical matters; they were always the talks about how large companies work. Watching some of the reactions from devs to the recent Taylor Swift/Apple back-and-forth, I realized that one of my dad’s lessons might be helpful to others.

Last time we talked about how a function that can
throw errors is a different type in Swift than a function that cannot throw
errors. And then I briefly mentioned this other thing, “rethrows.” Let’s talk
about that, and along the way explore closure types a little more and their
weird and woolly ways.

So say you are trying out all this interesting new throw stuff in Swift 2. And
say you’re running an early Beta in which many stdlib functions don’t handle
throw closures yet. Or maybe you’re in the future and dealing with some other
piece of code that you wish could handle a throw closure, but doesn’t. What do
you do?

By not using standard FP terminology in emerging languages like Swift, we deny learners access to a lot of existing literature.

I certainly agree. But there’s a lot more to it, and I hope the functional programming community will get involved in new ways. We’ll get there. First, a little history for the rest of us. FP folks, I’ll get back to you in a couple of sections.

For those who read my blog for Cocoa (and recently Swift) discussion, you may be surprised that most of my professional work right now is in Go, C, and C++ (in that order). So I thought I might take a moment to discuss Go.

First, it’s important to say that I really like Go. I didn’t think I would. I’m a language snob at heart. Before Swift, I’d been spending a lot of time on the functional side of the street with a brief dallience with actors. I was just about to do deeper into the parens, when I wound up taking a side trip into Google-land and Go. I’d dipped my toe into the water once before and been turned off by what seemed to be the sloppiness of the language. How variables are declared bugged me (turns out it bugs the lead language designer, too). The multiple return types of range bugged me. Strings switching between code points and bytes bugged me. The fact that Go can’t implement its own append() harkened back to funky Perl magic. Go just seemed sloppy and under-considered.

Our last talk about >>== was full of twists and turns, some
philosophy, surprising connections, and a radical new operator. It was a lot to
absorb, and you may have to play with it some in your own code before you really
know what it’s about. That’s ok.

Let’s take a little break and talk about a handy functional tool built into
Swift stdlib. I promise no big reveals, no new operators, no fancy types; just
hands-on, practical discussion of the Swiss Army knife of transform functions:
reduce.

In which our heroes create for themselves a convenience and discover a
surprising thing.

Last time we looked at the incredible little map function, and saw
how it could be used to simplify a lot of tedious for-loops while making our
code more clear and less error-prone. This time, we’re going to see if we can
solve a common problem that happens with mapping, nesting.

And I tossed a call to map, unexplained, in the middle of the parsing code. I
got a little ahead of myself there. Sorry about that. Cocoa has no map. Maybe
not everyone coming to Swift has a long history with this amazing little
function. In a field where monads get all the press, it’s time to step back and
talk about the humble map.

Yes, this is another of those “how to parse JSON in Swift” blog posts that seem
to be required of every Swift blogger. And yes, several of the techniques we’ll
work through come from the functional programming world. And, yes,
Swift+Functional+JSON is itself a well-worn trail. But still, I hope you find
this exploration helpful. Don’t think of it as functional programming. Think of
it as the path of “I wish there were a function that….”

About Cocoaphony

Rob is a builder of treehouses, hiker, proud father, and from time to time, a Mac and iPhone developer. Cocoaphony is where he pontificates on various issues fascinating to Cocoa developers, and occasionally other topics of technical interest.