In this episode of The Rabbit Hole we welcome our friend Jacob O’Donnell to help us talk about the decline of object oriented programming. We chat about how the pendulum is swinging towards a more functional based approach and also delineate between this and procedural code. We discuss how objects are often on the receiving end of coder’s frustrations and how this is one of the reasons for their unpopularity. We also get into pros and cons and the panel’s own feelings around this situation and what it means to potentially learn new methods. At the end of the episode we weigh just how dead the object actually is and think about whether it might return to its former status in popularity. For this and much more, come with us down The Rabbit Hole!
Key Points From This Episode:
- The tech pendulum and why Jacob thinks we see objects declining currently.
- Objects as a scape goat for frustrations with coding.
- A few prominent object based resources.
- What are bad objects? What are bad functions?
- React and the benefits of writing functional oriented code.
- Pros and cons and feelings on the death of object.
- Distinguishing between functional programming and procedural code.
- How far will the pendulum swing away from object oriented programming?
- And much more!
Transcript for Episode 92. The Death of the Object with Jacob O'Donnell
[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast in fantabulous Chelsea, Manhattan. I’m your host, Michael Nunez. Our co-host today.
[0:00:09.8] DA: Dave Anderson.
[0:00:10.8] MN: Our producer.
[0:00:12.0] WJ: William Jeffries.
[0:00:11.5] MN: Today, we’re talking about the death of the object.
[0:00:17.4] DA: You killed him.
[0:00:18.0] MN: Yeah, it’s gone, done for good. A lot of coding paradigms and now following more functional approaches I’m going to say rather than using objects and today, we’re going to talk about the death of the object.
Before we begin, we have a reoccurring special guest in the building. Jacob O’Donnell. What’s up Jacob?
[0:00:39.9] JOD: Nothing. That’s me, I’m Jacob, let’s see, I’ll introduce myself. God, how old am I? I’m 30 something.
[0:00:48.3] DA: Just a Brooklynite, 30 something.
[0:00:50.0] JOD: Yeah, I live in Brooklyn. My gosh, what else is interesting about me?
[0:00:54.5] MN: How long have you been killing objects? I guess is the question.
[0:00:56.9] JOD: God, I’ve been slinging objects forever. I mean, I was 13 and programming some C++ and learning Direct X and objects and I was like, these C++ objects, they’re the future.
[0:01:10.6] MN: Welcome to 2018, baby Jacob becomes big Jacob and we find that the object is now being killed all across the world.
[0:01:19.0] JOD: That’s right, yeah, what I want to talk about today is that I’m seeing – I’m a consultant and I’ve been to a lot of places and I’m seeing more and more - I would say earlier in my career, especially in the languages I worked in, a lot of like Ruby and stuff, objects were very embraced, everybody was using objects, everywhere you go, there’s objects and they weren’t always used right, in fact, I would say they often weren’t.
But nowadays, more and more, I’m seeing less objects out in the wild, I’m seeing more like in React, React has kind of moving away from objects towards stateless functional components. I’m seeing on the back end, a lot of Python code bases, just sort of a function as a handler calling out to a bunch more functions and less and less, I’m seeing objects which makes me sad.
[0:02:04.7] MN: Why do you think that’s the case? I guess, let’s just go right into the why?
[0:02:08.6] JOD: Yeah, why, well, I do have a theory and I sort of think it’s the tech pendulum. I think those idea out there that the pendulum swings one way or the other and people sort of are frustrated, their programming is hard, they’re like, “Why is this hard?” It’s a thing to blame, it’s like okay, well –
[0:02:26.6] DA: Well, it’s definitely not me, it’s the objects.
[0:02:30.7] JOD: Yeah.
[0:02:31.2] DA: They’re holding me back.
[0:02:32.9] JOD: Everything should be easier.
[0:02:35.2] DA: You know what’s easier than an object? A function.
[0:02:37.7] JOD: A function. That is true. A function is easier.
[0:02:41.9] DA: There you have it people, the objects are dead.
[0:02:44.1] JOD: Yeah, just killed it, right?
[0:02:45.6] MN: You put the nail on the coffin, that was it. How do you feel about that?
[0:02:49.8] JOD: Well, it does make me a little sad, I mean, I’ve invested a lot of time into learning about object orientation and honestly, the more years go on, the more I’m starting to be like, I think I get it, you know? Even like 10, 12 years in, I’m starting to be like, I think that I was doing it wrong before and that there are better ways.
[0:03:11.6] WJ: Do you ever get to the point where you stop feeling like you were doing it wrong before?
[0:03:16.0] JOD: Great question, probably not.
[0:03:19.9] DA: I feel like every six months. If I have to go back to something I wrote six months ago then okay, I definitely could have done this a lot better. Especially if you're like learning something new or new domain, new technologies, what have you.
[0:03:34.2] JOD: That is fair but I do think that there are at least general sort of rules about object orientation that you can learn. I think one thing, one sort of rule that comes up is –
[0:03:42.9] WJ: Dependency injection.
[0:03:44.5] JOD: Dependency injection and prefer composition over inheritance, right? You often don’t want these deep inheritance trees, you don’t want them, you certainly don’t want them deep, if they’re like wildly shallow. I think if they have hundred subclasses, maybe that’s not the right answer either.
I do know a lot of junior object orientations will create these really mangled inheritance trees and they will have multiple inheritance or if it’s Ruby, they’ll mix in 30 modules and they’ll be like, “I’m doing it. I’m object orienting.” Which, like, it’s really like - that’s not what good code looks like.
[0:04:27.1] DA: That’s like the classic example though in the book. You know, you have your creature class and then that turns into an animal and the animal turns into a human. The human turns into a baby. It’s just like, it just keeps on going.
[0:04:43.3] JOD: That’s true and that actually, you know, maybe that has something to do with it that the learning material sort of pushes us. A decent rule of thumb I’ve learned is you just sort of say, is this a thing. If it doesn’t really match, then avoid it and use composition.
You know, even with all that said, I don’t think that’s the only problem with what’s going on with objects.
[0:05:08.8] WJ: Babies aren’t human.
[0:05:10.9] DA: That’s a good point.
[0:05:12.9] MN: They’re small humans.
[0:05:13.9] WJ: Some of them are like baby birds and stuff.
[0:05:15.8] MN: I guess they do have very different abilities. A baby human is a baby human, is a human. I mean, I imagine that there are like reading materials that talks about object oriented programming, that being a thing. I know POODR is a really popular Ruby book that kind of teaches that.
Do you think that people just aren’t absorbing the knowledge that is of Sandi Metz in places where you know, you have to deliver this piece of code or this feature in a deadline that’s almost not realistic but you have to do it really fast so that it kind of muddles the object orienteers of the application?
[0:05:52.7] JOD: I mean, that’s a good question. Every time I read POODR, I get something more out of it, I’m like yeah, I still – my stuff still doesn’t really look like this.
[0:06:02.3] DA: That’s fascinating because there are lot of like really simple concepts in the book. It’s like so accessible.
[0:06:06.8] WJ: All of my code looks exactly like POODR. Exclusively program about bikes.
[0:06:14.9] MN: You had a bike client? Is that what it is?
[0:06:18.4] WJ: I think that’s the main thing that she’s trying to teach you is only program about bikes.
[0:06:21.8] MN: Very cool.
[0:06:23.7] WJ: That’s the lesson that I took away.
[0:06:25.3] MN: It could be my small business for sure.
[0:06:26.5] JOD: Yeah, I mean, I wonder. When this pendulum swings, assuming that I’m right about that, maybe object orienting programming is harder to grasp than functional, right? I mean, it’s got these benefits of you storing your data and your methods together. The data can operate on there.
I don’t know if things move to just sort of like lots of functions operating on data and just goodbye objects. What the price to pay there will be, maybe everyone will just be like, “This is better.”
[0:07:00.5] DA: I guess the opposite end of that, a bad object is like a really big object, right? You have like an object with too many responsibilities and knows too much data, there’s like a side effects all over the place, you can’t figure out what’s going on. You finally like, “Okay, get me out of here, I don’t want any of this side effects.” I want like immutable data and you know, functions that are pauper and yeah, that’s my promised land but then like, you could still just end up with like a module that has like – you know, 300 lines of functions in it.
[0:07:32.9] JOD: Yeah.
[0:07:34.0] DA: Easier to, like, trace through.
[0:07:35.9] JOD: I mean, that is sort of my field, bad code is bad code, what you just described there, even if you’re not the most accomplished object oriented programmer, you should still probably see that coming and be like, there’s problems here, this is too large, it’s too confusing, it creates a lot of bugs and work to refactor that probably by splitting it which is probably like the same process that’s going to happen with like a function, you know? Your function’s going to grow to 200 lines. It’s got state because you’ve got like these local variables floating it out.
[0:08:06.9] MN: React is now popular framework than a lot of people use and you often find that React tends to be more functional. What are the benefits of writing functional programming syntax or style versus object oriented programming?
[0:08:24.3] JOD: Yeah, that’s actually a funny one because in a sense, I think what React is moving to is still the same thing at its core, right? It’s a file and it’s going to have states still but it’s just sort of expressed in a different way.
[0:08:40.7] DA: Yeah, it does feel a little bit arbitrary. Instead of having a class component that has state and life cycle hooks, you’re going to apply hooks to it, you’re going to use memo instead of like you know, component should update. Why? Is it really like, is that really the future?
[0:09:10.7] MN: You mean this like the object ‘this’.
[0:09:14.2] JOD: Yeah.
[0:09:14.6] DA: The context of what you’re running in right now.
[0:09:18.0] JOD: Right where the arrow function helps with that but still you can run into that and as a beginner I could see that just would be very confusing.
[0:09:29.0] MN: Python and Ruby.
[0:09:29.8] JOD: Wait what do you mean self, I don’t think it exists.
[0:09:31.8] WJ: It does.
[0:09:32.6] MN: No way.
[0:09:33.2] WJ: Yeah, it is a terrible idea. I don’t know why you would have both of those things. I discovered this and I was like, “Oh this is so gross.”
[0:09:40.4] MN: What? What is self?
[0:09:42.9] WJ: It’s kind of like this but different and not in useful ways, as I recall. I read the description I was immediately closing this tab, never coming back.
[0:09:52.7] MN: Never using it again.
[0:09:55.0] JOD: I have never heard about that.
[0:10:07.4] MN: What?
[0:10:08.3] JOD: Wait, I have missed that.
[0:10:09.7] MN: Just don’t use self, ladies and gentleman. That’s a thing you don’t want to use and I guess as you mentioned this, when I say I want the listeners to know it is not like I am pointing at something like, “This is horrible,” but this context it could be confusing in general for newcomers who want to build an application in React Native or something.
[0:10:31.6] JOD: Yeah as far as like functional goes, I can’t say a ton. I have experimented a little. I don’t consider myself functional expert at all. So I don’t really – they say there’s a lot of benefits. You have to talk to your stupid brother.
[0:10:47.7] MN: Steve, yes with the Elixir. You can’t have the Elixir well fetched or – yeah, we’ll have him on sometime to explain.
[0:10:56.3] WJ: Steve Nunez.
[0:10:59.3] DA: Steve Nunez explains functional programming.
[0:11:01.6] MN: But we also had an episode I believe on – that we have been – that is not the case then we should have one, functional programming, that’s a thing.
[0:11:08.7] DA: Yeah there was an episode with that actually.
[0:11:11.0] JOD: I mean what do you guys think? If objects are in decline, are you saddened at all or do you sort of shrug your shoulders?
[0:11:20.4] WJ: I am saddened by that. I think that - I mean on the one hand, I think it’s nice because it forces me to learn new stuff. So I think increasingly I am being pushed in a more functional direction and then I think that is a good thing.
But at the same time, it doesn’t seem like the functional programming world has a good answer for the core of the value that they’re losing by abandoning the object and to me that core piece of value is that there is a ton of win that comes with having the functionality right there next to the data that it is supposed to be used with.
When you have a centralized data store then it becomes much more muddy knowing which functions are supposed to be used with which data when you can create a metaphor for everything that exists in your world and group the data and the functionality for that metaphor together, then all of a sudden we can have a conversation and it is just to the same conversation we would have if we were talking with the regular domain language for whatever product we’re building.
[0:12:26.8] DA: Yeah, I think that right there - I like the metaphor or the domain modeling like where you can have these concepts that are real in the real world be there like physical things like ideas and really talk about them even to agree with non-technical people and to share a language about it.
I think that will be a little bit harder when you only have PC or your verbs are still there. They’re still your functions you still have nouns but they are now just types that you pass into the functions and if you don’t have types then I feel like you are really missing something with functional programming.
[0:13:04.7] MN: I am okay moving with the swing of the pendulum. Functional programming is a thing that’s happening and it is the preferred language of choice with the client that I am in that I am going to continue doing that. I won’t be writing object oriented programming in React because then that’s just not following the convention and no one would approve my poll request. That is just what’s going to happen.
[0:13:28.2] DA: But you can fight the world.
[0:13:29.8] MN: Yeah, I mean you could but then - I don’t know if that’s the fight I want to be in and I think what William mentioned before is great is that it allows me to learn different paradigms that I may not have had the opportunity if I just continued to write object oriented programming.
[0:13:47.1] WJ: And there are good ideas that came out of the functional programming world, right? I mean the notion that functions are best when you can put the same thing in and always get the same thing out is really valuable concept even in object oriented programming. It makes your unit testing way easier.
[0:14:04.9] DA: Yeah, I do like the idea of having an immutable object like something that – when you change it, it doesn’t change that reference. You can get back into your reference. I like that idea and I think that really made more sense to me after working with functional programming and things like Redux where there’s only one rule. All functions are pure.
[0:14:31.9] JOD: One distinction I want to draw is while functional languages are gaining a lot of traction, what I am actually seeing a lot more now is procedural code where they’re function based like C but there is state. Versus I think Elixir or something where you are not really supposed to store things temporarily in variables and manipulate them like it’s – and then you can sort of get around that unlike [inaudible] where it’s like purely functional and there’s absolutely no state.
I’d be interested in trying a functional language just to see what the hub bub-bub is about.
[0:15:13.0] DA: My colleague just went to a [inaudible] Conf last week and they’re on North Carolina. So what’s interesting is there is a lot of academics and thinkers who are like working in this space and I think maybe there is something to the fact that’s a pendulum and maybe they’re just bored like they have been writing object oriented code but like they’re working on interesting problems that still apply to things that we care about in object land too.
[0:15:39.4] WJ: So when do you think the pendulum is going to swing the other way and we’re going to be talking about the death of the function?
[0:15:44.9] DA: The birth of the object.
[0:15:46.8] MN: Yeah the birth of the object. Oh I can’t wait.
[0:15:48.1] WJ: Baby objects.
[0:15:49.3] JOD: I don’t actually think while I feel like the pendulum is starting to swing back.
[0:15:54.1] WJ: Ooh baby doesn’t hear it from object.
[0:15:56.6] JOD: But baby woo?
[0:15:57.8] WJ: Baby doesn’t hear it from object.
[0:16:00.3] JOD: Oh.
[0:16:02.6] MN: There you go.
[0:16:03.7] JOD: Baby inherits from Bobby.
[0:16:08.2] MN: Exactly.
[0:16:08.8] DA: Spoilers.
[0:16:10.7] JOD: Well I mean I think that the pendulum while it is sort of swinging back I don’t actually think it is going to swing all the way. Object oriented in programming has too much of a foothold. I don’t think really like something other than like a pretty Object oriented languages had a strong foot hold since the 60s when it was Lisp and since it was born.
I am not sure when it was born. It was probably born in the 70s or 80s. I don’t know if there’s going to be a new paradigm but right now I don’t actually think it’s going to – I think it is in the recession but you know, Trump will take us right to the future. I am aware about that like all things lead to Trump.
[0:16:54.6] DA: Yeah and even if you think about it, you are talking about how at the web servers, you can write an end point in a functional way where it’s a function that responds to your URL and that function calls other functions. But you might be writing it in Python. You might be writing it for Flask and everything even a function in Python is an object.
[0:17:16.7] JOD: Is that true? I thought that was Ruby.
[0:17:18.8] DA: Everything has an object in Python.
[0:17:21.4] MN: Yeah, I know in Ruby that’s the case too.
[0:17:23.3] JOD: Yeah, I think about Ruby. I didn’t know about Python.
[0:17:25.5] DA: Yeah and that’s true in a lot of languages. Yeah you can’t escape from it.
[0:17:32.4] MN: You can’t escape from it.
[0:17:33.3] JOD: Let’s just erase this podcast.
[0:17:34.5] MN: You know there are other language that dominate like the industry like Java and C++ and they all use object oriented programming. So I don’t think those programming languages are going anywhere.
And I think it is almost writing functionally for Java is like very, very difficult. You are going down a really bad path if you don’t follow like specific object oriented paradigms. So I don’t think that those languages would ever change to the function around.
But I guess the popularity of functional programming would continue to go up and that may cause object oriented programming to go down but we’re not sure. The pendulum is swinging back maybe or maybe not. We don’t know where’s the pendulum, I can’t see it.
I’m glad to see the expert in the death of the object, Jacob, to come on down. Thank you so much for dropping by.
[0:18:24.0] JOD: You’re welcome, thank you.
[END OF EPISODE]
[0:18:26.2] MN: Follow us now on Twitter @radiofreerabbit so we can keep the conversation going. Like what you hear? Give us a five star review and help developers just like you find their way into The Rabbit Hole and never miss an episode, subscribe now however you listen to your favorite podcast. On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Dave Anderson and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.
Links and Resources: