CHRIS (00:08): Welcome to the Elixir Outlaws. The hallway track of the Elixir community. AMOS (00:17): Hey, it's the show. ANNA (00:18): Hey, how's it going? AMOS (00:20): We missed you. ANNA (00:21): I missed you both AMOS (00:24): Super busy lady. ANNA (00:25): You both have been super busy. Last week I was all ready to do the show. And y'all were at this silly conference called Strange Loop. Speaker 3 (00:32): It's like the worst conference ever. Yeah. Nobody ever goes there. It's like a desolate desert. No, it's fantastic conference. I love it. ANNA (00:39): What was the highlight? AMOS (00:39): Um, Oh shoot. That's hard. I went, so I did three conferences that week. I did Elm conf, strange loop,, and Erling, ICFP. And I would have to say my highlight was, was Chris and I at strange loop. And John Hughes walks in the door and sits right in front of us and I felt smarter immediately. CHRIS (01:02): Yeah, that one was pretty fun. That was a pretty fun moment. AMOS (01:04): Yeah, of course. I didn't talk to him. I ran out out of that room. I don't remember what the talk was it? Oh, it was, it was Stu's talk. Wasn't it? CHRIS (01:12): That was Stu's talk. Yes. Yeah. AMOS (01:15): Which was a fantastic talk, but there was a lot of closure in there and I, I think I did a peep code. Do you guys remember peep code? Oh my gosh. CHRIS (01:24): Yes. I remember that. I remember. No. I remember that. AMOS (01:27): There was a peep code on closure and that is my extent of closure experience many, many years ago. ANNA (01:36): Is that your new house? AMOS (01:37): That is my new house. This is my gigantic, uh, office. I pretty much took all of the basement. There's a kitchenette and a bathroom and that's all going to be office space. So that way I can have other people come work with me too. And if I have somebody come in at once, like maybe they're out of town and they're going to work with me for a week. There's a guest room with a, uh, a Murphy bed. Murphy beds are awesome. CHRIS (02:03): What's a Murphy bed? AMOS (02:04): It's a, you know, the beds that come down from the wall set up on their end during the day. Yeah. Yeah. We talked about buying one. When we were looking at houses, um, if there was a guest bedroom that could be connected to the office for people coming like that. And uh, when we looked at this house, there was a Murphy bed already in the room with a sticker on it that said it doesn't go with the house, but if you want it, we can work something out. I was like, yep. I want it. ANNA (02:30): That's what sold you on the house. Huh? AMOS (02:31): Yeah. Actually, the house is terrible. It's falling apart. It's got holes in the walls. CHRIS (02:35): The Murphy bed is holding up the house. It's actually a structural part of the house at this point. AMOS (02:40): No, so the house is pretty awesome. Conferences have been crazy. I, you know, I've been here a month, but I've been two weeks gone to conferences. So I haven't really had time to settle in that much. ANNA (02:50): You're heading out again soon, right? Gig City is in a couple of weeks. AMOS (02:53): Yeah. Yeah. I just bought a plane ticket to that too. Which Southwest doesn't fly. Semi disappointed and semi really happy that I didn't have to fly Southwest. CHRIS (03:04): Welcome to Chattanooga where you can only fly direct to two different places. AMOS (03:08): Where leg room is a necessity. ANNA (03:10): You can fly to New York now, right? Speaker 4 (03:13): Well, you can fly to Newark. It sounds like New York. If you say it really, really fast. AMOS (03:17): And they're really close to each other. CHRIS (03:19): The only destinations you can directly fly out of Chattanooga are like Charlotte because of American and Atlanta, because of Delta. Occasionally you can fly to Detroit and then occasionally you can fly to Newark and that's about it. Those are your, those are your four direct flights out of Chattanooga. ANNA (03:36): So Atlanta is so close. CHRIS (03:38): Well, yeah. So every time I go anywhere, I, cause I always, I have status through Delta or whatever. So that was in a flying Delta. So no one told me until like, I've been doing this for a while that you need to like pick an airline and then stick with it. So now, like I just happened, I didn't really choose. It was more just like Delta's close and flies. Like Atlanta's close. So that made sense in any case. Yeah. So every time I want to leave here, I take a approximately 20 minute flight to Atlanta and then I move across the entire Atlanta airport. Cause they use you fly into like, like the slum Gates where there's like, no one there. And the doors are all open and it's hot and muggy. And then you walk from there into the like Gates for humans. And then once you get on the gate for a human, you go to like a real city and then you end up somewhere else. AMOS (04:29): It's a small price to pay because you could drive to Atlanta. You're not that far. Right. Except for, except for when you get in on the plane in Chattanooga, I'm sure that your, your line at TSA is way shorter. CHRIS (04:41): Like the TSA agents in Chattanooga know me. And I literally just walk in there. I, and I'm like, all right, Hey, what's up Alex? What's up Bob? And then I like put my bag on the thing. They just like send me through. And I just go, I can literally show up to the airport. My car can arrive at the airport at the time at which I'm supposed to be a boarding and I can make it onto my flight with my correct zone and the whole thing. AMOS (05:06): Sweet. It sounds like Kansas city airport. The average wait, time insecurity is three minutes. ANNA (05:11): That's awesome. CHRIS (05:12): Kansas city is a weird airport though, too. Can we all agree that Kansas city is a really weird airport? ANNA (05:17): I've ever been to the Kansas city airport. CHRIS (05:19): It's like, okay. So it's like a big ring, right? It's, it never got renovated after 9/11, like in when security changed. So like it clearly was made so that you could just like walk up to the Gates and like wait for your people. Or like walk with people to the Gates. But then like post security changes, they just put walls up. AMOS (05:41): They don't go to the ceiling either. They're like halfway walls. CHRIS (05:44): You literally just like put like walls so that they could that they could like separate that stuff. And so everything is very narrow and security just like runs along the side of these walls around this ring. But the whole thing is probably like 50 feet wide. Like it's like this, it's a super narrow space to like cram everybody in there. It's very weird. AMOS (06:03): And the multiple terminals are all really small too. So you can actually get dropped off at some doors, walk into the doors and you're standing in the security line when you get through the doors and then you walk on the other side and you either go left three Gates or right three Gates in there. That's it. There's nothing. ANNA (06:21): That's awesome. That is not the case in San Francisco. AMOS (06:24): No, they they've talked about redoing the airport. And I really hope that never gets voted in because they'll probably move to a central TSA group instead of having everything all spread out. So it'll be a lot slower. CHRIS (06:38): Leaving Chattanooga is great. ANNA (06:39): No, it's awesome. Getting, I mean, getting into Chattanooga like that airport is awesome. I like that. I can just get in there half an hour before my flight. Yeah. CHRIS (06:46): There's exactly four Gates. You can walk up in there, find your gate immediately, go grab a coffee, sit down. Then you're on the plane and you're ready to go up. And it's only like 20 minutes to get to Atlanta. And then, you know, so it's not that bad. AMOS (06:56): Do I get to walk downstairs when I get there? CHRIS (06:58): There are some stairs that you walk down, yes. AMOS (07:00): There's also a display of sponges. CHRIS (07:03): Yeah. You have to stop at the world. Famous sponge display in the Chattanooga airport. It's we're actually renowned for it. ANNA (07:11): I'm not kidding. CHRIS (07:12): Oh no. This is not a joke. This isn't a bit, there's literally a display of sponges at the Chattanooga airport and you have to stop and examine it for a little. AMOS (07:21): So sponge display, friend of the show. CHRIS (07:25): I mean, I don't know that we could dine to sit at that table, with the sponge display. It might be more famous than us. AMOS (07:33): Are these like kitchen sponges? Or like sea sponges? CHRIS (07:37): No, no, no. Like kitchen sponges. One of the major exports of Chattanooga. It turns out. AMOS (07:41): Kitchen sponges. CHRIS (07:43): Yeah. It's that and pretty good rock climbing and broke hippies. Those are our main, those are our main exports. AMOS (07:51): Did you get broke hippies when you fall off the wall at rock climbing? AMOS (07:55): Never. Never mind. ANNA (07:58): Got it. Got it. I got the joke. AMOS (08:00): No. When you said broke hippies at first actually the picture that went into my head was people with broken hips. And then I was like, Oh, he means like, like the people we've had lots of discussions in the back end, but do, do we want to say anything else about strange loop? CHRIS (08:15): It was really good. I don't know. There's nothing else to say other than like, the quality of talks is unlike any other conference I've been to. ANNA (08:22): I agree. I agree. CHRIS (08:23): There's a lot of conferences where you swing and miss on a lot of talks. Stranger is really not one of those conferences. AMOS (08:29): It's are hard to get a miss there. Yeah. ANNA (08:31): The weirder, the talk the better, the talk I've found. AMOS (08:35): True. Yeah. Alex, Mario, crystal. I don't remember who else is involved over there. They do a really great job of picking people to talk. CHRIS (08:43): Yeah, they're very intentional. They're very active in seeking out... ANNA (08:47): Crystal gave an amazing talk at a Women Who Code conference. I was just at. AMOS (08:52): Crystal Martin. Friend of the show. What conference? ANNA (08:56): Women who code. AMOS (08:57): Oh yeah. Where was that? ANNA (08:58): In New York. AMOS (08:59): Did you say all this while I was trying to get friend of the show out? ANNA (09:04): Oh, I don't know, maybe. AMOS (09:05): She's also getting ready to speak in Hawaii. Sometime she's come a long way. She was a school teacher, a math teacher at an inner city school in St. Louis. She, she has, has pushed the community and herself. She's an amazing, amazing woman. She's fantastic. And always has the best hair. ANNA (09:27): Yeah. And the best outfit. AMOS (09:29): Yes. ANNA (09:30): Anyway. So what do y'all want to talk about today? CHRIS (09:32): Can we keep, just, can we just talk about Strange Loop more? AMOS (09:36): Well, I'll throw out a few, a few white papers from the Erling ICFP that I thought were really good. Um, there's understanding formal specifications through good examples from a whole bunch of people, uh, including John Hughes, where he's talking about, you know, you can generate these tests and the examples that come out aren't necessarily great. And sometimes it's really good to have, uh, well, they're good, but they, you might need more examples than what it takes to get a hundred percent code coverage for a human being to understand them. So there's, there's a really good paper on coming up with examples for humans, kind of, I really enjoyed the talk and their videos should be up online. I'll see if I can find a link for the show notes and I will definitely link to papers. And there's a typing in the wild in Erlang, which has also John Hughes. And I am totally going to mess this guy's name up, uh, - he's, uh, at Chalmers university there with John Hughes. And they're, they're talking about, um, what is it, the hit Hindley Miller Henley Milner. There you go - type system in Erling and, and you know, some of the things that they can do to improve typing in Erling, but they also talk about how you add types and you lose some flexibility. So you lose flexibility, but you get some better guarantees. And that, you know, just because the type system makes you add a function or a case clause or some types doesn't necessarily mean that you're, you will get a runtime error. Um, and that's kind of the trade-off with, uh, with dialyzer and costs his approach. And there was another one from Joe Harrison. It, I tried to print it off. Uh, it will end up in the show notes that was also about typing, but being able to use types to make sure that your like, received blocks are handling every possible message that you could receive. So that, that would be really cool to, it could be able to get errors beforehand saying, you know, like you meant to type people and you typed to poeple for the atom at the beginning of your message. And so it'll tell you, Hey, you're not handling this message and maybe help you fix some problems before you end up in production. So yeah, it was good. And if you can go to an ICFP I would go, it was about 30 people in the room, and I felt like the dumbest guy in the room, which is a fantastic place to be. CHRIS (11:51): Insane confunctional posse. AMOS (11:56): Actually, John did have his face painted black and white like that. Oh, I, I hear, I hear kids. Do we need to go to parenting talk now CHRIS (12:06): I'm trying to think of a monad monoyed class, uh, category theory, pun with jugglo at the moment. Come back to me, come back to me in 10 minutes. I'll have something ready for you. AMOS (12:20): I am not good at jokes. CHRIS (12:22): I'll say. AMOS (12:24): Chris, Chris has been putting up with them all last week. He, every time I say something and he just rolls his eyes, he's like, man, he, you need to stop the comedy. Maybe I should take some comedy classes. ANNA (12:35): Yeah. Why not? CHRIS (12:39): I'm not going to tell you not to do that. ANNA (12:40): But maybe don't quit your day job. AMOS (12:45): So that's all I had to say about strange loop and, and all the busy-ness around that. ANNA (12:52): Strange Loop is awesome. I wish there were more conferences that were like Stange Loop. Are we just gonna dance around ecto and not talk about it. AMOS (12:57): Or design. Do we want to talk about ecto or just general design? ANNA (13:03): Keathley's gearing up to... CHRIS (13:06): I'm legitimately weighing the consequences of where that road could, could take us. ANNA (13:11): Let's not do it then if you're worried about it. I mean, it's CHRIS (13:14): The fact that it makes me worried about it is like, is what's actually me off. We had a discussion about this strange loop, actually. Like when it comes to like that, I don't like being bullied and don't only being pushed. So like my inclination when I'm, when people push me is to push back and I'm trying to temper that. And I don't like that. I don't feel, I'm trying to figure out how I feel about the balance between like constructive discourse and not being allowed to say not, not feeling allowed to say the things that I want to say for fear of repercussion and trying to figure out like where that line is. I don't want to justify being like, I should have, like, I can say whatever I want. You can't do that without repercussion. Right. But at the same time, like I'm just frustrated. Um, AMOS (13:56): I think we can talk about technology. I just think, uh, leave words like stupid and dumb. CHRIS (14:01): I haven't used those words to describe... AMOS (14:01): I'm not saying, I'm not saying you have through history of, of working with groups of people. Sometimes you, you have that come up and it's like, well, that's not helpful, but I think it's okay to talk about, I mean, so design wise, I, I can kind of start this because I was one of the people that really would like to have changed sets, not have to be connected to SQL. CHRIS (14:28): Do you want to do wait, do we do, do you want to like actually lead in and explain, ANNA (14:31): Oh yeah, let's do the thing that we always say we're going to do. AMOS (14:33): What's that Chris and Anna? ANNA (14:35): Explain the thing before we talk about it, like explain what change sets are for folks listening, CHRIS (14:39): Explain even like what's happening right now. ANNA (14:41): What's happening with Ecto. Yeah. AMOS (14:45): Uh, Ecto is, is being split into two parts. They're pulling out Ecto from ecto sequel and ecto sequel is really kind of the, exactly how to talk to SQL databases. But the kind of weird thing about that for me is that I realized the ecto queries are still going to be in main ecto, which are very sequel oriented. So I don't see them applying to other databases or being generalized that well. So that, that was the thing that kind of threw me for a loop. So I'm portive of the direction. I don't know about you guys, but I am a little confused as why queries didn't end up in ecto SQL. CHRIS (15:27): I have a bunch of thoughts. Some of which like require a lot of context, some of which are, I don't know, like require less. I mean, AMOS (15:36): Oh, well, some people are driving while they're listening, so let's keep it shallow. CHRIS (15:42): No. AMOS (15:45): Can we start with the ones that don't require a lot of context or do they all..? CHRIS (15:49): I think there's a bigger piece of this for me, which is thinking about what constitutes like good design. That's like, that's like the wrong way to say it. Right? Like good and good and bad. Aren't like tangible things, but thinking about ways of reducing complexity, right? Well, that's really what design is about. It's about like pulling apart the things that can be pulled apart, putting together the things that ought to be together in order to reduce overall complexity, uh, in a, in a given system. AMOS (16:14): Now. Now why D- why do you want to pull them apart? What does reducing complexity do for you as a developer? CHRIS (16:18): I mean, I think we should define terms here. And because I have been reading a philosophy of software designer just finished reading philosophy of software design, which by the way, is the only book on programming design that I've ever read that I thought was worth a darn. AMOS (16:35): We weren't allowed to bring up other books until Anna and I both finished purely functional data structures. CHRIS (16:40): It's months you've had months. AMOS (16:45): How about you, Anna? Have you finished that book yet? ANNA (16:47): No, no, mostly because I've been doing so much conference travel once this is over, I'll have some more time. AMOS (16:52): You are way better at excuses than I am. I'm like, uh, I'm dumb. That's why. CHRIS (16:59): This book is really, really good. And I think it pushes back on a lot of the stuff that you hear touted as like being good design in ways that I find incredibly convincing. Now, as a practitioner, who's been doing this for a bit, you should read the book, I'm going to probably not explain all the things as well as the book will explain them. And he provides, you know, chapters to sort of back up the claims that he's making. And it's really, really well-written and really good. So one of the things though that he leads off with is this notion of overall complexity, like the complexity of a system is derived by, uh, saying it's the, it's the sum of all of the individual pieces of complexity multiplied by the, like the number of times you actually have to interact with it. So hiding a thing so that, to where you never to interact with it is as good as eliminating that complexity by that definition, by that sort of mathematical definition. Is that fair to say? ANNA (17:56): Yes. CHRIS (17:57): And I think that that's like a really useful, um, metric to sort of look at how you build things. And what do you effectively advocates for throughout a lot of the book is this notion of, um, creating deep modules versus creating shallow modules. He provides a lot of, a lot better explanation than I'm about to provide, but, you know, generally a deep module is one that has a very small interface, but provides a lot of power, like a relative, a relatively large amount of power for its interface. A shallow module is one in which you have a relatively complex interface or large interface that provides very limited power. AMOS (18:38): Is there a good, um, like concrete example that you can give of, of some modules - you can make up an example. CHRIS (18:45): I'll use the one from the book I'll use the, I'll just use the ones from the book, because I was trying to think of one, like what would be a good one. I've had this, these discussions so far about elixir things and examples that I think are good and bad, but I'll refrain from that. And just use the one from the book. And the one he uses in the book is, um, like interacting with files in Java - in order to do interact, like in order to read a file in Java, you first need to create a file object and then you need to like pass it to an IO reader object. And then in order to buffer that, so it doesn't just like read the entire file into memory all at once. You have to wrap that in a buffered IO reader object, you know, those are all decorators on top of the file object. Um, they're small, tiny classes, tiny little decorator classes that go over the top that do a thing. And his argument is that all of those are shallow. Those are incredibly shallow interfaces and provide limited power on their own and only serve to make the interface more complicated, like as opposed to just making buffered file reading the default because buffered file reading is probably what you actually want to do 90 something percent of the time. There's very, for, for all practical purposes, you probably want to do buffered file reading. And so that should just be the default, just make the interface, read files in buffers. And if you want to get out of that, then you have to actually drop to a layer below the thing instead of like jumping through these hoops to build multiple decorators on top of the thing, because now you have to hold in your head, what are all the decorators? How do I find the decorators? Where are they documented? How do they work? Like you have to like go and examine all those things. And so he sort of pushes back on this idea that I think was really popular that I've seen demonstrated a lot coming out of like, OO stuff. But I think applies to functional programming, specifically elixir since, you know, people treat it like an old language in a lot of ways. There's this notion that there's a sort of class-itis as he calls it, right? There's this notion that many small classes is better than one large big class. And I think that that's a reductionist argument because one large, big class that does one thing like that has a very small interface and effectively does one very complicated or like powerful thing. But hides that from you. That's really, really good. What you actually don't want to do is have like tiny things all interact with the same stuff. So like a good example of this is, um, this is probably like controversial, but like, I would say like a really good interface for this is, is Mobius. Mobius is a way to talk to Postgres. Its only job is to talk to Postgres. It only supports Postgres and it is a pretty, relatively small interface for composing queries and then a singular function that you call that is like execute and it runs the query and that's its only job. It doesn't do anything else. It returns you errors. It tells you that stuff worked or didn't work. It doesn't do any other sort of things on top of composing queries and executing. Mobius executes queries. That's that's, that's what it does. It executes queries. And that to me is a very, very powerful interface. Like that's doing a very large thing, which is like talk to the database, uh, make sure that like stuff gets executed, bring you back results, execute results, compose queries together. Like that's a, that's a, that's a lot of power in a relatively small interface. So like I would refer to that as like a very deep module, which is kind of exactly what you want. You wouldn't want to interact with like 10 different APIs just to compose queries together, to execute with Moebius that's that's not helpful. Th th th that to me is a good example of something that's like very deep. And his argument is basically that you actually want things to be very deep, which pushes back against a lot of the, just like rules of thumb that we give people, which is like have small methods and methods should never be more than in number of lines long, you know, or you should, you know, every class should fit on like one page in them. Or like, I dunno, like they, people give these like stupid heuristics, which are sort of arbitrary and probably like helped to try to shape people's understanding, but they're not doing it in a way that's like actually addressing the underlying problem about handling complexity. So he also pushes back against the notion of like small methods or small functions. He's like, that's bad. If what you've done is decode like break these things arbitrarily. If you just have to now go look at like 10 different functions to figure out how this one thing works. That's actually like a less good design. You break things up in order to be readable. And he provides like a bunch of other more concrete heuristics about how to do that all in the service of like reducing overall complexity and the backstory to all this too, is he actually did all this stuff with, for, for years in a class at Stanford. I think it was at Stanford. I might be getting that wrong, but he, he, he, you know, effectively ran this class with a bunch of students, went through all these principles and like all this design stuff is based on his own experience, working as a practitioner and then working as an academic and also, uh, with his students, helping them guide, guide them through designs in like teams, um, and, and finding things that like empowered those teams to work better and remove complexity. AMOS (23:47): So a lot of the, the rules that you're talking about, function size a number of arguments to a function, whatever those things. So I, I agree with him that it's very arbitrary and probably doesn't lead to the right thing if you don't know what you're doing, but I see so many new developers come in and write functions that are a thousand lines of code and four levels, deep of case statements inside. And they just keep piling more and more and more into this function. And so they, they're not seeing those things. So I think that the, the rules unfortunately, are taken as this hard and fast - This is the way it is and the way it has to be. But I think they're good general guidelines to think about. CHRIS (24:27): I think they can be helpful, but I, I don't, I think that the problem with giving people those sorts of like rubrics of like, Oh, if it starts to go over three lines of code than it needs to be a new method like that doesn't actually make anybody better because it's not teaching people how to do that. Like the, now they're just, it's sort of like, linters right. Like the goal of the, if you have a problem with the linter, your goal becomes like, how do I make the linter happy? Not how do I like fundamentally rethink this design? I see people do things that are like, Oh, you're passing five arguments to a function that's wrong. And then they literally wrapped it in a tuple. ANNA (25:01): I mean, is it, isn't the idea there though that with these rules and I agree that it's not taking them as like for, at face value and harden fast is not really helping anybody. And maybe the part of the problem is that, do you take those rules a little bit at face value? And then at the point of them seems to be to step back and be like, wait, what am I actually trying to accomplish here? AMOS (25:20): Yeah. And I think a lot of these rules that, that you see around like that, that are very simplified actually come from Sandy Metz, but she didn't originally give out rules. She didn't want to, people pushed her and pushed her. And she said, okay, here's, here's some four good general guidelines. But then one of them says, you know, like all these aren't really hard and fast rules. These are meant to be broken whenever you understand why. And whenever you convince somebody and so adding a linter that does these rules and then telling everybody, Oh, you have to pass. That is, is bad too. ANNA (25:54): It goes back. That goes back to the accepting of a thing, rather than the thinking about why you're doing that thing in the first place, right? Like, Oh, it's through these things, these are the right things to do, as opposed to like, wait, what are we trying? How are we trying to design our system? Or what are we trying to accomplish? Right. Like, and why are we using these tools to help us accomplish that? AMOS (26:13): And I think the why is, is the important part for every person and every team to answer. Because for me, the reason why I appreciate those rules is because there are so many junior developers out there who rate their productivity, their how good they are based on how much they type and how often they're typing. And a lot of these rules slow them down and force them to think, and I wish they would rate their productivity more on how much they're thinking. And, and instead of how their fingers are touching the keyboard, ANNA (26:45): I wish that was a paradigm shift period. And I think there are, I mean, like, especially when you're starting out, right, like that good software development is probably what, like 90% is thinking, right. CHRIS (26:53): Oh, an incorrect opinion. But I, I can't help, but feel like a lot of those rubrics about like, you know, method length or arguments or whatever, like STEM almost entirely out of incomplete failure to provide, tutilage, to people and to like, provide like a cult, like a lack of mentorship, culture, and lack of like trying to pair less experienced people with, with patient teachers or whatever. Like, I don't know. Like, I feel like that comes out of like, sort of this like cop-out of, well, we don't have to teach you as long as you would just like give you these rules. And then I don't have to like, look over your shoulder anymore. I don't know. Like, I, I feel like there's a, there's a place, everyone to provide mentorship for everyone, if that makes any sense. And in that way, you, you learn via those interactions with people, you would learn like this isn't a good design because I don't understand that. And I'm sitting here with you as opposed to like, we sat here together and we worked through this design and this is how we, you know, this is what came out of it. I feel like these rubrics are like, they're like a poor substitute for that. ANNA (27:51): I agree. I mean, I think, but that's on a larger scale, right? Talking about how we choose to communicate as we're developing software, right? Like these rooms, it's like an attempt to make that a little bit more, not asynchronous, but to make that, so that exactly is that you don't necessarily have to have as much continuous interaction and communication. Right. You can just give points to somebody instead of rules and say, Hey, keep these in mind. Um, or a linter right. CHRIS (28:16): There was a talk, which I won't say the name of, or what it was about, but there was, there was one talk at strange loop where the person was like, Oh yeah, we use our linters to lock down entire subsets of this language so that, you know, our developers can't use those parts of the language and like giggled about it. And he's like, those things are great because with the subtext of like, developers are stupid, our developers are stupid and left to their own. Uh, we know better, and we can protect them from themselves if they don't do these things. Or like, I mean, maybe this upticks is developers are too clever by half and won't, and we'll do these things left to their own devices, but we've stopped them. Isn't that great. We've made our lives better. And I was just like, I was so offended. Like I was so deeply offended by that, by that, by that statement. AMOS (29:03): Although it's still, it sounds very reminiscent of the type argument from many friends in the Haskell community is you're stupid. So you need these types to constrain you and put you in. CHRIS (29:17): I was, I was just deeply offended by that, like, uh, this notion that like this select group of three people knows better than the rest of the hundreds of developers at their company. ANNA (29:29): Yeah. And this all comes back to like, what does this say about how we as a discipline and a group of practitioners communicate, right? Because to me it's like, this is like a symptom of poor transparency and communication. Right. And rather than if somebody isn't understanding, figuring out why, maybe there's a reason for that understanding, Oh, a particular way of doing things. And instead of being like, we're just going to create these things because we don't think you can do this thing, having a conversation or having, you know, common dialogue around, um, reaching a common understanding that probably ultimately makes everybody better in the long run. Right. AMOS (30:06): But talking is hard. ANNA (30:07): I've been thinking about this a lot lately. I think I can give a talk along these lines so far. CHRIS (30:12): I think the other hard part is like, you have to cater these things to whatever your team like is willing to tolerate. And every team's going to be different. Every team's going to have different needs. And that's also why these, these, like, this is why I've loved this book so much is because this book actually doesn't ever give you any sort of rules. Like, you know, when you see things like when they have four arguments, like start to pull them into multiple fun - and it doesn't do any of that, it's just like, here are ways to think about designing. Here are some of the common patterns that are wrong. That act that actively hurt you most of the time. And here's like a different way to think about designing systems. And that's like, what I've loved most about this, because that means you can adapt this to your team and your team's needs and what's going on in your company at that time. ANNA (30:55): Well, yeah, exactly. Right. And communicating that, right. Because when systems are complex, we say that are complex. And we mean that they're complex for humans, right? Like the computer is just going to do whatever the computer you're telling the computer to do. Right. The complex for our human understanding. And so why is that happening? And again, when people are in a vacuum where people are thinking, well, I know the answers and other people don't have the answers, so I'm just gonna do this thing. And it makes sense, but it actually doesn't right. Like I really do think it comes back to this like interface, it's human communication that we are all not great at. Right? CHRIS (31:23): Yeah. No, I think that's true. Well, and the other really galling thing is like, this has been coming up so many times in so many recent discussions, I've had recently about our, about our community. And I just there's Rich Hickey has this quote. He was talking about this, that I don't remember what talk it is. I'll find it though. And I'll post it in the show notes with a timestamp at the point at which he makes this quote, but he just says, he's like, programmers know the benefits of everything and the trade-offs of nothing. And I just, that resonates with me so, so much because he's basically just saying, like, we always can find and look at the Hutton, the new thing, and figure out like, Oh, that's going to be better because it has all these benefits and we never, ever stopped to think about what is it that we're trading off when we do that? Like, what is it that we're losing when we do those things? And, or like, you know, we install some new package or we make these design decisions and all that stuff is inward. Like we're so, we're, so self-focused as like an, as a community, like that's just programmers in general, like are so self, so focused on our own cells. We're just all like in these big groups, just like vibing on how cool we are and how like cool our abstractions are or whatever. And it's like, none of that fricking matters. Like your only job is to deliver value to the business that you're working for. And you deliver the most value by producing things. So the whole point of design and reducing complexity is so that you can continue producing things over a long haul. Cause otherwise you're providing no value. You're just an overpaid obstruction, like for doing this for, for providing value to this company or to human beings. Like it's such a, we're such, Oh, it makes me so mad. Like we're such spoiled brats, like about like, as like a community as like a, as like the greater like programmer you're like Zeit Geist is like a toddler. Who's just like, so in so infatuated with their own, like what, how does this make me feel? And I can't help, but feel like so many decisions get made that way. And because no one's actually willing to talk about or wants to talk about like the actual trade-offs that we're going to make and how we're going to choose to do things as a team and why we're going to choose to do them as a team. And like any of that stuff. Cause that's, what's hard. Sorry. I'm going to have to go. I'm going to go take a nap. I'm getting... ANNA (33:37): Yeah. I mean, but these are things, the interesting thing about it is, you know, developing software is always complex. This is not a new problem. Right. It's always challenging. And so I think I can see the attempt to try and create guidelines to make it easier. But at the same time, I think people want us interpreting sometimes, right? They're like, Oh, this is what we should do. As opposed to like, wait, these are supposed to help us think about why we're doing things. AMOS (34:00): Yeah. And everything that you, I almost said, well, actually, and I wasn't trying to correct you. Chris is rubbing off on me. ANNA (34:10): Chris doesn't say, well, actually, AMOS (34:13): Actually, no. Uh, the, uh, now, now I forgot where I was going. I sidetrack myself with that. So all these rules are, are, there's so many nuances around those rules that if you actually apply them, how they're supposed to be applied, then you're not going to use them constantly. And you're going to be thinking a lot, but it's just like writing laws, looking at, look at any law that's written, there are so many words and pages to try to give all of those nuances in a law that there's no way that they're going to get all of that into a digestible form. Otherwise we'd have to have a second degree on top of it just to read how to design software. Right. CHRIS (34:49): I think of it like board game rules, like if you've played like nerdy, like Euro games, a lot of times there'll be some sort of re like statement in the rules where they're basically like, our intention is for you to do this, but we can't actually be there and police you. And if we just come up with a bunch of rules, like that's how we, we encourage people to find ways around them. So our intention is for you to do this. And that actually tends to work out like people like actually self police pretty well in most scenarios. Um, especially with like small groups of people, they self police reasonable well. AMOS (35:19): Yeah. And well, and a lot of those, those nerdy games, I think run into the same problem that we're talking about, their youth, you read a whole gigantic book sometimes and you get down to the end of it. And you're like, they could have written this in two little paragraphs, but it's because they're trying to eliminate some of that nuance, but they know that they're not going to get it all. So then they add that little statement that you said in there, or like a love letter has something in there too about, you know, there there's, there's some card that if you have it and somebody plays something, or if you draw another card, you can't have the two of them. So you must discard the other one. I don't remember what it is. But then at the end of it, it says, you know, uh, where basically that you're on your own accord to actually discard, like you're supposed to, since nobody actually knows what's in your hand. And then it says, don't play with cheaters. CHRIS (36:13): Cause they can't no, one's there to police you, you can't, you know, and that's, that's what you're left with. You're left with like, you know, this sort of like, you know, general intention and they just state what they want you to kind of do. And then explain like, look like if you don't do this, you'll, you'll invalidate the game. And it probably, won't be very fun. Our intention is for you to do this. So please just do that. So like that's the context. I mean, part of it is like, my brain is sort of poisoned by this book because it's really, really good. That's the lens through which I'm looking at a lot of these decisions happening right now. The thing that is most jarring about the ecto stuff for me is not that they like extracted sequel I get the steps that they walked down to decide that that was a thing that they wanted to do. The thing that's jarring to me is that people is that the use case that most people want from ecto is such, is so different than my own. Like it was legitimately surprising to discover that what people actually wanted was all the things that weren't databases like the thing that people want is like change sets and queries on arbitrary data, on like any arbitrary data structure, you know, or like talking to, it's not like, uh, you know, someone posted a, um, like an example of repo where they've got ecto talking to GitHub. And so like, you can use ecto with GitHub now. And it's like, I just, it never occurred to me that that was the part of Ecto that people wanted or liked. That's just such a surprising thing to me because those are the parts that I like least about ecto. Those are the parts that I want least in Ecto personally. I mean, for me, like for the things that I have to do, like those are the parts that get in my way most, most of the time. And it's because it's because those are very shallow abstractions. Those are very, very shallow abstractions. They add a lot, they have a very wide interface. They have a very, very wide interface, you know, change that specifically has a super wide interface, like going all the way down into the database. Occasionally - like it has, it knows stuff about the database. Like, you know, whether it's implicit or explicit, like it has functions in there that are like validate constraint, right. That comes right out of relational databases. Not all databases have constraints turns out, you know, but like that, that knows about deep things about the database. So it's this sort of like weird bifurcation, right? And they even said this in the issue that when they attempted to remove the pieces of Ecto, that didn't care about databases out, there was basically nothing left. So it wasn't worth splitting. Like, and again, because those would be super, super shallow because they'd provide very limited benefit over the top of the part, the actual real power, which is sending a querey, into the database and doing stuff with it. Right. AMOS (38:37): I personally ran into this. Like I haven't used ecto directly in a little while, but I liked the ability to use change sets outside of a database for validation and some of the steps that they go through. And to me, I would like to see an interface where you can add those like constraint validations to chain sets, because most of my validations aren't database constraints, right. They aren't checking for does, does this user, that this thing belongs to exist in the database already? There's no, I'm not checking foreign key constraints. I'm checking very basic data constraints. Does it have the format that I expect? Is it an integer? Is it a string? Is it all of this? And what I like about change sets is whether I'm talking to a database or get hub or assets or whatever, it gives me a common interface that my front end can use across all of that. Like, I deal with errors. I deal with inputting data. I don't even need to use the change set to write to the, to any sort of data store, but just the validating data, what a, uh, an entity looks like in my system and what the errors look like in that are all the same simply. And so I would rather see some kind of extension point in, um, change sets that say, Hey, if I need a constraint validation, we have this other extension that we add in, which is why I'm confused at why more SQL stuff wasn't pushed down or change sets just pulled out. That was my original was just pull out change that's cause that's all I want. CHRIS (40:03): I think that the core problem there is those things aren't nearly as inseparable as everybody believes that they are those, those, I just think fundamentally those things are really intertwined together and whatever uses people have are using ecto for, I mean, if you can make it work and it works for your team, it doesn't add a lot of complexity and you are comfortable tying yourself to a framework and being beholden to learning a lot about that framework and want the majority of the things that it's giving you. I mean, sure. That's fine. Use that. I mean, that's, that's cool. Like that's good for you. I don't know. I just, I don't feel like those things are probably as inseparable as people think that they are. I don't know that this helps the majority of people. Like, I don't think this made people's lives better. Like, I don't think that this is going to like reduce overall complexity for most humans, maybe. I mean, but clearly like, I mean, and tacitly I'm wrong because, and as many as all of you have, let me know I'm wrong. Thank you, Twitter. Do you don't have to let me, you don't have to let me know any more. I know I'm wrong. It's good. I've got the, I got the memo. So on in all of the venues, in which you have, let me know I'm wrong. That was also useful. I get it. People want to use this for other stuff. I don't, I don't understand that desire just fundamentally don't understand that desire. And that's probably a taste thing. Like I am not predisposed to try to shoehorn all of my use cases into a given library or way of thinking about things. As I do think at the end of the day, that is what you do is you shoehorn just mash your problem until it looks like the shape that this other thing that will fit into this other thing. AMOS (41:35): Cause you've - you've already invested time in that other things. So it feels easier sometimes to mash things in then to try to find another solution. CHRIS (41:42): Yeah. Yeah. I guess, I guess that's, I guess that's like the road that people walk down or maybe people just are really uncomfortable passing maps to functions and then validating these values inside keys. I don't know. I don't know. I don't know. I don't get it. It doesn't make any sense to me, but like, that's obviously I'm wrong and I appreciate everybody, um, letting me know. But in any case, like I think if you look at it from the, from the, through the lens of like deep, the, this, this notion, right. Of like deep modules from the shallow modules, it, it really starts to make a lot of sense. ANNA (42:10): Amos, we'll have to read this book so that we can talk about that. AMOS (42:13): I already ordered it while we've been on the podcast. CHRIS (42:17): But like, like the, the query query and repo are actually a relatively deep, they're a relatively deep module, like taken together, you know, uh, repo actually is if you can, if you, you could actually eliminate a lot of stuff from repo in order to make it like deeper in order to make it less wide. Like there's a lot of functions on, there's a lot of stuff. There's a lot of interface functions to repo that you actually don't need. If, what you're, if you're using just queries, like if you just use queries and you just use repo, you, you don't need almost any of the other interface functions to repo at all. You could get away with, with like one or two. So, but like, but you know, as far as ecto is concerned, like those are the deep modules there. Those are the things that like, let you do useful stuff. And then the rest of it is like very, very shallow on top of that. And it's not actually layered really on top of it. And in like a way that's like easily separable. Um, which also, I think is probably part of the reason that they had trouble splitting out anything, but the SQL bits. But, and I don't know, I just can't help, but feel like this, that sort of design methodology of like, well, what is good is smaller things. That's like what we're running with at this point, you know? And it's, and it's not, it doesn't, is it using this other framework it's using this framework of like, what makes things good - Well designed is smaller things. And then you end up with the Java file reading API, you know what I mean? Like you do that to the nth degree and you get the job without reading API also as a side note, after this happens, which has already happened. So, I mean, this is all moot, my opinion on it doesn't matter. Like, but, and I'm wrong anyway. So, but like, but now that it's happened, I don't ever want to hear another elixir person ever complained about the node package ecosystem ever again, because this is exactly that, like, this is the exact same thing. ANNA (43:59): Amos, let's read this book so we can have a discussion about it. AMOS (44:01): I feel differently, Chris. CHRIS (44:02): Uh, that's fine. That's fine. AMOS (44:04): Well look at the bright side. The deep parts are now all in one repo that you can just use that one and you don't have to have all that shallow stuff CHRIS (44:14): You can't though. You still, yeah, AMOS (44:16): No, actually the deep repo depends on the shallow one. So there you go. Yeah, you have, CHRIS (44:20): So you have to bring it all in there. So I don't know, whatever, like, I mean, it's fine. It's done it's it happened like this is our lives, you know, so, and it's good. Everybody else likes it. So it must be, it must be good. AMOS (44:32): I think you need to see where it goes and maybe see what some people are doing. Find out people who are going to get into using ecto and not Ecto SQL and see what they're doing with it. CHRIS (44:42): I think there's this notion that like, there was a, there was somebody asked on that issue like, Oh, does that mean that the queries are not going to work for things that aren't SQL? And the answer is like, no, not yet. Maybe, maybe eventually. And it's like, okay, well, I don't know, like, this is a weird split, but I mean, cause I think that there's a desire to like turn ecto query into link. Have you, have you either y'all use link from like C-sharp AMOS (45:02): I have not, but I've heard so many things about it. Link - it's monads right? CHRIS (45:09): That's - yes. Um, link is, uh, a way to interact with any arbitrary data structure. Basically you write something that is pretty analogous to the way that ecto queries are written similar. It's not exactly the same thing, but it's similar. And you can use them on anything that like implements a given interface on any data structure that implements an interface. You can use the entirety of link against it. And at one point they, I don't think it's as used anymore, but they had a thing called link to SQL. And if I remember correctly, I'm probably getting the history of this wrong. But I think like EMJ based the syntax for, for ecto queries off of link and the, and the way that that, that was working, I think there's, there's some sort of lineage there, but one of the benefits that link has, and one of the things that ecto doesn't have going for it is that link is built into .net. Like you can just use it, like you don't need to install anything or like bring a package in. And that means it works with like all of the default data structures out of the box. The interface is just like built in. It's just like built into the language. So it would be somewhat equivalent to like, if you had Ecto query syntax, just in elixir and it worked with anything that implemented a numerable like, that would be the equivalent, but it's much harder to do that. If you have to bring a thing in from the outside world and like install it, right? Like it's much harder to build something that's sort of pervasive. And that provides like this like generic pervasive access across all data structures. If it's a package that you have to install. AMOS (46:35): That's, that's a fair assessment, but I don't know, working in the embedded world has changed me a little bit too, because I'm very constrained on resources and things like that. So splitting packages up as small as they can so that I can pick and choose. But I still, you know, I need something useful. It's not worth pulling in a package if it's so small that I got to get 60 of them to get what I need. CHRIS (46:56): Right. I mean, that's the power part of it. Like you don't want left pad. Like that's not what you, that's not where you want to end up. You don't want to end up with like a single function that does a single thing. You want a single function that does something very, very powerful. That's how you have a good that's where you end up with really good design. AMOS (47:12): So Anna and I are going to read this book. CHRIS (47:15): You should read the book. AMOS (47:15): Like the last book we talked about. CHRIS (47:17): It's really good. It helped me frame. It helped me one, correct. A lot of like assumptions that I had made that were definitely wrong. And it helped me frame a lot of things that I felt like that were true, but couldn't put into words. Um, and he taps into all that sort of stuff. And I think it's really, really useful as a book because of that. And I mean, Ecto is fine. It's every, everybody else wants this. It's just, I'm the, I'm literally the only person who, who is like, who doesn't get it, but so I'm the one who's wrong. So no, no one needs to let me know. I get it. You've all. Let me know already anyone who's left, don't feel like you need to say anything. ANNA (47:53): All right. Yeah. I actually have to run. All right. Sorry to end it on that note. AMOS (47:56): I look forward to here. You talked about putting together a talk about kind of these rules and dealing with that on a team. I would love to hear more about that. Anna, next time. ANNA (48:05): We'll see. And early thoughts around mostly around communication as we built larger systems in general. But yeah, I'd love to chat about that more as I have more formed thoughts ANNA (48:14): Soon, we'll see you all at gig city, which as of today, I believe there are still a few tickets left. Not a lot. AMOS (48:21): It's like 15 tickets left. ANNA (48:22): So yeah, by the time you get this next Thursday, there may be zero, but you should try anyway. CHRIS (48:28): Yeah, we can't predict anything. ANNA (48:30): All right. Cool. Thanks. Y'all thanks guys. AMOS (48:33): Have a great day. ANNA (48:34): You too. Bye.