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?

Manuel Chakravarty made a comment a few weeks ago:

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.

Alex Payne wrote an excellent essay called Thoughts on Five Years of Emerging Languages. It called to mind something I wrote a while ago for a limited audience that I never got around to turning into a public form. Thanks to Manuel Chakravarty for the link and the inspiration.

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.

I had a bit of a throw-away line in Functional Wish Fulfillment:

Kind of like map, but kind of different.

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….”

...and I hated calculus.

Yes, the functional world seems to overflow with bizarre terms that defy intuition. Faced with words like object, property, inherit, class, even non-programmers can get some handle on what they might mean. Applicative functor is not so kind. Nor is the ubiquitous monad, a word that feels designed to obscure its meaning (plus the ensuing arguments over whether something is really a monad or a monoid).

Let me boil functional programming down to its basics, the part you need before we can really get started: variables are evil. Stop mutating them. It just makes them more evil. If I could do just one thing to improve your Swift programs, it would be to generate an electric keyboard shock every time you typed v a r. Yeah, you’ll need it sometimes, but each time you should ask “is it worth the shock?” And by “the shock,” I mean “hard to find bugs.”¹

In response to I Don’t Know Swift:

Is this career advice? I am a web developer thinking about a “career change” to iOS. Since I have no background in CocoaTouch or anything Apple, would your advice be the same, to learn Swift?

I’ve received different versions of this question since the day after Swift was released, from ObjC lovers and haters, seasoned pros and the uninitiated. Having had a very unusual (and privileged) career path, I’m probably not qualified to give career advice, but I’ve been asked enough that maybe it’s worth talking about. Maybe I can frame how to think about it, even if I can’t give you satisfying certainty. Maybe that’s all advice really is.