|< What is functional programming in Swift?||What are the first steps for functional programming in Swift? >|
Recorded – watch the full episode on YouTube.
If someone's doing OOP now and they think it's great. What kind of advantages would you think they'd get from switching to a more functional approach to programming?
Daniel Steinberg: I want to push back on that, because I'm not advocating that they switch. I'm saying you don't have to give up the way you're doing it. I'm just offering you new tools to add to your tool belt. I'm offering new techniques. The techniques of functional programming don't necessarily replace OO, they can make it more robust for you.
So for example, in SwiftUI, all of a sudden, our views are structs, our views are value types. And for so long, we've wanted our models to be value types. Well, if nothing changes in an app, then the app doesn't do anything. So we do need to violate this no immutability anywhere. And so we have sort of a gooey middle, and it's the middle guy that the controller or the view model or whatever you want to call it, that's where we're doing some of the changing.
“The techniques of functional programming don't necessarily replace OO, they can make it more robust for you.”
I don't know what the analogy would be for sports in England but I think of it in baseball, it's the second baseman relaying, he catches, and he throws it on or in soccer maybe just the one-touch pass. You receive it, you pass it on. That's the middle. The middle doesn't do that much but it translates so that it can speak to both ends. That's MVC. It's not much different than we've done before. So I'm not asking you to give everything up. I'm just asking you to isolate the parts that change in one place so that you aren't surprised.
Paul Hudson: Okay. So they do adopt a slightly more functional approach, yet you say not rip and replace, but bring functional programming techniques and tools into their guesting workspace. Still, the question is there: what kind of advantages would they see from having that functional approach or a more functional approach?
Daniel Steinberg: Again, to me, the biggest thing is, when something goes wrong, I know where to look. When something has gone wrong and someone has set a variable, while the only people that can set that or the only places that it is exposed as a variable is here. If you had good practices back in Objective-C, I say that like no one's doing Objective-C anymore, you wouldn't pass an
NSMutableArray around, you'd give someone an
NSArray, they would make a mutable copy, they would make their changes, and they would offer it back to you. You wouldn't allow them to change your
NSArray inside you.
“SwiftUI is very good at making us be careful and now when we mix that with Combine, oh, my goodness, it's a new world.”
It's formalizing that sort of good behavior. Formalizing a lot of good practices. And the other thing I want to say is, it's not new. I mean, the mathematics behind functional programming goes back 100 years and the programming goes back to the late 1950s, early 1960s. It's new to us, but these ideas have been around a long time.
Paul Hudson: Certainly what I like about SwiftUI is that we still have state, that bits are going to change over time, but it's very, very clearly marked now. You can't change things by accident. It's like, “this bit, this bit I know it's going to change. I want this thing to change. Let me treat that thing specially." That's got a really nice fit for functional coding in Swift, I think because you're now saying, "This bit, this is immutable, this is fixed. This is Pure functions. This bit... Okay, this is the gooey middle," like you said.
Daniel Steinberg: And the nice thing about state is, in general, we mark state private, because I'm the only one that's holding on to this thing that changes. No one else gets to see it. Someone has initiated an action through a button press or entering text and maybe that's changing my state. But the other thing is we can replace that state with say, a class instance. And then use observable and observed to see changes there. SwiftUI is very good at making us be careful and now when we mix that with Combine, oh, my goodness, it's a new world.
Paul Hudson: You've mentioned some advantages that it makes clear state and similar. But are there any disadvantages? Things that people will struggle with or have a hard time with by adopting a more functional approach?
Daniel Steinberg: It feels awkward at first. Instead of sending a message to an object, and it just changes, you send a message to an object or you invoke a function and then you have to receive the change. So if I want to take an integer and increase it by one, I just don't send a message to counter to increase, I send a message to counter to increase and then it returns me a new counter that has been increased.
“Functional programming in general feels a lot like that, that you're wasting things and you've just got to trust that the Swift engineers are optimizing for that and that these bits are cheap.”
It feels more awkward. It feels like, “why are we doing this?” Do you remember when you first came to Swift and arrays were structs and you thought how wasteful? If I add something to an array, I'm throwing out the old array and I'm getting a whole new one. And you thought, a”ll these bits I'm just wasting!” Functional programming in general feels a lot like that, that you're wasting things and you've just got to trust that the Swift engineers are optimizing for that and that these bits are cheap. And if you watch some of the Swift performance talks from Dub Dub, they're doing some very clever things.
Paul Hudson: Certainly Swift 5.2 improved that. They reduced a number of retain/releases happening behind the scenes. So things like copying are just cheaper now, which is great. They've made some real improvements there. But yeah.
Daniel Steinberg: There's an interesting discussion on the last a while back about that, where someone was posting performance test results and saying Swift doesn't seem to perform well. And some people were going on to making excuses that the performance test wasn't really good, but some of the core Swift engineers popped up and said, "Actually, we do have some work to do. And our first job was to get things right. And now we're going to get things more performant." So it's something they know, it's something they're working on. And as you say, even as recently as 5.2, we're seeing some payoff.
This transcript was recorded as part of Swiftly Speaking. You can watch the full original episode on YouTube, or subscribe to the audio version on Apple Podcasts.
SPONSORED In-app subscriptions are a pain to implement, hard to test, and full of edge cases. RevenueCat makes it straightforward and reliable so you can get back to building your app. Oh, and it's free if your app makes less than $10k/mo.
Link copied to your pasteboard.