Poor Man’s Functional Programming

It’s a very exciting time to be an iOS or Mac developer. The platform moves very fast and we got a new toy (language) to play with: Swift. It’s the perfect time to reevaluate, learn and evolve as a programmer, because you will be forced to adopt this new language (yes, I think Swift is the future, 100%).

I want to relate this to the fact that most iOS engineers, or mobile application developers, are traditionally familiar with Object Oriented Programming paradigm. But Swift offers more than different syntax and OOP.

I’m referring to some features inspired by functional languages. If you’ve ever had an interest, but never the chance or motivation to go forth and look into this paradigm, now it’s the perfect time to do it.

Functional programming is…

I don’t want to start reviewing what functional programming is, there are excellent resources out there, check them out.

I want to point out how a beginner, somebody who starts learning Functional Programming (FP), might feel:

  • Too abstract
  • Not applicable to my problems
  • For academics
  • What does even ‘pure’ mean?
  • I need to mutate stuff!
  • Meh, I’ll go back to my familiar way of doing things

There’s a higher barrier of entry to learn how to think and code programs which are more ‘functional’. The concepts are abstract, and the benefits are often described as it’s more functional without emphasis of what you are actually gaining. Also there’s the problem that many times all is explained by simple examples. But every programmer knows there’s a huge difference between toy programs and real big projects.

Flame wars

You’ll find engineers and computer scientists that believe that the only and true way of doing things is of course thinking functionally, and we’ve all been doing it wrong during the last decades. The math is the only source of truth and validity, hence FP is the only way.

They’ve got their very valid reasons to think this way, but my opinion is that many people familiar with FP start to use higher-level vocabulary, and describe conventions and problems in a way that might seem foreign and strange for somebody who is not used to those terms. Rob Napier has an excellent article describing this.

Computer science, and programming in particular, is a curious field where people take sides around things that may seem totally absurd for an outsider: Vim vs Emacs, Windows vs Mac, Linux vs everything else, Ruby vs Python, OOP vs FP.

Do we really need to fight over who is right, instead of using the tools that are most appropriate to do our job? I’m totally on the side of moving on and being pragmatic about learning, and eventually as growing as a software engineer. By looking at different ways of solving a problem you can only get better at what you do, not worse, because you will have the ability to make an informed choice.

I’d love to see the people who are experts or versed in FP to reach out and share knowledge in a way that can be understood by beginners. If we really want people to be aware of the benefits of using a different paradigm, we should make it approachable to start with.

Poor man’s functional programming

I would like to think that for most engineers, the choice of paradigm on our day to day work is not a clear one. Thus we will have direct benefit from a language that lets you choose. Using such a language we will be able to write code in an OOP or FP way where it benefits the most. And it seems I’m not the first to think about this.

Coming back to Swift, this is precisely what you can do with it. You can choose programming styles depending on what your problem is, the framework you work with, and even the team you work on.

This flexibility does comes with a price though: The functional features of the language are not as rich as other, purer languages. This is the point of my essay: With Swift, and given the normal users of the language (myself included), we will be able to do Poor man’s functional programming. A style that tries to mix the best of both paradigms.

We’ll make mistakes as we learn, but hey that’s part of our job. Do you like code you wrote 6 months ago? I know I don’t.

Moving on

I like to be pragmatic rather than zealous. And I think Swift brings an excellent opportunity to learn more about other ways of thinking about building software, different abstractions, and how to fit those into our day to day work as iOS developers.

Swift, as other modern languages, offers a unique opportunity to learn and grow. It’s a very exciting field we work on.

Aside: Sources to check the ‘tension’ between OOP and FP:

And the list goes on and on…