Mark Seemann, who joins to talk about SOLID principles, is a self-employed programmer and software architect, book author, PluralSight author, public conference speaker, Humane Code Video author in Cleancoders.com.
Sponsor
This episode is sponsored by Copado.
Copado is the first Salesforce Delivery Management solution and the #1 native DevOps platform for Salesforce.
Copado DevOps 360 is the first Salesforce Delivery Management application, enabling you to measure the performance of your Salesforce implementation.
Main points
- What coding problems does SOLID solve?
- Single Responsibility Principle (SRP)
- Open-Closed Principle (OCP)
- Liskov Substitution Principle (LSP)
- Interface Segregation Principle (ISP)
- Dependency Inversion Principle (DIP)
Links
- Mark’s Twitter
- Mark’s SOLID course (PluralSight)
- Mark’s PluralSight courses
- Mark’s personal blog
- Mark’s Humane Code Videos
- Book – Dependency Injection Principles, Practices, and Patterns
Video Teaser
Contact Me
If you enjoy this podcast, please reach me out to let me know your thoughts or simply say Hello. My (Xi’s) contact info:
Take care, until next time :)!
Transcript
AI-generated, unedited.
[00:00] This episode sponsored by Capado. Capado is the first Salesforce delivery management solution and the number one native DevOps platform for Salesforce. Capado makes the jobs of Salesforce admins and developers fun and easy, even in the largest, most complex works. Plan and collaborate on work, then track your changes right on the user story with the admin-friendly Git interface. Automate development and testing, and track metrics so that you can target improvements. Capato DevOps 360 brings advanced analytics such as value stream mapping, executive summaries, and rich interactive dashboards. These insights help you find inefficiencies and delight your users by delivering innovation faster than ever. Take the pain out of the Salesforce development process and make Salesforce development fun again with Capado.
[01:11] Hello, everybody. This is Xi Xiao. This is yet a new episode of Salesforce Way podcast. Today, I'm sitting with a wonderful guest with me. His name is Mark Seemann. Hello, Mark. Hello. Good to be here. Yeah, Mark. So, would you like to introduce yourself? Oh gee, I could I can try. So my name is Mark, and I'm I live in Copenhagen, Denmark, which is where I'm calling in from right now, and I've been I've been doing software development for. Gee, twenty, twenty-five years, something like that. I actually started out. I have a university degree in in economics, so I was not really, you know, wasn't really in. In my plans to become a software developer, and then I sort of just stumble on software development in the in the mid 1990s, and then thought, hey, this is much more fun. So I basically just started doing that instead. So it's it was sort of like a gradual shift. From I I actually started out working in the Danish Ministry of Economic Affairs. So I um I used my education a little bit, and then I sort of transitioned into software development from there. So exactly how many years of software development experience I have is it's a little bit fuzzy around the edges because it's sort of gradually transitioned into that. But it's more, it's definitely more than than than twenty years. I got my first, you know. You know, job where it said software developer as the title in 1999. So it's been it's been a while. But I did I did software related things even before then. Yeah.
[02:41] So it's been it's been some time. Yeah, so so Mark, I ran into your Pluralsight courses. It's about the solid principle, right? You teach people how to write a object-oriented programming language. That's right. Design those stuff, and you got almost the two thousand ratings with the average of four point five out of five. That's like amazing, you know. I just wondered how much money does this guy get from this one single course. I'm I'm not sure that I'm allowed to speak about that actually. Yeah, it's fine. But you know, that's the first thing, first impression. I get convinced. Okay, let's really check what's the the course content. And the solidity was something I really wanted to learn, but it's obviously in the book. You know, I I know what it's about, but how do I really use them? And how important is it, especially in the real life when we are busy? You know, we're writing the code for the customers, for most of the Salesforce developers. Right. So that's the reason I want you to you know to come into my show and then have a conversation about it. So, so solid. I understand it's like a five separate principles that combined with the first letter S O L I D, right? That's true. But it sounded very like academic things. It's like only the professors in the university wanted to study that, right?
[04:11] Okay, fair enough. Okay, so I think I think the first thing we need to be sure that everyone understands is that I completely get the the point where if if it feels like you're very busy, you may not feel that you have the time to dive into what you you know what you say. You know, it sounds like it's more like an academic thing, but it's it's not really intended to be. Particularly academic, and and and it didn't actually grow out of universities. It's it's quite a practical set of of principles that that you know originally Robert C Martin tried to. To put into some rules of thumbs, but I think what's what's really important here is that you you probably. You tend to have more than one goal when you are software developer because obviously you have this short term goal that if someone, if your customer is asking you when when is the next feature done, when is the next feature done,
[05:27] But on the other hand, if you know that you have to work on the same code base for years and years and years, you may also have experienced this phenomenon where you know when the when the code base is young, you can deliver new features fairly quickly. But then, as the code base grows older and older, it becomes harder and harder to add new features because every time you try to add a feature, every time you try to fix a bug. Something else breaks somewhere else in the codebase because everything's sort of connected to everything else. So, you know, that's why we call it spaghetti code—is because if you try to, you know, pull at one, you know, place, it it affects something completely different in in in the codebase. Is that one type of technical debt? So, it might definitely be, you know, a type of technical debt. So, so we. You know, a good textbook or a good you know course about the solid principles should always start by saying what I'm about to say now is that you know you should only use those principles if you actually have the problem that they address, because you know it it you know the solid principles aren't. Sort of like a fix-it-all, you know, set of of rules. It they they're there to fix particular problems, particularly around you know maintainability of you know code bases that tend to live. For a little bit of of a longer time, then what kind of problems does it really solve? If we just want immediate gain attraction of people,
[06:57] right? Yeah. So I think I think one of the problems that it solves is exactly this this. Problem of diminishing returns, where it gets harder and harder to add new features. So, if you follow those, you know, they're also known as the principles of object-oriented design. So, if you follow those principles, if you do it right, it should become easier to add new features later on. So, with you know, without breaking the features that are already there. With all sorts of caveats and and sort of where you say, well, okay, it doesn't, you know, it's not a solve all fix, but it it might just make it easier to maintain your code base in the middle to long run. But what you just mentioned—it sounds like when your code is rigid, which means it's really hard to move around. When when the customer has new requirements, which usually is the case, right? Along the project, the customer changes ideas, and you tell them back that sorry, I can't change that because of this or that. Which is the sign your code is already. Rigid, yes, yes, and it could be something else. Like you just already mentioned, when you change something here, then something else breaks. It's like your code is really fragile, right? Yeah, so it's really hard to touch it. And maybe also because in the code there's this so-called complexity, right? If you have a lot of ifels and nested things, it's really hard to understand. So those things are also maybe
[08:28] part of these things. The Started principle training. Yes, right. Yeah. So I probably spoke at a little bit of of a too high of a level of abstraction. But but as you just mentioned, one of the one of the symptoms you see is that you know a lot of of you know long methods that may run on for hundreds of lines of code and with lots of nested if statements where you have if and a for loop inside of the if statement and another if statement inside of the for loop and then another for loop and so on. You you've probably seen those. Everyone is we've all seen that sort of code. And what often happens in that sort of code is that there are lots of different responsibilities that are sort of you know mixed in together with each other. So you may have some responsibilities where part of that code goes and looks something up in a data store somewhere, and then another part of that code puts you know you know renders something on the screen. Or perform some sort of business calculation, and and it's all sort of mixed in together, which makes it really hard to figure out if you need to change one of those things. You sort of need to figure out, you know, which parts of the code. Do I actually have to change that? Okay, so Mark, let's start with the single responsibility principle because it's the S, right? Yes. So you know, if we pull everything into one conversation here, then people get confused. Let's just start one by one. I understand. Point is that the five principles in. Solid. You have to learn them
[09:58] and apply them all together in your daily life. Then you get the most benefit out of that. Right. But for the learning purpose, it's better. Maybe we go through one by one. So let's start with the first S, which is a single responsibility principle. When I need to change something, I only need to go to one class. So one class is only responsible for one thing, which is a unique. Principle, right? In the Unix, yeah, that's that fits pretty well with the you know do one thing and do it well principle. Yes, okay. Because in Salesforce, we are familiar with one things called separation concerns, which was mentioned by Martin Fowler at the beginning. So we know in Salesforce we always separate as like a service layer, domain layer, select layer, and then we kind of in each layer we have multiple small classes responsible for certain responsibility. So for this so called single responsibility principle, we are kind of familiar and we really use these separation concerns to drive our design or code. Sounds good, but one one thing I really hear is that if we do this, then we end up with many small files in our even a small solution. Yeah, comparing to before, we just put everything into couple of classes. Then, is it better with the small files? Right, right, yeah. So, so this is a question
[11:28] I actually do get from time to time, and I completely understand where this is coming from.
[11:36] Often, when you're trying to get an idea about you know how is a codebase organized, lots of people start to look at the file you know the list of files, and then if you see, as you just suggested here, if you see hundreds of files in a list, that that looks like it's really overwhelming.
[11:55] And, but I think it's a little bit of a mental hurdle you just have to get over. You know, if you have this all of that spaghetti code that we talked about before, you might have files where, if when you open it, it's ten thousand lines of code, but you only have like ten of those files. And then people say, "Oh, that's a nice code base. There is only ten files, even though you have you know one hundred thousand lines of code there." But if you have two hundred files of code, even though each of them is just like. Twenty lines of code, then people say, "Oh my God, there's so many files." Yeah, but each file is really, really small, and you know, ideally, each little you know code file is fairly self-contained. So if you're looking at that particular code file, Ideally, you shouldn't have to be able to keep in your head all the rest of the hundreds of files. So, so that's one of the ideas with the single responsibility principle is that we keep things small. And there will be a lot of files. There will be a lot of classes, and it it looks scary, but it's it's really much easier to understand once once you sort of get over that problem. So even if let's say the smaller files versus the large file solution, even if the line number is the same, but the smaller files is more scary for people. Yeah, that's my experience. Yeah, yeah. But if you really apply that, at least based on my experience, when I split the files into the smaller ones and give them good namings,
[13:25] especially for example, if it's the select layer, I have a certain. Suffix so that my IDE would automatically when I search with that suffix, then all these small files just listed it down for me, and I know from the naming exactly what that file is for. So I don't need to go through everything. I don't need to scroll up and down, right? Yeah. So the search already helped me a lot. Yeah, yeah. I so I we haven't really talked about. I'm not a Salesforce developer. I usually I do most of my. Software development, but at least the thing that things that people pay me to is C sharp development, and there's we have this environment called Visual Studio, and it has a lot of navigation you know features built into it. So if I'm looking at you know a code listing and. And I wonder, you know, what is another class doing? There's a button, you know, it's just a keyboard shortcut I can press to, and then it just takes me to that file. So I don't even have to find the file in the file navigator. I can just sort of, you know, navigate around the system. So I suppose you have something that similar to that, where you're using Visual Studio Code. So which is oh, you do? Okay, yeah, yeah, Visual Studio Code does a lot of those things as well. True, cool. I think the the first one S is more or less easier for us to understand because it's a concrete class and it's really simple to to digest. The second one is O, which is open close principle. Yes, right. What does that mean? Yeah, so that that means that the class should
[14:55] be open for extensibility but closed for modification. So, so originally it was it was defined in terms of you know object oriented inheritance hierarchy. So, so the idea here was that you could have a base class. And if you did things right, then you shouldn't ever have to, you know, go back and change the code of the base class. Well, if you find a bug in it. Fine, you can go and fix the bug, but otherwise, if ideally you could design the base class in such a way that if you needed to change some of its behaviors, there were enough hooks into it so that you can you know create a class that inherited from the base class and then it overrides you know one or two virtual methods and then could you know you could change the behavior that way. And you know if when you have you know inheritance, which I believe you have in Apex as well, yeah, you can still do that. That's that's fine. Another another approach to do this is to use the strategy pattern, where you basically just you know instead of creating you know an inheritance hierarchy, you can basically use dependency injection and say, well, there's an interface that you inject into the. You know what was before the base class, and then it calls you know methods on that you know interface, and then you can always exchange one implementation of the interface with another one. But the basic idea with the open close principle is to say, well, okay, so once the
[16:26] base functionality is Has been developed. You shouldn't really have to go back and revisit that code because you you should be able to change further on behaviors by adding new classes that sort of you know extend on the things that need to to change. And I and I often find that quite useful in you know something like a business context because what often happens is you hinted at this already that business rules change. So you often get this requirement from. The rest of the business that they want you to you know implement that change of the business rule, but I've I've often found myself in a situation where it's a good idea to keep the. Old business rules around still. So instead of going in and you know editing the business rules so that you only have the new one, you can sort of, if if at all possible, then you know leave the old business rules still in the code, but then have you know something that sits side by side. For example, maybe by extending, you know, a previous class, and changing enough of the way that things are done, so that you now have the new business rule. But you know, you often run into these things where sooner or later someone will come and ask you to run some calculations based on the old business rule. And it's really nice to be able to say, yeah, okay, I can do that. That class, you know, is still around. So I'm just, I'm just going to use this, you know. Class
[17:56] over there, which represents the old business rule, and then I can you know tell you, okay, this was you know this would be the result that we would have you know arrived at with the old business rule, and here's the result we can arrive with the new business rule. You know, it doesn't come up a lot, but it happens, and it's it's just pretty nice to have those all the things around. It sounds a bit like you have a version control system in editing your code. Yes, yes. Yeah. Well, okay. So I'm not saying you should keep all old code around. It. It's not. I don't mean that, but. But sometimes it might. Yeah, I get. I get the point. It's. It. I just try to, you know, visualize it so people can really understand. Fair enough. So when you have the base class, which is like a core of your originally design, which is more kind of like abstracted, essential, and then the new things kind of grow on top of that, kind of extended, override it. Yeah. Yeah, that's the idea anyway. Yeah. Okay, so the solid principle, the third one, is called the Liskov substitution principle. It's really a mouthful one, and it's a it's a term that I can throw around in the office, and people would think I am smart. So, what is Liskov substitution? So, so this is really this is probably the the most abstract and the most academic one.
[19:17] It's and it's difficult to explain in a way that doesn't sound abstract. But once you sort of get it, it took me many years to actually understand really what it says. But once you get it, it's really you just say. Ah, yeah, that makes sense. I mean, it's really intuitively, you know, easy to grasp once you get it. But in order to do that, we should probably let's see if we can do do this short. Well, we need to talk a little bit about encapsulation. So the way that I understand encapsulation. I take a lot of my knowledge about encapsulation from Bertrand Meyer, who he wrote. He developed this programming language called Eiffel back in the in the eighties, and and he wrote a book about that. And and he had this notion about invariance, and basically. What we what we talk about when what we talk about invariants and invariant is you know some sort of description you know an abstract description of an object where you say whatever the state of the object these things will always be true.
[20:26] So let's say if you just have a simple entity like you know you have a you know a a person you know a you a car oh we could we could take a car so so the car will probably have you know a. They will probably have a color. They will have a model. It will have a you know manufacturer. It might have a vintage. You know a year it was manufactured. You know things like that. So you could have a class that you know that represents all of those things, and then you can say, well, one of the invariants, even of a simple, this is basically just like a you know a. A class that just holds some data, but we could invent some invariants where we can say, well, but the the name of the manufacturer is guaranteed to be there. You know, that could be an invariant where you say, okay, so manufacturer. It might be, you know, this could be a Toyota, it could be a Ford, it could be a Mazda. You know, whatever it is, but we guarantee that there's going to be exactly one manufacturer. We we could and that's an invariant. So you say, well, you can change the manufacturer if you decide that oh, it wasn't actually a Ford; it was a Toyota. You could go and change that manufacturer property of the object, but you're not allowed to set it to null. You know that's that's a that's just an example of an invariant. So because that property always exists, no matter what the invariant it is, you are guaranteed you can get the value. An invariant is a guarantee. That's another way to put it. So you say, well, invariant. This is is the guarantee to say, well,
[21:57] this is always going to be true. There will be a manufacturer, or you could say if you make the the year of the model. You would probably say something like, "Well, that's going to be a number, and we guarantee that it's going to be a positive number because you know cars weren't manufactured in you know before you know our current era, so it's probably going to be a positive number." So let's say if I'm a person, I need to use a car. Of course, I would construct a car instance. Yeah. So for that car, I would expect it can. Allow me to drive forward, drive backward, and you know I fill the gas, and I just use this car. Maybe go to the grocery to do some shopping. But in the end, maybe you give me back as a Porsche car, a really fancy car, or you can give me a Ford car, which is an ordinary car. Even though the price is totally different, but they fulfill the same. Idea. They allow me to drive forward, backward, to fill the gas. So there's no surprise here. I can get extra benefit from those subclasses. Like it charges more. It's more fancy, more colorful, but the base. Things are already guaranteed for me always. Yeah. So so so so this all depends on what you actually what's what's in the original contract. But but one thing we can say is if you perhaps a little bit more realistic example is not buying a car but just you know renting a car when you're on vacation because this happens sometimes you
[23:27] know you you you make a reservation for a car when you go on vacation and you say I would like a you know a middle sized car and then you get there and they say Gee, we don't have any middle-sized cars left. But would you like, you know, a bigger car? This actually sometimes happens. This is actually a pretty good example of of the Liskov substitution principle in in the in the sense that your original contract, when you made the reservation, was that you say, well. I would like to have a middle-sized car and pay for a middle-sized car, and then they say, "Well, you can't get a middle-sized car, but we can give you a bigger car and you still pay for the middle-sized car because that was part of the contract." So they can't say you should pay more because you know your contract was you pay a certain amount, but they can give you something better. And and that's still okay. So that's actually it's actually a fairly intuitive, you know, example. Yeah, let's use that in the future for us.
[24:27] So we spent some time already talking about risk of substitution, and your Pluralsight course has good code examples. So for people who really want to learn, you know what it really is about, I encourage people to to check the course again. Yeah. So so the next one is called Interface Segregation Principle. Yes. Again, it's a fluffy term to me. Yeah, this is—it's actually not a difficult rule to grasp. It basically just says that. You shouldn't pass big objects around. You should pass small objects around. So the interface segregation, it basically just means that you know even if if an object you might have something that is implemented with a fairly big class underneath, but you should be able to sort of. Look at that object from various different perspectives and only see parts of it, if you will. But but really, you know, when it comes down to the practical matters of things, what it basically just says is that. Try to write your code so that you know if you have an input argument that's you know that comes into you know as an argument to a method and that you know is is an interface or some sort or an abstract base class. You should you should try to design those things so that they don't have. You know, dozens of or hundreds of methods. Try to design them so that methods that are available on the interface are basically only
[25:57] those things that the client code really needs to to talk to. So you know, if the client code needs to call three methods on an object, that should be the three methods that are available on on that interface and. Nothing else, and you know you can't. So, this is one of the reasons why we, why why we tend to, at least in Shiva, we tend to. Favor interfaces over base classes because you know an object can implement as many interfaces as you'd like it to have, whereas it can only you know inherit from one base class. So this becomes a fairly good way to even give you know even if you have an object that has some level of complexity, you can give it you know different roles or different aspects by saying well it implements this interface and this interface and this interface, and then you know depending on what the client code needs, you can just represent that object as being well. I'm I'm just now this object is just pretending to be that particular interface, and the fact that it also implements three other interfaces is not you know important for the that particular client code to know. It becomes more useful when you couple that or when you take take it in in the connection with the the last you know part of the solid principles, the D, which is the dependency inversion principle. So now I'm just going to skip ahead for that. Yeah, go ahead. So, so the dependency inversion principle. Now, first of all, we shouldn't get too confused with dependency injection. They're
[27:27] sort of related, but not quite. Dependency injection is probably more related to the open close principle actually than the dependency inversion principle. But dependency inversion principle basically just says that. Abstractions should not depend on implementation details. Implementation details should depend on abstractions. So, so the idea here is that you sort of define your abstractions first. So, that would be your interfaces or your abstract base classes, and and they. Can't or this shouldn't depend on implementation details. So if you want to define an abstraction for how do you talk to your database, for example, you can define a you know an interface that says, well, I can query this my database object and I can get some things you know returned that would actually be you know a real database query, or I can save something into my database object, but. Part of the interface definition shouldn't include specific things like you know the the the SDK for talking to you know an Oracle database or you know a SQL Server database or whatever it is. Yeah, I try to you know put my experience here is that in Apex we usually create so called a wrapper class on top of like the database connection. Yes. So later, when you need to change the database connection from SQL to Oracle, then just swap the inside of the wrapper. Yes. Right. Yes. Yeah. So so that's that's a fairly common
[28:57] way to do that, and that's that's perfectly fine because you have. You know, each each database technology tends to come with a specific SDK. So, you know, to talk to SQL Server, which is what I usually do, there's an SDK for that, and that's built into .dotnet. And then, if you want to talk to Oracle, you you have another SDK for that. It looks a lot like the other one, but not quite. And you know, there's another one for MySQL and so on. So, all of those SDKs come with very specific concrete types that enable you to talk to that particular kind of database. But then, as you say, you you create a wrapper. I like to use the word adapter because that's actually design pattern from from the design patterns book. But same thing, you you you create a class that implements the the abstractions that you've created, and the way that it implements the abstractions that we've created is then by you know using those specific SDKs. You know, depending on which database you want to talk to. Yeah, so that's that's a very common way of doing that, and that's yeah, that's that's still how I do it today. Yeah. So so go, yeah. If we go back to the the interface segregation principle, when I watch your videos, there's one thing really changed a lot of my perception about OO design, is that. A lot of programmers tend to have a concrete class, as let's say the circle database connection. We have save, we have read, and on top of that, we generate interfaces.
[30:29] Right. So we, from the concrete class, we created abstraction. Yeah. But in your video, you said we shouldn't have done that. We should more from the client side, which invokes this concrete or the abstraction, and from that to define how you design your interface, which makes your interface tend to be smaller. So, for example, maybe the client doesn't need a read method. It just does the save method. Then, why do you have the read methods a part of the interface? You don't. You don't have to, yeah. That made me think a lot, and it recently, the early days when I read the Java documentation, there's a lot of this. I read, I save, I what, whatever. Really small ones with only one method inside. I couldn't understand why people are doing that. Right. And then once it's a concrete class, there are multiple interfaces. You know, get implemented in that. Yeah. So this is the reason. Yeah, yeah. You basically explained it now, but that's you. And you're you also basically you know explain why I wanted to talk about the dependency inversion principle in order to explain the interface segregation principle because once you've Once you you know you arrive at the conclusion via the dependency inversion principle that you should only define the methods that you actually need, the idea from the interface segregation principle that
[31:59] you should only you know that an interface should only include the methods that a client actually needs. That's sort of just. You know that's almost just a byproduct of doing the dependency inversion principle. Following that one, so you explained it, you know, just as well as I could have done that. Yeah, just based on my experience. But it's true, and I think that's probably one of the most important things to take away from this. You know, interfaces should not be designed by starting with a concrete class and then, you know. Extracting the interfaces from from concrete classes that tend to lead towards all sort of of of pain, if you will. I'd say ninety percent of developers around me are doing that. Yeah, I know. I know. It's it's a very common thing to do, but that's why it's called the dependency inversion principle. That's because you sort of invert things. You you sort of turn things on their head and say, well, no, no, we define the interface first, and then we figure out how to implement it later on. Hmm. Okay. Yeah. So let's try to wrap up the solid principle. So from what I understand, we started with single responsibility principle, which is to break down your concrete implementation into small pieces. Yeah. And then we talk about the. The following four is more less about abstractions. How you design the interfaces, how you design the base class, subclasses, which is again to break things into smaller pieces. Yeah. So to me, like
[33:30] the OO designs, to break things into small pieces and then figure out how to construct them in in an elegant way, so that the code is not rigid, is not fragile. Yes, well put. So I graduated. Yes, you did. You paid attention. Yeah. So that's that's really interesting. But the thing is, how many years do I need to spend on this? To you know, this is art. It's not that easy to to get everything figured out. Yeah. Fair enough. Fair enough. I think. And I know you want to talk about functional programming as well. I think one of the reasons why I've become more interested in functional programming the last many years is that I agree that doing you know object oriented design there's a lot of art to it as you as you say. So you definitely can learn, but it takes many years. And and I think one of the problems here is that there's there isn't that much. Tangible guidance, if you will. There's there's a lot of of you know high level ideas, but how you actually make those things into The actual code that you're writing, that still takes a lot of practice, and and I don't want to you know scare anyone away from that because I think it's it's valuable to do, but
[35:00] but it it does take a lot of time, and I think the the fastest way you can do that is if you can somehow find some sort of mentor to attach yourself to, you can probably you know save yourself a couple of years of figuring all of those things out for yourself. But the next best thing, obviously, is to find you know a book or you you found a video course, whatever suits your learning style, and see if you can learn from from from other people there. But but it's still there's still a lot of of you know. Experience that you just need to accumulate in order to figure out how to do these things, and. And and the reason why I've become interested in functional programming is that there there's a certain I wouldn't say all functional programming but there's a certain sub culture in in functional programming that takes a more you know disciplined more mathematical approach to programming and sort of say well okay we can describe you know programming in terms of something that looks like mathematics a lot and that that gives us some Well, it actually narrows down your your options of doing things because you sort of have to behave in a certain way. But that also gives you some rules of thumbs and say, well, yeah, your code ought to look like this. So, so it gives you a little bit of I think. So, my thesis here is that. But I would like to do the experiment. But I would really, you know, if you imagine that you take, you know, a hundred young people who've never learned programming
[36:30] before, and just you know randomly divide them into two groups, and then you teach one group object-oriented programming and the other one functional programming, and then you see after a few months or after a year who can actually. You know, do more with programming. You know, with object-oriented learning it from scratch, all with functional programming. I would guess that. Function programming would actually be easier to learn, but the problem is that people, you know, you hear over and over again, and people say that you know function program is really difficult to learn, and that's because, well, if you already learned imperative programming or object oriented programming, well, then it's hard because you sort of need to unlearn a lot of things. It is a different paradigm, yeah. But one of, but to come back to your question, um. One of so one of the things that I've been interested in doing for the last many years is that we can take a lot of the ideas from functional programming and sort of pull them back into object-oriented programming to. Produce a a more you know disciplined a more structured way of approaching object oriented programming, if you will. So there's I have lots of that on my blog. If you just you know scan my blog for the last few years, you see a lot of that stuff going on. I you know, but I I publish an article every week, so. There's a lot there. I would definitely leave a link on our show notes. No, that sounds good. Personal blog.
[37:55] Hi, this conversation continues on the next episode. See you next week.
