Code with Jason
Code with Jason
261 - Abstraction and Emergence with Jorge Manrubia
In this episode I discuss abstraction and emergence with Jorge Manrubia from 37signals. We explore how abstractions should hide distracting details while showing essential information, debate whether programming guidelines are subjective or objective, and examine how good explanations distinguish useful abstractions from poor ones. The conversation touches on service objects, domain modeling, and the importance of showing actual code when discussing software design principles.
Hey, it's Jason, host of the Code with Jason podcast. You're a developer. You like to listen to podcasts. You're listening to one right now. Maybe you like to read blogs and subscribe to email newsletters and stuff like that. Keep in touch.
Speaker 1:Email newsletters are a really nice way to keep on top of what's going on in the programming world, except they're actually not. I don't know about you, but the last thing that I want to do after a long day of staring at the screen is sit there and stare at the screen some more. That's why I started a different kind of newsletter. It's a snail mail programming newsletter. That's right. I send an actual envelope in the mail containing a paper newsletter that you can hold in your hands. You can read it on your living room couch, at your kitchen table, in your bed or in someone else's bed, and when they say what are you doing in my bed, you can say I'm reading Jason's newsletter. What does it look like? You might wonder what you might find in this snail mail programming newsletter. You can read about all kinds of programming topics, like object-oriented programming, testing, devops, ai. Most of it's pretty technology agnostic. You can also read about other non-programming topics like philosophy, evolutionary theory, business, marketing, economics, psychology, music, cooking, history, geology, language, culture, robotics and farming.
Speaker 1:The name of the newsletter is Nonsense Monthly. Here's what some of my readers are saying about it. Helmut Kobler, from Los Angeles, says thanks much for sending the newsletter. I got it about a week ago and read it on my sofa. It was a totally different experience than reading it on my computer or iPad. It felt more relaxed, more meaningful, something special and out of the ordinary. I'm sure that's what you were going for, so just wanted to let you know that you succeeded, looking forward to more. Drew Bragg, from Philadelphia, says Nonsense Monthly is the only newsletter I deliberately set aside time to read. I read a lot of great newsletters, but there's just something about receiving a piece of mail, physically opening it and sitting down to read it on paper.
Speaker 1:That is just so awesome, feels like a lost luxury. Chris Sonnier from Dickinson, texas, says just finished reading my first nonsense monthly snail mail newsletter and truly enjoyed it. Something about holding a physical piece of paper that just feels good. Thank you for this. Can't wait for the next one. Dear listener, if you would like to get letters in the mail from yours truly every month, you can go sign up at NonsenseMonthlycom. That's NonsenseMonthlycom. I'll say it one more time nonsensemonthlycom. And now, without further ado, here is today's episode. Hey, today I'm here with Jorge Manrubia, jorge, welcome. Hey, jason, thank you. Thanks for being here.
Speaker 2:So you've been on the show before, but for anybody who has not heard you, can you give us a little bit about yourself? Sure, so well, my name is Jorge. I work as a programmer principal programmer at 37signals in the product team In terms of Rails and open source. I'm the author behind Active Record Encryption. I worked on adding Morphine to Turbo last year. Recently I released Hotwire Spark, which is a live reloader for Hotwire, and I'm a seasoned Rails programmer interested in all the parts of the stack, so that's a good introduction, I think.
Speaker 1:okay, in pre-show we talked about what we were going to talk about and we we touched on the idea of abstraction and there's maybe a few other things I want to touch on too. Um, I shared that I had been reading this book, the Beginning of Infinity, by David Deutsch. I listened to it on Audible first and it really gripped me and I liked it so much that I ordered a print version and now I'm reading it in print and it's kind of interesting because on this pass I didn't even realize how much I missed in the audio version. I'm reading stuff and I'm like I don't remember that being in there.
Speaker 1:But it's great because I can kind of take it at my own pace and when I encounter a topic that's kind of tricky I can slow down and make sure I really understand it, or at least try to understand it. And the interesting thing is that even though this is not a programming book David Deutsch, the author, is a physicist there are a lot of topics in it that I think apply to programming. And something I wish more programmers would do more of is read nonfiction outside of programming, because there is a lot that can apply to programming even if it's not meant to be applied to programming. That can apply to programming even if it's not meant to be applied to programming. So this book has a chapter on abstraction, and I'll see if I can kind of describe the way he comes at it. He ties it to this other concept of emergence. So emergence is kind of a tough one With some of these words like abstraction and emergence.
Speaker 1:Some of these concepts I look them up in the dictionary and the dictionary definition doesn't necessarily seem correct, or at least it's not the same sense as these other definitions. But to me emergence is like layers of explanation, like if we want to explain some kind of phenomenon. We can describe it in terms of the motion of atoms and stuff like that, or we can explain it in the higher level of what actually happened.
Speaker 1:I'll pause there real quick in case you have any comments. Jorge, no, I'm listening.
Speaker 2:That's super interesting. I wasn't familiar with the concept.
Speaker 1:Yeah, yeah, and I had encountered the concept of emergence before and here's how I kind of thought about it, like life is emergent. So we have, you know, when the earth was young, we had all the elements but there was only, you know, rocks and water and air and stuff like that. There was nothing organic. And then, well, let me see, after life emerged I'll use this part as an example. Okay, let I'll use a different part of it as an example.
Speaker 1:Instead of saying life is emergent, I should say aspects of life are emergent. So we have animals which evolved, and their emerged behaviors and systems. We start with these simple elements. You know, the universe started with just hydrogen and helium, and then those elements fused and made up other elements and so we ended up with I don't know more things to work with. Life evolved and then all the behaviors of all the organisms and all the complexity that we see. That's all emergent. It was never designed by anybody or anything like that, it just emerged. I don't think I did a good job of explaining it, but hopefully some of the other it makes sense.
Speaker 2:it's kind of like is this like from some makes sense? Is this from some philosophy school? Is it some kind of metaphysics related term about how to look at the world?
Speaker 1:Could be. I think it's also used for just its utility. So when we talk about emergent properties of systems, it's a different level of abstraction, like when we talk about evolution and animal behavior. We can speak in terms of the low-level phenomena that take place, but it might not have much meaning. But if we speak in terms of the higher-level, emergent phenomena, it could take on more meaning, and here's one example that I came up with the other day. If we ask the question, why did John F Kennedy die, one explanation is that a high velocity metal projectile caused sufficient tissue damage to his brain that his brain activity ceased. Another way of describing that at a more abstract level, at a of emergence, is he got shot. Okay, yeah, so hopefully that kind of paints the picture.
Speaker 1:A little bit about what this way of looking at emergence and abstraction is about it does.
Speaker 2:Yeah, I think I. I. I got the concept. I like the Kennedy example.
Speaker 1:Well, that makes one of us, because, as we can tell from my explanation, I don't have the firmest grasp on it, but the way this applies to programming is like, if you look, okay, so people have misconceptions about what abstraction means. So people have misconceptions about what abstraction means. I feel like a lot of times, jorge, programmers think that creating an abstraction means creating a generalization.
Speaker 1:We have a car and a truck, and so now we create this third abstraction called vehicle, and it's more vague and more general than either car or truck. That's a an abstraction, um, but that's not necessarily what an abstraction has to be. An abstraction can be something very specific and crisp and abstractions kind of get a bad name. And we have this, uh this, saying that I'm not totally comfortable with. Duplication is cheaper than the wrong abstraction and abstractions. They kind of have gotten a bad name, have you gotten?
Speaker 2:that impression at all, jorge? Yeah, for sure I mean. Yeah, I mean abstractions first of all. They can be done wrong, so you can build the wrong abstraction. To me, first of all, if we go for what an abstraction is useful from my perspective, I think that when you are thinking of a complex system as a human, you need to make that system understandable for you as a human. So you build those abstractions in order to be able to reason about some system as a human. So from that perspective, you can definitely create abstractions that help you think and reason about the system, or you can build abstractions that actually make understanding the system harder.
Speaker 2:So I think that that bad press that sometimes abstractions got could come from, you know this seeking, like strict recipes to build abstractions, like, for example, what you said there, like if you have two kind of vehicles, you need to create a more generic abstraction and make it generic, because that's what we are aiming with abstractions those kind of too narrow vision of a very human intellectual concept, which is an abstraction. It's like imagine that we were talking about words and about writing. How will you? You can teach writing, you know, with 10 guidelines. Like you need to. You know, use sentences of this length and always need to put the name and then the verb and then whatever. It doesn't work like that right. It's way more elevated as an intellectual endeavor building the right abstractions. So I think the bad press could came from there. You can definitely cause harm. You can definitely cause harm with the bad abstractions they are. I agree that they, or I do believe they can be worse than not creating them in the first place.
Speaker 2:Recently I can put you an example. I remember well not recently, maybe a couple of years ago we were debugging a very tricky bug in Hay the email system that was related to the export system. So you can export your email and the export system was. It was. The code looked very neat but there was like a tremendous amount of indirection for something that was, in essence, very simple. So travel the suit in and find it the back, and reasoning about how things worked and what could be failing took us like hours and it was like maybe the abstraction wasn't right. You know, even when it looked right, you know at the first glance, uh, it wasn't. I don't know. It was making hard. It was making to understand the system harder. That's for me a smell that an abstraction is not the right one yeah, what do you think?
Speaker 2:do you think they can be bad? Do you agree that they can cause?
Speaker 1:oh, of course, more. Okay, yeah, um, there's so many things in there that I want to go deeper into. Um, okay, one is is I I think a lot of people, including myself, until pretty recently, only had a very murky idea of what an abstraction is and what the purpose of an abstraction is, and my view of it is shifting, even right up until you know, a few days ago, in the present moment, and I think a lot of people think about abstractions in terms of code and, of course, people think of software systems in terms of code. But something that I've been preaching a lot lately is that a software system isn't exactly made out of code. It's made out of ideas, and the code is just a codification of those ideas. Ideas, and you can have abstractions without having code. Um, just like, well, one one example that the beginning of infinity uses is that the concept of causation is an abstraction. Um, like one pool ball hits another pool ball and the second pool ball moves. That is a sequence of events. It's only that we added a higher layer of abstraction and gave it the name causation.
Speaker 1:And so if people have abstractions just in science, nothing to do with with computers at all um, obviously we can have abstractions then in software systems without necessarily having any code behind it.
Speaker 1:So to me it's like, um, we're thinking. It's like the art of coming up with abstractions is the art of slicing up the world into pieces, and slicing up the world into pieces in such a way that it's easy to do the work that you need to do. And I think that the concept of an abstraction is closely related to the concept of a model um, um. And this is something that I had a pretty narrow view of for a while, because if you have a rails application, you have controllers, views and models, and it's like what's a model? Oh, it's something in the app model directory that inherits from ActiveRecord, but it can be broader than that in a software system and it can be broader than that just in general. Again, it doesn't have to have anything to do with code. Partly because I forgot my main point, I'll turn it back over to you, jorge, in case you have any comments.
Speaker 2:No, you made a good point. I actually just realized that I normally use model and abstraction interchangeably as if they were the same concept. So, yeah, you made a good point. I loved what you said about an abstraction needs to serve a purpose. I mean, if you build the abstraction, it needs to serve the purpose of the system or the problem you are trying to solve. And again, I think that makes it very, very hard to come with. That's why it's very hard to come with good design guidelines. You know systematic design guidelines.
Speaker 2:When you are creating models or instructions to solve a problem, it's like what's the problem? Each problem is normally quite different from each other, so what can work in one place doesn't necessarily have to work on other place. Also, I think that that's why it's so good to start. I mean, an approach I love in general when building software is to start with something simple and then start iterating on the code and try to and try to. I mean because sometimes you see the distractions right away, based on past experience or because it's something that you just know that needs to be solved in a certain way.
Speaker 2:But more often than not you need to get something working and then start working on the internals of that, and at least for me I don't know if it's the same for you or for other people, but I normally start with something working. Then I start working on the code and it's when I start seeing the instructions. I need that in some kind of way. They kind of emerge I'm going to use that term from the needs and what you're seeing, because you are trying to enforce certain traits in the code, ultimately making it easy to read and I don't know. Yeah, yeah, yeah.
Speaker 1:Yeah, I think that's pretty universal. You know, there's that quote of, like, every complex system that works started with a simple system that works. It can't go any other way, whatever the exact quote is um. So I think that's kind of a universal truth, um, and you can either follow it or you can pretend that it doesn't apply to you and then crash on the rocks of reality, and then you'll just have to start over or whatever, um and when you yeah when you mentioned.
Speaker 1:Yeah, I try to be pretty agnostic early on as to what the um, what the abstractions are going to be. Um it's. I think you can run into trouble when you create speculative abstractions. Uh, too, too early. I prefer to start with what I know for sure, even if it's at a very low level of abstraction, um, and then, later on, maybe I'll see the smaller pieces, maybe I'll see the smaller pieces and, like you said, a good abstraction will will emerge from those um, and I want to. I want to make a comment. I have a gripe with something you said earlier, jorge. Um, you were talking about, like, the idea of the right abstraction or wrong abstraction and stuff like that. Um, I have have tried to get away from thinking about things as being right or wrong or whatever, versus useful or advantageous.
Speaker 1:Um cause it's. It's not quite so black and white. Sometimes, like an abstraction can be a really really bad abstraction and sometimes it can be a good one, and maybe in certain scenarios there's like clearly one correct answer or whatever. That or whatever. But I feel like it's more fitting to reality to speak of them as being like advantageous or not, or whatever.
Speaker 2:Yeah, I agree. Yeah, I like that framing and that terminology better too. It's true that sometimes, when we're talking about software, we are very categoric with the terms right, wrong. And you know, I agree that. Well, first of all, there is a strong subjective component to everything, and with abstractions I agree, yeah, it's much better to talk about whether they are useful or not rather than whether they are right or wrong yeah, and that's interesting that you mentioned subjectivity, because it's like almost all of software design is subjective, like I'm not sure that it's not 100% subjective.
Speaker 2:Yeah, yeah Well, I think it's reasonable to think that there are some basics that we all would agree, but maybe that's too much, maybe that's too much to believe, I don't know.
Speaker 1:What does it mean if everybody agrees on something? Does that mean that it's right? What does it mean if everybody agrees on something?
Speaker 2:Does that mean that it's right? Yeah, I mean. Probably I can come with some function in Ruby that any experienced Ruby programmer would say oh, that code is not great, or that code is kind of neat. I don't know. Some basic foundation maybe, but it's true that you know, I've met so many different fantastic programmers with so different tastes when it comes to design, and the thing is that I mean what you need to look is to look for teammates that share the same preferences in order to get a functional group of programmers working together. But it's true that if you try to unify some guidelines so that they work for everyone, it's so futile. And also different teams using widely different approaches can succeed. Widely different approaches can succeed If, by succeeding, you think of getting a successful product that you can maintain in time and make it a very profitable business.
Speaker 2:As we know, you can enumerate all sorts of different, widely successful products that use completely different approaches to software design. One code base that I always think of is this course, the Rails Forum Software, which is a fantastic business, fantastic product, probably the best forum software out there, created by Jeff Atwood right From Stack Overflow I think he's one of the founders and the code base and how they work is completely different in terms of patterns and you know, approach aesthetics to what you know. You would see in a place like 37signals and can you say one is wrong and the other is not. You'd rather talk about, you know, this group of people prefer this and this other group of people prefer that and both are happy. Develop, developing teams right.
Speaker 1:Yeah, it's interesting because like um, to get like really fundamental um, how do you, how do you tell if some particular uh software design guideline or heuristic or whatever, is a good one or not?
Speaker 2:how do I decide?
Speaker 2:that is that the question yeah uh, yeah, you definitely don't have any empirical or mathematical way to say that that guideline is a seven. So, yeah, it's not good enough for me. You can't do that, so I guess you always talk from a combination of past experience and and taste. Uh, there, there are definitely some things you can say if you want to be more like.
Speaker 2:You know, I think 30 years ago metrics used to be a thing in software, or at least there was a lot of research around metrics and around, you know, trying to get with some numbers that could tell you about the quality of some code base for whatever interaction you want to build in your application. You will have to build a service object, for example, which is one of our favorite topics here. You can argue that you are going to get an explosion of classes that won't really help to solve or to get much advantage in terms of fundamental design of your abstraction or your domain model. You can say, okay, maybe you can create some compelling case against doing that systematically, but even in that case, I doubt you can get very far.
Speaker 1:I think we are talking about preferences.
Speaker 1:Yeah, I'm really skeptical of metrics because, to take any two I don't know projects or what you might call events, and to try to take any number of events and compare them, to try to take any number of events and compare them I don't really see how it could ever give a meaningful result, because every project has so many variables in it that you can't possibly control for enough variables for the projects to be comparable in a meaningful way.
Speaker 1:So my thought because I pose this question to myself how do we know whether any particular guideline is good or not? And the answer I came up with is that all we have is each programmer's own personal experience, because, even though you can't compile a database of all the projects that have happened, you know, let's say, all the Ruby on Rails projects in the span of 10 years or something like that, and we divide them into ones that used automated tests and ones that didn't, or something like that you can't get usable enough data to draw a valid conclusion. But I think what human beings can do is you can take your own personal experiences and say, okay, I worked on these five projects.
Speaker 1:The first one we use automated tests, but the project was a total failure, but that's because, you know, we had this guy on the team who really sucked and blah, blah blah. And then the next project, we didn't use automated tests but it was a total success. But that was a much smaller, shorter project and blah, blah, blah. And so a person can kind of control for these variables from project to project and they can draw valid conclusions. So it's like, ironically, anecdotes provide higher quality evidence than data. In this case, at least as far as I can think.
Speaker 2:Yeah, I agree, yeah, yeah. But my previous response was in the line of trying to look for formal, you know justifications and some kind of formal reasoning about what's good and what's bad. I don't think that's possible. But I totally agree and actually I do believe that, also based on past experience, on you know what books from experienced authors tell you. So, for example, you can have heuristics following with the service example, like it's, you know, since domain-driven design was presented, they were talking about the dangers of thinking that everything was a service. So that was something that they were presenting, you know, based on their experience, even if there was not risk, formal justification for that. It's like there is a danger if everything, if you make everything a service, because you're going to end with an anemic domain model.
Speaker 2:And an anemic domain model is not a model that lets you reason about the domain and build a solution, which is a quite compelled to me. It makes sense and it makes sense enough so that it's an idea I would defend very strongly if I'm responsible of some, if I'm leading some development team, even when I can justify, you know, with formulas and numbers. But I agree that you have to be careful with how strong you advocate for things, because it's something also like I often express my own opinions very strongly and probably I should maybe review some terms and some framing for the things I present, because it's true that you know, if you, if you want, if you want to base your um ideas on empirical data, you can find empirical data sustaining any, uh, any approach and I that's not to say that I don't have strong opinions that I would enforce in the place I I work at, but uh, yeah, I think you made you made a good point about the right and wrong framing.
Speaker 1:And I'm kind of poking back at your ideas just to be just for a fun conversation. I'm being a little bit annoying on purpose, Okay annoying on purpose, um, but okay.
Speaker 1:so even though, uh, all those things are true, it's obviously not the case that anything goes, it's not that all opinions are equally valid, and so I I don't think we're, uh, I don't think we're out of the woods yet, um, and it's also not a popularity contest, because if it were, then I'm sad to say that maybe, like it would be the case that service objects are the way to go, because that seems to be the predominant wind in the, the ruby community right now, um, and so there are plenty of, like, minority positions that are actually better than what the majority thinks, but how do we know that they're any better than these more popular views? That's a question that I'm posing to us.
Speaker 2:That's a question that I'm posing to us how do we know that something that gains popularity, like service objects, is good or bad? Well, it's again a matter of experience and thinking about systems, I think. But it's very hard to, yeah, it's. I think it's very hard to come with a good answer Like, okay, forget about experiences, forget about books, service objects.
Speaker 2:I could tell you service objects if everything is a service object, I mean, it's fine as long as you care about your domain, but normally everything is a service object result into not only a huge set of service objects but capturing all your domain operations as service objects that invoke each other, so you end up with a missing domain.
Speaker 2:That's a problem. You can say why is that a problem? Then you can say, oh, because then you are not leveraging the benefits of representing your domain in code, you are not leveraging the benefits of representing your domain in code, you are not leveraging the benefits of using object oriented programming to represent your domain. And you can say, oh, but why is that bad? Then you can again, you enter into subjective territory and I can say, oh, because for me as a human, I've seen all sorts of approaches and object oriented programming to me makes it easier to model, the real world and some other programmer can say, oh, but I'm an Scala guy and you know, functional programming for me is the way and you know, at some point you reach some point where it's a matter of I don't know different schools or whatever.
Speaker 1:Well, I hope that you're wrong about that and I just realized something. But before I say that, I agree with pretty much everything else you just said, and I think that is probably part of the answer too. But I remembered a thought that I had the other day, and it has to do with the concept of explanation. So also in this book, the Beginning of Infinity, which I've been kind, of obsessed with lately.
Speaker 1:it talks about the idea of good and bad explanations and the fact that science is about explanation, not about prediction. So I'm going to get this pretty wrong probably, and it's going to be clumsy wording, but bear with me. Um, you know, there's there's an idea that science is about prediction. Uh, we have theories, because the theories can predict phenomena in nature, and if the theories provide accurate predictions, then the theories are valid, and if they don't, then they aren't. And the book also talks about the concept of inductive reasoning, where we look at what happens and you know, the sun has risen every day in my life for 40 years and therefore I can predict that the sun will rise tomorrow because I have used inductive reasoning to work out that that's what happens. But this book says inductivism is false and the reason the sun will rise tomorrow is is not because the sun has risen many times in the past. That's a bad explanation.
Speaker 1:The. The reason that it'll rise tomorrow is because we have an explanation of how the solar system works. The earth goes around the sun and it gives and the earth revolves every 24 hours and that revolution gives the appearance of the sun rising every morning, and so that's the. That's the theory that that we can rest that prediction on. But the whole thing is not even about prediction, it's about explanation. And so when we have a particular programming heuristic, I think maybe I'm just putting this forth as a possibility. I'm not saying I think for sure that this is right. But maybe the difference is that the good heuristics have good explanations behind them and the poor ones don't. And I think you could put that to a test by asking for the explanations of the ideas behind service objects, for example, and the explanations behind the ideas behind service objects, for example, and the explanations behind the ideas in OOP.
Speaker 2:That's a good point. Yeah, I like that way of putting it.
Speaker 1:And you can start, for example not that this episode is intended to be a shit-talking session about service objects, but you can ask first of all, just what is a service object?
Speaker 1:And there's no single answer, and that's the first clue that it's it's maybe kind of a corrupt concept. You can also ask what problem does it solve? Um, and that's another one that I think most people wouldn't have a valid answer to. I've heard certain answers like it makes your code easier to test. It's like okay, well, explain why you think that's true, because it might make your code easier to test than whatever you might have been doing before. But does it make it easier to test than an object-oriented programming style? I don't think so, and if so, I'd love to hear the explanation for style. I don't think so, and if so, I'd love to hear the explanation for that, but I don't think there is an explanation. So maybe the difference is all about explanations.
Speaker 2:Yeah, I like that for sure. But even then, like, if you get picky, you can. I think that at some point I mean I think both this is not a dichotomy it's both possible to have a strong opinions and a strong beliefs about something, which are not like exoteric beliefs, they're based on, you know, things you've learned through reading authors, practicing, trying different approaches on different codes sorry, different projects reading different code bases. All those things form a base of knowledge that can, you know, sustain some strong opinion in one way or the other, and then you can articulate the reasons, as you were saying, based on that. As you were saying, based on that. But I do believe that at some point you can hit a very subjective component that is, I don't know, inherent to humans, because writing software I mean creating software it has this component which is like writing words, and it's very hard. I mean, I think it's kind of easy to agree on who's a good writer or who isn't, but you know, there's also excellent writers that use completely different approaches to how to compose their prose. Some authors are very simple and concise and some other authors are very descriptive and maybe more complex to read, but both are, you know, considered excellent by by the public and the experts.
Speaker 2:So I don't want to go as far as saying, oh, if you use I mean, I think there are teams that just, or people who just prefer this very structured approach of using different archetypes or buckets for the things and or, or, if you are managing imagine that you're managing a huge team of folks which is I don't have experience managing I don't know 200 programmers trying to do something together. Maybe it's good to have so to to, to to. Uh, you need to create this controller. This controller is going to both. This service, this service service is going to invoke I don't know this other thing.
Speaker 2:You know what I mean that maybe in different contexts or for different, or if you get a group of people that just loved that way of working, I don't know, I think there is. I mean, yeah, I'm all about. I actually have written whole articles trying to articulate my reasons, pushing for a certain way of doing things in rails. So I believe in that. But the, the formality component, at some point there is a subjective component that I can, I can't shake. Uh, you know yeah, that's true.
Speaker 1:Um I I go back and forth because you know I said earlier that I feel like it's 100% subjective but at the same time, part of me feels like very little of it's subjective. The part of the challenge is like what qualifies as subjective or not subjective and I've, in thinking about this question, I've thought about, I tried to take like one of the most, one of the least controversial examples that I could and the least controversial programming heuristic I could think of is that it's a bad idea to give all your variables in a program and let's just say all your entities in general, to give them all one letter names.
Speaker 1:Like it's better to give your variables descriptive names than to all. Give them all just one letter names yeah, nice, that's a good example. Yeah, it's subjective, but it's um pretty hard to argue with. But if, if, we're going for like full intellectual honesty, like how do we really know and do we really know that that rule is any good, and is it objectively good or is it a matter of subjectivity?
Speaker 2:Yeah, yeah, that's a good example, because that will be an example, one of those basic things that I think most programmers could agree on, right, I would imagine like nobody would say I prefer one letter variables against using descriptive names, but maybe there are people who prefer.
Speaker 1:Yeah, maybe there's some nutcases who do that and they're proud of it. Yeah, but but those people aside, yeah, and again, I don't think it's a matter of democracy, like I don't think enough people voting that that is is a good way to go, is a valid way of doing it.
Speaker 2:Yeah, to me. What always bothers me in these debates, like the thing, is that, of course, anyone can use whatever they want. I have my strong preferences, you have yours, all the people have theirs. What always bothers me and triggers me is when someone presents an approach that I strongly believe is flawed. Article where I kind of confronted certain this is cool in Rails of using application level objects like services or interactors and blah, blah, blah, not blending active record models with your domain entities.
Speaker 2:There are these, you know, things that some people push very hard in the Rails community for and that always bother me.
Speaker 2:It's not like the patterns themselves or the guidelines themselves, but when they are presented in a very, you know, with a lot of conviction, like you need to do this If you want to get, I mean, when things get real, you need to do things in this way, because that's what we true engineers do. That framing bothers me a lot and I definitely try to not use that framing when presenting my ideas. Now it's quite different if you say, oh, we're a bunch of folks and we prefer to do this and this is working for us and this is the proof. We have these applications, they are working. Or we are Shopify, we are, like I don't know, hundreds of developers and this is working at our scale after trying many things. That's quite different to say listen, if you use Rails in that way, you are doomed. You need to do Rails this way. I don't love the absolutist positions that you sometimes read and I think they cause very they cause harm not to experienced developers, but to novice programmers entering into the world.
Speaker 2:Suddenly the first day they don't really have anything to contrast and they just assume that invoking some domain entity from your controller is violating some kind of you know sacred principle and instead you need to create an additional object. And suddenly you know you need to do that for every interaction and that's the way you create race applications and that's the way you, you learn to do it.
Speaker 1:So yeah, um, yeah, I learned another thing from this book that I'm not going to stop talking about is, um, the, the concept that's called scholasticism. I had never heard about this before, but you know Aristotle whenever he was alive. I forget when, but you know, like 2,000 years ago or something. No 4? No 2,000 years ago.
Speaker 2:Somewhere in that neighborhood.
Speaker 1:He laid down all these supposed truths and then Aristotle's teachings were then taught dogmatically for the next 1,500 years or whatever, and it was kind of unquestionable Um and that mode of thinking was called scholasticism. Apparently I never knew about that Um, and and now you know there's. There's related ideas, scholasticism, uh, authoritarianism, dogma and a lot of programming.
Speaker 1:advice is given and received in a way that resembles scholasticism or dogma, cargo culting, that kind of stuff. What's missing again is this concept of an explanation, that kind of stuff. What's missing again is this concept of an explanation. If you say that descriptive variable names are better than one letter variable names, that one's kind of self-evident, but it it would be good to provide an explanation that one letter names are confusing.
Speaker 1:If you take something that's a little bit more nuanced, like um, oh, I don't know what's an example of a programming here. Oh, the short methods tend to be easier to understand than long methods. Um, if you man that one's kind of actually hard Like, what is the explanation for that exactly, other than just restating that things that are small tend to be easier to understand than things that are large? Maybe that's the whole explanation, right there. Anyway, a lot of times these things are passed down where it's like you should do this, but it's never explained why you should do this, and then the consumer of that information never asks why and I think, yeah, totally, yeah, you're totally on point.
Speaker 2:Uh, I, something I I loved is something I read and I learned many years ago from, from david, uh, henner, mayor hansen, which was like this advocacy for showing the code. Because the code? Because when you're discussing things in the abstract, you know, with words you can make almost any idea uh, appealing, uh, if you use the right words and the right framing and the right presentation. But when you see the code is, you know, everything you know lands into the realm of the concrete. So I think that even when you can get formal software discussions benefit tremendously from showing code as real as possible, because sometimes it's not possible to show thousands of lines of code, but showing realistic looking code in examples.
Speaker 2:And it's something I try to do, because 37signals always give me permission to share code in blog posts, which I think is rare. Like most companies don't do that, they don't share code. So it's something I praise David for, for allowing that, and I think it's so much I recently there was like some, what is this framework, which is an alternative to Rails in Ruby, which is kind of uses this approach, this different approach where you have separation of concern more strict that Rails provide this Harami right, harami or Harami Harami RV. Separation of concern more strict that that word rails provide this harami right, harami rv. I think they released um a new version recently.
Speaker 1:Yeah, oh and they were hanami. Yeah, hanami is hanami rv, I think I love to imagine that the creator of Hanami is listening and we're just butchering the name.
Speaker 2:Sure, no, yeah, I mean, I think it's a. They have all my respect. They created something that represent their vision and they get it to the you know, finish line. They released a second version recently and it's an alternative in Ruby for if you want to build web applications and you don't want to use Rails. So they definitely have all my respect.
Speaker 2:And something I loved about them is that they've been talking about for a long time about the persistence layer, how they're going to do that in version two, and I was really curious about that.
Speaker 2:And then they published that module and they published the documentation and they published the guidelines and you can see the code and I remember I had been reading about the theory for a while and I was really curious about to see how does this look in code. So it was great. For me, it's like it's something that should come with every piece of software guideline you want to push regarding how to design. You should show the code, Because that's what can convince you to use that or convince you of not using that. But if you don't have code, it's so much harder to get an opinion on things and also discussions can extend to the infinite, Because with words you can defend your approach, I can defend my approach. But if I say, okay, this is my code, and you say this is my code, at least you can see which one you prefer, Even if two different people prevent different pieces of code.
Speaker 1:Right, yeah, and what is sadly extremely rare in programming and I guess it's rare with with people in general is, um, a desire to dispassionately seek the truth and to have intellectual humility and have the ability to be genuinely open-minded and admit when you were mistaken about something and let go of your most cherished beliefs if you discover something. That's better, even if it wasn't your idea and even if it means losing face and saying, man, my idea that I've been clinging to for the last 10 years is actually not so great and this other thing is is better. That's really hard to do and it's really rare to find somebody who's willing to do that. And it's rare even to find somebody who's willing to have an intellectually honest discussion where their objective is to kind of clear their mind and say okay, let's find out about the merits of these various approaches, independently of whether it's your idea or my idea or whatever.
Speaker 2:Yeah, totally, totally, and I've seen myself in this quest like many times where I'm studying something that I became obsessed about and I try to make it work until I realize it doesn't, I remember. Are you familiar with the DCI data context interaction pattern? I think it is.
Speaker 1:I've heard about it.
Speaker 2:I think it comes from the I'm not sure if it has the same author that you know formalized the model view controller back in the day. I'm not sure, but if it's not, it's like an evolution. It was presented like an evolution of that, but I remember being fascinated by the proposal when I was reading about it. I remember thinking, oh, this is it, this is how you need to design your applications, and I tried to make that work. Back in the day with Java, when I was in Ruby, I was like, oh, ruby is way more dynamic. It's a great language for these context things where an entity can behave one way or the other depending on the context. You could, you could model that with ruby pretty, pretty nicely, but at the end of the day, there was a mismatch between how good the original article sounded and how the code looked.
Speaker 2:So, and I, you know, find myself many times, uh, in that. So, and also that's why experience is valuable and you know, having an open mind, as you said, and trying to trying things and seeing what works for you and what doesn't, is, yeah, recommendable. But in general, something I would advise to anyone who is starting is to try to when you're discussing things, and if you find yourself spending too much energy on something, try to see the code. How does it look in code? Because, if not, words are very valuable, but at some point you can be discussing and spending a lot of energy on something that is not really practical, and I'm talking out of my own experience multiple times in the past.
Speaker 1:Yeah, yeah, I've certainly done that too, um, where I I don't know if this is the same thing as what you're talking about, but I keep refactoring a piece of code beyond the point where I'm sure that what I'm doing is actually an improvement. I'm sure that what I'm doing is actually an improvement.
Speaker 2:I've definitely done that before.
Speaker 1:Yeah, I'm sure. Yeah, then my so-called improvement ends up actually making things worse. We should probably start wrapping up pretty soon. There's one at least other thing that I wanted to make sure I got in. We talked about abstraction a little bit at the top of the show, but we never provided a definition of abstraction, and that's something I've been trying to do lately is take these terms that we throw around all the time and ask myself what actually does this mean? Because it's surprising how many fundamental terms that I use all the time that I can't actually come up with the definition of, and that doesn't seem right. So I attempted to come up with a definition of abstraction, and we'll see if I remember it off the top of my head.
Speaker 2:Okay.
Speaker 1:I think the art of abstraction is the art of hiding, distracting details and showing essential information. That's the definition that I've come up with.
Speaker 2:I like that. I like that. So hiding, how is it Hiding? What? Hiding? Distracting details, distracting?
Speaker 1:details, yeah, and showing what's essential.
Speaker 2:I like that. Yeah, I would also add something about that. It lets you think about a problem. It's something that is useful for you as a human, but I like that definition.
Speaker 1:Yeah, I'm questioning that definition a little bit in light of what I read in the beginning of Infinity, because I think there's also something to do with meaning. I think abstraction has something to do with taking low level, low meaning details and replacing it with higher level um, I don't know how to put it um, replacing it with a higher level of abstraction, but that's a circular way of of defining it. Um, you know what I mean. Like, instead of instead of saying JFK died because a metal projectile damaged his brain, blah, blah, blah, we say that he got shot, right? I don't think that exactly fits my definition of hiding, distracting details and showing what's essential. I guess kind of it does, but there's nothing that my definition says about meaning yeah, to me it's like the hiding details bit to me.
Speaker 2:It's like the hiding details bit To me. It's like to me the showing hiding details part evokes like kind of the programming encapsulation concept which is so important, but to me that's kind of very low level. To me it's more like the function what's an abstraction? What's the goal of an abstraction? To me that should be. It's more a more defining trait, is like a mental construct that offers you know, it's a mental construct you can use to reason about a problem. For me that would be a definition. I think details is normally the case that you want to hide details and just see the details that are interesting. That's another way to put it. It's true that it's good to it's hard to define words that you're using all the time.
Speaker 1:That's I think we should do that more often, partly because I think that maybe sometimes we don't even know what these concepts are. You know, we're using these concepts so much and it doesn't even occur to us that we might not know what they mean. That was definitely the case with me. It didn't even occur to me until like three days ago that I didn't know exactly what abstraction meant. And the funny thing is, I thought I did. I thought I went from not understanding it to understanding it, and then I encountered a new piece of information and it made me realize that I didn't understand it. But OK, just now I had this thought Maybe what abstraction?
Speaker 2:is? Is it's focusing on a higher?
Speaker 1:level of emergence Nice. But what is?
Speaker 2:emergence, yeah, but it's true that I like that linking, because it's true that an abstraction so you have a mess which is the system you want or the problem, the system you want to build or the problem you want to solve and an abstraction is not something that is there like trying to. You know it's there and you just need to see it. It's like something that kind of emerges from that mess, right, right, so it's.
Speaker 1:Maybe it's true that all abstractions are human constructions, like I think you could say, we use the example of causality earlier. Maybe causality is a human construction. Hmm, I think so, it's not. I'm not sure. Okay, I I looked up emergence just now. Um, according to wikipedia, emergence occurs when a complex entity has properties or behaviors that its parts do not have on their own and emerge only when they interact with a wider whole. That is interesting. Indeed, yeah, and I'll read that again for the benefit of the listener Emergence occurs when a complex entity has properties or behaviors that its parts do not have on their own and emerge only when they interact with a wider whole. So, now that we've said that, how do we like the definition of abstraction is when we focus on a higher level of emergence. I think maybe it fits, but I think maybe it's not quite sufficient.
Speaker 2:Yeah, it's like something is missing there, but it's like you could say that's a trait or something you could say about abstractions, for sure.
Speaker 1:Yeah, it's when we focus less. Focus less on an entity's parts and focus more on the emergent properties of those parts.
Speaker 2:I think maybe abstraction and emergence are very closely related. Abstraction and emergence. The thing is that I hadn't heard of it. Which book is this? Is it from the same Infinity? I hadn't heard about which. Which book is this is? Is that is is from the same infinity book?
Speaker 1:yeah, the beginning of infinity.
Speaker 2:By david deutsch I should definitely have a look at that. It's so good. It's like a nice. Is it new or is it like one of these classics, like from?
Speaker 1:it's from maybe like 10 years ago or something.
Speaker 2:Okay, yeah, or five years I don't know, a number of years ago, um, but it's not like 50 years ago or something.
Speaker 1:Okay, yeah, or five years, I don't know A number of years ago, but it's not like 50 years old or something like that. Yeah, and it's like every chapter has made me think about programming differently. And it actually does talk about computing a lot. It doesn't really talk about programming, but it talks about computing and the history of computing and stuff like that. It's. The scope of it is just so broad, it's crazy nice and definitely.
Speaker 1:I'm definitely going to check it out yeah, and if you're going to check that one out, uh, he has an earlier one called the fabric of reality, and I kind of wish that I had read the Fabric of Reality before the beginning of Infinity. So I'll just mention that that's the sequence in which those two books came out. Anyway, jorge, before we go, is there anywhere you want to send people online to learn more about you, or anything like that?
Speaker 2:Yeah, sure, you can check my personal page at jorgemanrubia. My name and my last name dot com. So, yeah, there you have my Twitter and LinkedIn, and I also have like a mailing list you can subscribe to if you want to receive the things I write.
Speaker 1:So there it is. Thank you. Awesome Well, jorge. Thanks so much for coming on the show.
Speaker 2:Thank you so much for having me, jason, always a pleasure.
Speaker 1:Definitely, see you.