This is a bit late, but I’ve been insanely busy in the past few weeks, so I haven’t had change to blog or reflect much. In the beginning of December, I attended (and spoke at) the Functional Swift Conference in New York. It was honestly one of the best conferences I’ve been to in a while, and also the hardest one I’ve had to speak at! I went back home more excited about Swift and my work than ever.
For those of us who don’t have much functional programming experience, transitioning to the functional mindset is going to be a big challenge. But a really fun challenge with a high pay off for those willing to take the leap 🙂 I’m excited and willing to learn, and I hope you are too!
Here are some big takeaways that I think are really important for the iOS and Swift community:
Check out Brandon Williams’s talk if you’d like to see some extreme Functional Programming that will blow your mind. However, in real day-to-day situations – working with a team of other iOS developers, the transition to a functional mind-set has to be a lot less extreme. After all, some people might not even want to learn functional programming – they’re happy with the way they already know how to do things.
This is where Andy Matuschak gave great advice – Exploit Pain. Instead of springing all of functional programming on your team all at once, watch out for ugly code that could be improved with functional programming concepts. Take the time to discuss the merits of the functional approach and get your team members excited and talking about how to solve something better.
Simple vs Easy
Rich Hickey’s Simple Made Easy talk kept coming up again and again throughout the Functional Swift Conference. The idea is that as developers, we have go-to ways of doing things – this is our muscle memory – it’s easy for us to just do what we already know.
But our solution might not be “simple” – the best solution for the problem (especially in Swift). By choosing the “easy” solution every time, we add unnecessary complexity to our code. Here is the result of adding yet another variable to our code (the “easy” way) from Justin’s slides:
I watched Rich Hickey’s original talk, and these “easy” tools that I use in my code every day really stood out to me:
Object vs Value Layer
So at this point you might wonder how you should structure your code if you can’t use the stuff in Rich Hickey’s slide that we use every day. Well, Functional Programming assumes a pure system – one without input / output. But, alas, the real world of our app is anything but pure!
Of course our program will have state and complexity. The key is to use the functional concepts as much as possible to minimize the complexity as much as possible. Check out Justin’s and Andy’s talk for examples on how to structure your Swift code better. Some key tips:
- Use Immutable Values (Structs / Enums) in place of Objects whenever possible
- Isolate unrelated pieces of State
- Objects should only have one reason to change
- Say No to Globals (yes, goodbye Singletons!)
And of course there is more from Rich Hickey’s talk!
By writing more functional code, we can make our code a lot easier to test. For example, in Functional Programming, mocking is not necessary – we don’t have to “set up the world” if we have our code isolated well.
Brian Gesiak, the creator of Swift’s unit-testing framework Quick, also announced Fox – a property-based testing library based on a popular functional testing framework QuickCheck. Fox generates random data to test your code with, and once a failing example is produced, Fox will attempt to find the smallest possible example that also exhibits the same failure.
Hopefully Swift and functional programming will help improve the testing culture in the iOS community!
It’s OK To Learn
This is something I learned while making my own talk. The truth is when I agreed to speak at this conference, I didn’t have much Functional Programming experience besides reading the Functional Swift book and a bunch of blog posts that I only half understood. But I liked the challenge, and I took this as an opportunity to dive in and learn a lot more about Functional Programming.
But what I found was that it’s much harder than I though it out would be! I was spending days and days learning it, and felt like I wasn’t making much progress. Again, this stuff is hard!
So when it came time to prepare my talk, instead of pretending that I’m an expert on this stuff, when I’m clearly not, I decided to be truthful and share what I’ve learned so far, how I’m applying what I’ve learned to my own code, and be honest in that I have a lot more learn. Here is my talk for those interested:
So I give you permission to learn something new 🙂 It’s going to be hard, but it’s ok to say that you’re not an expert at this and be open to learning and asking questions from people who are better than you.
If you have a chance, I recommend taking the time to watch every single video! They’re only 30 minutes each.