Chris Keathley
The Elixir Outlaws now have a Patreon. If you’re enjoying the show then please consider throwing a few bucks our way to help us pay for the costs for the show.
Episode Transcript
Amos: Welcome to Eixir Outlaws, the hallway track of the Elixir community.
Amos: Hello? Can you hear me?
Chris: Yeah.
Amos: So you got a coronavirus yet?
Chris: I don't think it's, you know what, I feel like I'm living in a post joking world. I actually think , I'm actually taking it slightly, like pretty seriously.
Amos: What?
Chris: And I feel like we ought to take it- I don't think it's a thing we should joke about. I do feel like it's a little bit, not a thing that we should joke about or make light of. It is like actually a huge deal.
Amos: I agree with you.
Chris: I don't have a take on this that is funny. So like, we'd be really plumbing the depths of, of just not funniness.
Amos: Uh, I have, I have a joke about it, but I won't tell it cause it's a little dark. I'm horrible.
Chris: I mean, that's the thing is like, I don't, I I'm, I'm really over the takes of like, I'm really over takes. I'm really over just, just people and, and their silly opinions on stuff.
Amos: Understandable.
Chris: And I find this is like a serious thing and, and like an over joke, like joking about it a lot is makes it easier to cope. And there are definitely like humor as a way to cope with things, for sure. And I, I respect that, but I also don't have, I don't have anything funny to say, because I feel like you'd have to not care about it, to be truly funny about it. And I do care about it. And so it's, I don't, you know what I mean? Like I don't, I don't have it. I don't have anything funny. This is a rough start. This is not a good start to the show.
Amos: Naw, I think it's okay. I mean, there are a lot of, a lot of people out there being affected by this. So I think it's okay to send our best wishes to everybody and hope that they're happy, healthy and safe.
Chris: Yeah. And, and just, you know, take care of each other y'all. Like, this is, this is not good. This is, this is, these are, this is not, uh, is not overplayed. People are not, uh, being alarmist. Like this is a serious thing. Like take care of each other. This isn't just going to go away, I guess is part of it. Any-who-
Amos: Like we got a good three months out of us that are going to be rough.
Chris: Yeah. I think minimum. Yeah. It's, it's, it's this, this is a serious business y'all. Any-who, how was Lone Star? You were sick the whole time.
Amos: I was sick the whole time.
Chris: Topical. Topical reference.
Amos: I have a little bit of a cough left. Yeah. Uh, so the live episode's funny, they, they took a picture during the episode and tweeted it. And of course it's the picture where I'm, I have my head pointed straight up at the ceiling. Cause I'm like just trying to breathe and contain myself. It was pretty bad. Um,
Chris: Just holdin' it all together.
Amos: Yeah. Uh, shortly after that episode, I just went to my room and went to sleep, uh-
Chris: That seems good.
Amos: And dealt with fever for a couple of days. But, um, yeah, it was probably good for me to get out. I tried not to shake anybody's hand the whole time I was there. I kept poking my elbow out and like having people, not even fist bump, but like bump my elbow. But yeah, the, the conference was pretty awesome. There were some really good talks. Um, and the ones that I missed I'm, I'm looking forward to, to being able to watch them online. Um, I really wanna see, uh, Samuel Mullins talk on telemetry. I heard good things and uh, and I like Samuel he's from here in KC. So he's, he's got, I've said over and over- He has the best blog posts, but you have to like to read if you're going to read his blog posts. They're long, these blog posts.
Chris: They're uh, tomes.
Amos: Yes. Thoroughly researched. Yeah. Um, I appreciate that, you know, a lot of blog posts out there, including ones that I usually do they're like kind of just get the bare minimum out there.
Chris: I, um, just being honest, I'm not a very good writer. And so I keep my blog posts incredibly short because they already betray my sort of like, like how bad I am at writing. And if they go on for too long, then it's going to become very clear that I really have no idea what I'm, that I am a dog in a human suit, uh, typing on a computer and just like, I have no idea what I'm doing.
Amos: I like your blog posts. You always have really good images and stuff that help move that along.
Chris: Keynote. All keynote.
Amos: Keynote is beautiful.
Chris: It's really good. It's just like really good. I mean, if you're going to pick a tool, you know, it is a tool, it's a good tool. I like it.
Amos: So hopefully they'll, they'll take out all of our sniffles and coughs. I.
Chris: I mean, whatever it is just, this is the world we live in now.
Amos: Yep. That's true. I bet the two people that I have in my office today are really happy that I'm over here, coughing.
Chris: I'm sure. I mean, I'm sure they love it. Do they get like hazard pay for that?
Amos: Well, no.
Chris: Do you pay them at all? Do you just have them there for decoration? Like what's going on?
Amos: I have them here for decoration. One of them is, is the intern. So the intern gets paid.
Chris: It's like how, it's like how San Francisco consulting companies always have like giant open office spaces because when they bring clients there, they need those clients to understand that those people are working.
Amos: Right.
Chris: That's a major part of selling yourself as a consultancy is demonstrating that you do actually work.
Amos: Right. So that's what I do. I invite people who don't work at my company into my office so that when I take pictures, it looks like we're bigger and more busy than we are.
Chris: Yeah. You want to create the illusion of size and busy-ness.
Amos: Thanks Johnny, for being my illusion of size and busy-ness.
Chris: That's a, that's important. That's a key part of business is, uh, is marketing and brand.
Amos: Marketing and brand .
Chris: And brand.
Amos: Uh, so what's going on, you're in your, uh, Elixir world lately?
Chris: Um, I don't know, trying to think of any, if I'm doing anything interesting right now. I'm- I feel like I'm continually just, you know, working on metrics and working on more tracing stuff and working on tying libraries together. And it's like a lot of, uh, it's a lot of just busy, mechanical work. That's the sort of my thing I'm working on right now is just a lot of mechanical work. It's a lot of stuff that just needs to be done. I feel like I'm in a mode where I truly believe that if I just write enough code, I can solve some of these problems.
Amos: Nice.
Chris: Which may be delusional, the jury's out on that one. But, uh-
Amos: I think you're allowed to be delusional.
Chris: Yeah, I think so. I think I'm allowed to be whatever I want to be, but I think a lot of our, a lot of this stuff that we're dealing with right now for work is really like, uh, to, to use a topical phrase, uh, it's blocking and tackling, which I'm led to believe is not about police, but about football. Um, that's, that's what, as far as I understand. So.
Amos: That took me a moment.
Chris: Apparently that statement is a, has a lot to do with fundamentals. He's gotta get the fundamentals, right. And I think one of the downsides of being in a niche language, um, is that, you know, someone has to create that crap. And we take that for granted a lot. If you're coming from a lang-like a really like JavaScript or Ruby or something, something that has like a ton of people and in a long lineage, uh, you take for granted all the like little things that you just don't have to wire up, um, where we don't have that. We don't have that, right in Elixir. And so it's like, well, if you want something it's got to get done,
Amos: You've got to build it.
Chris: So you better go start forking libraries and submitting pull requests and hope maintainers want to accept it and hope that you can move some of this stuff forward and like, hope you can tie it all together. Like, um, so I've been doing a lot of that. I've been doing just like running around and adding little things to libraries.
Amos: What are some of those things that are, are block and tackle basics that, that you think libraries need to add? I got one. I mean, telemetry, observability stuff would be great in every library.
Chris: Yeah, that's a staple. I mean a lot of- well, and the real thing with telemetry right now is it's still just so up in the air about what events libraries should admit, um, how they should admit them, how they're going to play well with other things. And there's like ongoing discussions about this. None of which I have anywhere close to the emotional energy to get involved in. And so I just surround myself with people who are involved in that. And then when things aren't good, I complain to them or when I don't like a decision, I complain to them. But, I mean, with no hopes that it'll change. Just, just because I need to complain.
Amos: I tried to get somebody for you to complain to today. I tried to get Brian Negley on today, but, uh, he had, uh, observability working group meeting with the ERLEF.
Chris: See that's the thing is, they're there, complaining right now about stuff that I told them to complain about.
Amos: Well, hopefully, hopefully somebody fixes it then.
Chris: The main, I mean, it's not even, it's a thing that, like Brian said, this it's a thing that, uh, you know, a grand total of 10 people are ever going to see, including like the two of us. And so it's probably not gonna get changed.
Amos: Oh well.
Chris: Which is fine. And the thing is, is like, that's great. I mean, I don't expect, I, I don't really expect that all libraries in Elixir are going to have like already adopted telemetry and understand like what events they need to do, what events they need to admit and all that kind of stuff. Like, I'm not worried about that at all. That's just like part of being in this ecosystem. Uh, and I don't have any real problem adding that stuff, but it just means adding it and it's, and it is a little bit, like right now, like, you know, if I can just add it all, eventually all this stuff will just work.
Amos: Right. The third library that you added to, it starts to get a little tedious.
Chris: Yeah. But that's fine. It is what it is. And that's part of my role at BR these days is like making sure everybody else doesn't have to do this crap. And the fact that, you know, hopefully some of that trickles back out into the world. Um, isn't that good for everybody? Like I hope anyway. I hope it's good for, for all of the, you know, everybody else who's building systems. So that feels good. But a lot of it's just like, yeah, it's just generic, you know, tying together libraries. And none of it's like interesting in a problem solving kind of way. It's all just mechanical.
Amos: Yeah. Yes. It feels like the interesting problem of like telemetry and stuff has, has kind of been solved. And now, now it's just adding it everywhere.
Chris: Yeah. And then getting everybody to do it the same to some degree, because -
Amos: Oh, that's true.
Chris: It's not even the same, but you know, there are conventions that help consumers of telemetry events do things like add tracing at APM support, add, you know, whatever, whatever the case may be, right. Uh, and so it's just getting, it's like right now I'm working with, um, uh, Andrea to get, to add telemetry or to change the way that the Reddis, uh, Reddis adapter does telemetry events. Uh, and so, you know, it's just because we need that to be able to do tracing, to make tracing like seamless.
Amos: The event names themselves, I think are, are really important to try to get kind of a standard- ish across community, like start and stop. seems to be the standard for like, if you're timing something. But I've seen it a couple places where it's like start and finish or, uh, begin and end. And so if you have multiple of those libraries out there, there's a lot of cognitive overhead whenever you're like, uh, which one of those was it again?
Chris: Right. Well, and you know, so, I mean, I think that's, it's a, it's a, that's definitely a problem. Like discoverability is still, we probably talked about this before, but actually to be honest, that's the names themselves are less of a problem, although it’s annoying, but like the convention, right? Like not every library emits a start and a stop, whatever you want to call it. A lot of libraries just admit, stop. Um, and if you're doing tracing, what that means is that you then have to retroactively, um, build the trace correctly. And that can be really cumbersome because traditionally what you'll do is like start a trace and then finish a trace, like, cause you admit those as different events. But you can't do that if all you get is like stop. And so at that point, then you got to go back and like fake it and then it doesn't enter or leave with all the other traces that you're emitting necessarily. Cause time warping, and all this kind of stuff, it's like a whole thing. So in any case, you know, I think a lot of good will come from just people adopting similar semantic conventions, even if they don't always name the stuff the same way. And that's fine. I mean, I don't know. But again, like all this is like, to be honest, like a lot of it's like pretty boring, like it's just mechanical.
Amos: Yeah, well, and I think there's a big thing too, of if you have a function in your library, that's going to emit some events, adding that to the documentation for that function or that module, whatever, because that I see not happening. So then I have to dig to figure out what events are going on. It'd be really nice if somebody could figure out how to build something in that would automatically figure that out while doing documentation, while documentation is being built. I don't know how feasible that is.
Chris: Yeah. Some of it is, and some of it isn't, and it also has to play with Erlang I don't know, it's a whole, it's a, it's a weird thing. And like, to be honest, it's, it's just more emotional energy and mental energy than I have to understand to even like work out all those problems. Like I just don't have enough context and my brain is unwilling to gain the context necessary, to think about what the solutions would look like, because it's just not interesting enough to me. And it's not interesting enough, like, and it's like largely political, like, cause you got to talk, it's like a, it's a kind of working group. I don't have time for that. Like I'm so happy that other people have time for that. And the energy to go to go discuss that. I super don't.
Amos: And really, the whole idea behind the working group is really just to get some kind of standard, like the stuff that we've been talking about that needs to get done. Hi Andrea! Um, so yeah. They're like they're in there trying to figure out together- cause there's, there's people from, from all the different languages of the BEAM in there, trying to get some semblance of structure between the languages so we can have some inter-operability with stuff like that. So yeah. I'm glad that they're doing that, but I think- thank you. I just want to tell them thank you. Because that, see, that would be the last thing.
Chris: Yeah, I don't want to deal with that. That sounds annoying. I don't want to do that.
Amos: Yeah. Um, as much as I want to give back, maybe that's not the way that I give back. Yeah.
Chris: I built a chat bot framework recently and that's the way I'm giving back. Cause that's way more fun.
Amos: Nice! Is that the one you've been testing in our super-secret private Slack?
Chris: Yes. Yeah. It's pretty fun.
Amos: So I'm going to have to go try to play with your bot. You're gonna have to turn it on again.
Chris: Yeah, it's good. Well, I should say I should actually deploy it instead of just running it locally on my machine.
Amos: Yeah, erm
Both in unison: Whatever.
Chris: Anyway. No, I mean, uh,
Amos: I, I've never built a Slack bot. How- is it pretty simple?
Chris: Its fun! Now you can. It's very simple. It's super simple. Very, very simple.
Amos: I need a Slack bot that, uh, restarts my server.
Chris: I'll link- the project's called uh, the, the project is called, uh, it's called Fawkes, like after the Phoenix and Harry Potter.
Amos: I know. I remember when you put that out there. I thought we were going to put gunpowder under the-
Chris: Nope. Nope,
Amos: under the Parliment.
Chris: Nope, Nope. Different Fawkes.
Amos: Yeah. It was less exciting.
Chris: Well, I mean, you know.
Amos: But it's a good name.
Chris: It is a good name. I like it. Anyway, so, but it's fun. It's on my GitHub. I'll link to it. It's a good, you know, cause it's fun to go back to what? 2017? 2016? When was, when were chatbots a thing? That was probably like 2016.
Amos: Oh, long before that.
Chris: Yeah. You know, you think everybody's moved on to something new.
Amos: It was probably 2007. When did, when did Hubot come out? The one from GitHub group?
Chris: I don't know.
Amos: A long time ago.
Chris: It's been a hot minute. A hot minute. I have a topic.
Amos: Okay. Let's hear this topic.
Chris: Did we talk about this already? Did we talk about abstraction already?
Amos: Abstraction? Yeah, I don't remember.
Chris: Okay. So I'm going to say -
Amos: I mean you probably have new ideas even if we already did.
Chris: Which is, which is a, that's my favorite insult from my teen years. Let's not , let's not and say we did. All right.
Amos: Is that what you want to do? You just want to move on and not talk about it right now?
Chris: No, we're gonna talk about abstraction.
Amos: Okay. Perfect.
Chris: I want to ask you a question. Here's a, here's the, here's the intro. Uh, so have you, have you heard this phrase, all abstractions are leaky.
Amos: I think I've heard it. I don't know where. And it makes sense.
Chris: Sometimes you hear it using the ridiculous, the ridiculously inappropriate, that's really an impedance mismatch between, between these things.
Amos: So I worked in electronics. Impedance mismatches are very different.
Chris: Right? Right?! Like, listen, I did not go through almost five years of a four-year degree in electrical engineering to come in here to the software people to have you co-opt the term impedance mismatch. And you're also all using it wrong. Okay. You're all of you using it wrong. I get that this is just old man shaking fists at cloud, but still you're all using- no- stop. God. Programmers are the freaking worst. Don't use refactor as a real word. Cause that's not a real, word.
Amos: Aaah, come on Keathley, let's not go back there.
Chris: Don't use impedance mismatch because you don't even know what it means clearly. Okay. You can't use impedance mismatch to mean I don't like this. Okay. That's not what it means.
Amos: This is, this is not a common nomenclature in the groups that I hang out in.
Chris: Also, it's only, it's only ever in relation to ORMs. You can see the impedance mismatch between this and the ORM, and the database.
Amos: Okay. Fair enough. Fair enough. I have heard that term used that way.
Chris: Yes, it does not transfer the maximal amount of power because the resistance and voltage don't line up. You're right. You're right. That's exactly. You used it totally correctly. Can achieve maximum power transfer.
Amos: Yup. Your antenna sucks. (Keathley laughing). So, so I, yeah, so I have, I have heard that. I do tend to agree that at some level too, with the original statement of all abstractions leak at some point, um, just because it’s hard to find a perfect abstraction.
Chris: Okay. So, so that's interesting, right? The notion, what does it well, okay. There's two things here that I think are interesting. One is the notion that all abstractions leak, right? Like that's a statement that's being made.
Amos: So that scares me because anytime you say every, all, always, those, those automatically make me go neh, your wrong.
Chris: Well, but that's part of the point, right? Is like there's a, there's this notion that abstractions, that all abstractions leak, right? Like, you know, like that's the thing that gets tossed around. And I think that's interesting to think about. And what does that even mean? Right. And what does it mean for an abstraction to leak and also what is, what do we talk about when, in computers when, you know, programmers co-opt terms like, uh, like abstraction.
Amos: And, and what does abstraction mean in a, in a functional language versus object-orientated? I think it's more obvious in an object-oriented language. Cause I feel like abstraction is, is leaking whenever you either have to go around it or you have to get to some underlying data structure, but I guess that's still going around it whenever you have get down to the, past it, to do something that you need done.
Chris: I tend to agree. But I also think this leads people to incorrectly malign abstraction as like a bad thing, right? There's this nominal sort of belief that explicit things are better than implicit things.
Amos: Well, but wait, everything we do is an abstraction.
Chris: And that, you know, an abstraction is an implicit thing and that's somehow like less good. Am I, am I off base in thinking that ? That's the vibe I get from people.
Amos: I think, I think in a way, I think there's a little bit of, um, what do you call it? Uh, not Munchhausen, uh, but like whenever you have left, leftover horror from another project or another language. And so I think there's a little bit of that, but, um, I think there is a fine line between being explicit and being implicit. Uh, you need, you need that- at some level you don't want to have to add all the bits together, right, to make something happen. You actually just want to call something that has a name that makes sense to you and move on. So you have to have, you have to be implicit at some point.
Chris: Right. Well, I think actually all of the things that people like are actually implicit things. Like, I think, and I think too,
Amos: We have talked about this before.
Chris: I think typically when people are, uh, especially people in functional languages, the things that they point to, and they're like, I love this. This is the best part of function languages, but also it should be explicit. You're like, well, that's, I don't know how you hold that in your head.
Amos: Can you give us an example ?
Chris: Map and filter.
Amos: Okay.
Chris: There. I'm all done. That's the whole thing . Map and filter. I mean, like those are completely abstract things. Or enum in general, right? Like, and this is , so here's the thing, my, my, my opinion is that there are a class of abstractions that aren't leaky. Um, they're mathematical, and we don't tend to talk about them. And the reason they're not quote unquote leaky where leaky just means like, whatever the hell you want it to mean, it just means it doesn't work. You know? And you know, again, it's a nonsense, weasel word that doesn't mean anything whenever the abstraction doesn't hold, right. It's because we're butting up against like the real world. And math, you can control the world. You can just basically say like , for this range of values or, you know, given these, given these, uh, preconditions or whatever, you can like control everything, right. And so you just limit the scope of the world to the things that you can build, like an abstraction around. And also most, most like most mathematical abstractions are theoretically interesting, but only really about themselves. They're not like, well, you know, like-
Amos: I think you need to, I think you need to go deeper into that statement.
Chris: Well, I just mean that like most of math is about math. Most of programming is not about programming or shouldn't be in my opinion. Mathematic is the subject of itself. Mathematics is the subject of itself. Like it gets itself, it's like a lawyer, you know, lawyers make laws. It turns out. So I think like a lot of the- and that doesn't mean that -mathematical abstractions aren't interesting and like math, and like groups and semi groups and monoids and all this crap isn't interesting. That is interesting. That's totally interesting. You know, but I do think it's important to, to caveat these things with like, well, that's math, and math and be about itself.
Amos: Well, I, can it be about itself because it's so basic and fundamental, like really a lot of what we do is, is applying mathematics where mathematics itself is like the study of itself like you said.
Chris: So I would, I would, I would argue that very little of what we do is actually like true mathematics, but outside of like province stats, which, you know, everyone only got a cursory understanding of in college if they happened to go to college. Um, but like, it's, it's really just applied province stats because, you know, it's, all just queues. This is just apply province stats. Anyway, my, you know, I, I just tend to think that like the nature of abstracting things right, is, is finding the core of a thing, like finding the, the essence of a thing and removing it and building like a notion around that, right. So, enum, that's an actual abstraction, cause you've what you've done is you've pulled out the nature of what it means to move, to like iterate over a thing, right. To, to, to roll over some sort of inerrable innumerable thing. And anything can be innumerable, right? Same with collectible. Like, it's a way to talk about things that can be collected, which is interesting. Like that's a fundamentally interesting thing, that that idea of finding like a core abstraction is like very, very interesting because that's what allows you to build systems that grow over time. If all you have is a, for-loop like there's an upper bound on the interesting things that you can do. There's an upper bound on the interesting ways to actually abstract the essence of a thing out. Right? Like you just can't have a numerable if all you have is a for-loop
Amos: So how do, how do you come up with abstractions that are more like a numerable than most of the bad ones that are out there?
Chris: Well, so that's, that's like the interesting part- And I, and I don't know. I mean, I think practice, I think the, I think like this is why it's not math is like, you have to practice. You have to just like write a lot of code.
Amos: Is this one of those things, like, it's hard to define, but you know it when you see it.
Chris: No, I just think that, like, I think there's a lot of, I think there's a lot of fundamental things about the data that we deal with in our systems, right. Um, as the data like moves through the system and as you grow a system and understand more about the data inside of it, you can find those things. And I think we should be finding those things all the time. And I really wish Elixir had a slightly more powerful way to talk about that because really all we have is protocols. Like we only really have protocols and they're just limited because they're, you can only talk about structs, right. So, um, this is the thing I've been like, thinking about a lot, like, what is it, you know, what does it take to, to, to find these kinds of core ideas, um, and, and pull them out. And I think, you know, once you have sort of a maximal amount of data moving through the system, you can start thinking about what is the nature of these things? Like, what is the, what is the essence of these operations that we're doing? What kind of things can we say about these things? What kind of cross cutting, like essential things, can we say about, about this data? And if you can do that, then you're like, well on your way to providing really useful abstractions. Um, the other thing I want to like, think about in this is that, or the other thing I've just been contemplating is like, when people say nonsense words, like, you know, all abstractions are leaky, like what they mean is that encapsulations are leaky. They almost never actually mean the abstraction is leaky, especially when you talk about ORMs because like most ORMs are based on relational algebra, which is math. Like there's no leaking. What's, you're mad about is that the encapsulation is wrong. And those are different things. Like , the idea of hiding, you know, logic and hiding implementation details. That's a good thing. Like that is a good thing. And you want to build systems and layers like that, right. And what people get mad about-
Amos: If you don't you have to write, you know, 40 pages to do anything.
Chris: Right. And what, well, and that's the thing is like those two things tend to go hand in hand. Finding something essential means that you can then reuse it or at least the reuse, the interface for it, right. Um, and that's really useful, but what people actually are getting mad about most of the time is that the encapsulation is slightly wrong or it's hidden away too much information from them and they're not able to get to the lower level thing.
Amos: So can you define what you mean by encapsulation?
Chris: So when I, when I talk about that, um, I just mean essentially implementation hiding, right? You're hiding complexity. You're hiding like all of the necessary steps that it takes to do a thing, right? Like if any given HTTP library that you used to make calls would be a worse library, if you also had to care about, um, the underlying TCP stack. Like it would be a much worse library if you had to talk about like domain name resolution, and you know, uh, I don't- timeouts or deadlines.
Amos: So those, those are what you're calling encapsulation.
Chris: Yeah. I mean hiding those details is-
Amos: Then what are you calling abstraction?
Chris: Well, what abstraction is not like, oh, I put everything in, in an HTTP library and now I abstracted it. You know what I'm saying? Like, an abstraction would be more like I have these entities and in order to hydrate them all, I have to call an HTTP service. There's like an essential part of what it means to be an entity in this system, which is that it came from some other place. The provenance of this data came, you know, is, is some other service. And I want to go get that data. That's like maybe an essential part of it, right. And you might have an abstraction around what it means to like, go get all that data and hydrate it and return it to you, right. Or a numerable right. Like the numerable is an abstraction around what it means to enumerate over things.
Amos: Okay. I think I'm following. But I have-
Chris: My contention is that most people, when they are like, oh, well, my ORM is leaking or there's an impedance mismatch, what they mean is I can't write this query in way that I want to, like, that's all they mean. Right.
Amos: Right. If they have to go down and hit SQL, then they consider it a leak.
Chris: And it’s because the layers are wrong. It's because like the layers and the encapsulation becomes broken because too much is hidden away from you with no access to the underlying mechanisms that you actually want. Um, and, and, you know, I think that's where people get, like these kinds of things, like people, people rightly in a lot of cases, consider this stuff to be sort of bad or premature, like, oh, don't, uh, don't abstract something until you have three. And what they actually mean is don't encapsulate this logic somewhere until you have three of the thing, or like, whatever, either like don't hide away this logic until you have, uh, lots of them and you've proven that you need it or whatever, right. And I think that, uh, and, and I don't have a conclusion to this. I don't have like a, like a big takeaway from this, but this is something I've been thinking about a lot, like just for whatever reason.
Amos: Yeah, I think you've ruined the rest of my day, like that's what I'm going to be doing.
Chris: And now I just, now I needed to share it.
Amos: Yeah. Thanks.
Chris: I don't, I don't have a, I don't have an outcome to this. Like I don't- and in some ways I'm kind of looking to like, maybe I'm totally wrong about all of this, which is difficult. I'm typically wrong about everything I say. You should just consider that to be true.
Amos: I think that's okay. That's okay.
Chris: But I think it's important, like I don't, I think, I think, I think making these distinctions is important because it allows you to talk about things that you like, and don't like about APIs in this concrete way. And I think, you know, we're experiencing that a little bit at work, right? Just like we're going through these growing pains as we've hired a lot of people recently, and those people, rightly so, look at these services and they're like, what have you people done? What is any of this? Right. And I think that this stuff, because I think this stuff applies at a system level and not just at like lines of code level, you know, this stuff applies, you know, across your entire organization and not just inside VIM. You have to think about this stuff. And you, you have to build services in such a way that follow these same principles, right? Like you have to build services that are abstractions around certain things, or like that are, that encapsulate logic, right? Like if everybody has to know intimate details about how a thing works in the system, that's a coordination point and you have failed to design the system well, because it means that now you have to coordinate and coordinating is not a thing that you want to do most of the time.
Amos: Yeah. That adds a whole lot of complexity. As soon as you have to coordinate anything.
Chris: Right. Anything at all. Right. And that includes teams, you know, and, and people, and developers and pull, pull requests and migrations and all this stuff. You've got to coordinate all that crap-
Amos: Or systems.
Chris: - that, you're in a bad place. You're in bad shape. Sometimes you do it because you need the, like, you know, Bezosesque letter that goes out that says everybody do it this way, or get a new job. You don't really want to, you know, typically you don't want to act that way, cause that would make you a jerk. But also you, you know, you want to limit the times that you do that, even if you do it nicely to, you know, maybe twice a year, right. Like, because otherwise you're going to like churn everybody's life. So this is something that I've been thinking about a lot and it's, cause it's come up a lot. Um, and I think other people are trying stuff like around this, right? Like trying to work out, how do we, you know, like how do we encapsulate, um, things inside of Elixir services, right? Like how do you put stuff in a module and then kind of have everybody like respect the boundaries of that module, right. Like, and all that kind of stuff. And I think that's interesting, but I think at a fundamental level, there's no amount of tooling that's probably going to solve that. Like tooling helps you enforce the design decisions that you make, right. But you still have to make the design decisions. And so having a vocabulary that's actually well-defined and formed around talking about design decisions seems really important to me.
Amos: I agree. I'm still trying to figure out completely the differences that you're implying behind abstraction and encapsulation a little bit. You've definitely put some thoughts in my head about, about how to, how to design all this. And, and even, even at system levels, you gotta think about it there, you gotta think about it at every level of the code and at different levels, there are different, like real world requirements for the type of abstraction that you're going to make. You're not going to do the same thing for, at SQL level that you would do at an API level, right. For, for a server.
Chris: Right. Well, and I, I just think, I mean, I do, I do think that there's, I think there's a lot of shared stuff. When you talk about, you know, encapsulation and abstraction, right? Like part of the benefit of, of, of abstracting something is that you get encapsulation, right? So like with a numerable I need to implement what, four functions, three functions, something like that, whatever it is or whatever.
Amos: Well you don't have to implement- think the only one that you, I don't remember, I don't, I don't think you have to implement all of them, but it's reduced, count, slice,-
Chris: And something else. It doesn't matter.
Amos: Yeah there's one more.
Chris: Yeah. It doesn't matter. It's boring technical details, but you do, you do the thing, but then you get this rich set of operations on top of it, right. You get this huge benefit for buying it. And that is a form of sort of like, I, you could argue that that's a form of encapsulation, right? Cause you, you just don't have to care anymore. It's like, if your special struct thing knows how to be collected, like, well, I don't have to care anymore. I just collect it.
Amos: Collectible might be my favorite.
Chris: It's great, right. You know, and like I do argue all the time and I will continue to argue that we should all be using protocol like way more, just generally. Right. You know, I have no advice for you on how to like arrive at the right, at the right actual protocols.
Amos: That's what I was gonna say. That's the hard part is coming up with like what the protocol should be. I mean, the only thing that's worked for me is you just, you just build a system long enough that you understand, that you sort of understand it at a fundamental level, like what it means to have these for these, you know, what are the, what are the key things about this data? And then you like pull all that apart and you use like a bunch of different protocols to solve it. Um, because that's allows you to, you know, grow the system better over time. It allows you to maybe not reduce things, like you don't, you're not going to reduce like the lines of code probably, but it allows you to grow that system over time. That's sort of like a health check, right? Like it's like, it's like a, just a better, a life betterment thing, right? As you like move through the system. But yeah. Like, I don't know. Like I think, I think all this stuff gets kind of like a bad rap because people have seen the, you know, the classic Java structs app that had 10 objects, you know, deep of random garbage that they had to wade through in order to like submit a form request or something like that, right. Like it's, you know, we've all seen that, that kind of terrible app.
Amos: Look at and going back to philosophy of software design.
Chris: But I don't think that makes encapsulation bad. Like you want that, right? Like you want, like, you don't actually want to know how the relational algebra SQL query gets put together. Like most of the time, like maybe you do, you can make an argument that all you want to do is write SQL queries. And I'm not necessarily going to, I'm not actually going to argue with you about that part, like, all I want to do is just write SQL queries and then run them. Uh, I don't actually want anything more than that. The other really important point is that, you know, you can't have an ORM if you don't have objects in your language, that's just a galaxy brain move. So that's also good for us. But what you really want to do is write queries and execute them, right. And so when I talk about like, you don't actually want to know how the relational algebra thing works. I don't just mean like in your language de jour, I mean, in, you don't want to know how the query planner works. Like that would suck.
Amos: Right!
Chris: Like I don't want to know how Postgres, it's interesting to know how Postgres query planner works. I want it to be good.
Amos: You don't want to have to tell the thing which index to use every time you do a query,.
Chris: Right. That would suck .
Amos: At all. By the way, if you're doing that in your project, you're probably wrong. Moving on.
Chris: You know, but that's the kind of like, that's the kind of encapsulation stuff. Like you want to hide that. You don't want to, you don't want people to have to care about that. Yes. You want to be able to analyze it. And see. Because there are times where it matters, but most of the time you don't want to care. And I think that like, people, people sacrifice encapsulation on the altar of quote unquote explicitness. And it's like, yeah, but if you were, if everything was maximally explicit, that would be awful. Like that would suck so much.
Amos: You'd be moving bits around like,-
Chris: Well, you just write, Go. I mean, like, you know, like you might as well just write Go at that point. Like none of that's.-I mean, yeah. You can look at it and see everything it's doing, but like, I can look at my Elixir code and see everything it's doing, and I can trust that, like under the hood, the schedulers are all working correctly. And like, I dunno, like, you know what I mean? Like, that's, that's such a weak argument because you do, your remove the ability to like abstract things out when everything is maximally explicit.
Amos: Okay. So would you say that-
Chris: Or data log. Data log is amazing! You couldn't have data log!
Amos: Would it- it's true. Would a GenServer, would you call that an abstraction or encapsulation?
Chris: That's, I mean, it's, it's, uh, it's, it's an abstraction and in as much as it's a way it's a series of stuff, right? It's a behavior that you implement that does things. And the cool thing is like, you don't have to know what it does inside of there. Because like it's doing all this other additional work for you. It's doing things like naming the process. It's doing things like having all these like explicit callbacks that know how to like take in the PIDs of like messages or it's coming from and do selective receive and, you know, uh, do all this work, right? Like you get all this benefit out of it because like it's a behavior that you can just extend and, and like use wherever you want and for whatever thing you want to do.
Amos: So that's an abstraction,.
Chris: Right. I mean, you also get some benefits of like, it's hiding, implementation details. For instance, it's hiding the selective receives it does, it's hiding, you know, the fact that it's like naming the process for you,-
Amos: Timeouts.
Chris: It's hiding all of its, you know, all of its junk that it does, that it just does that you just get for free by using handle call. Like that's a ton of crap that is going on when you do that, right. And so like, you don't have to care about any of that. Maybe at some level you do. But, but the majority, the vast majority of time, you don't care, you just do not care like how that works. And that's good. Like that's a huge monumental benefit. Like we want this.
Amos: Yeah. And at no point in time, do I ever feel like I have to go, I mean, okay, so once or twice, but most of the time I feel like I don't have to go around GenServer it's not in my way. It's not a problem. Supervisors, especially like, I don't think I've ever gone around a supervisor for anything.
Chris: Yeah, I mean, and there's always going to be, you know, I I'm sure immediately, Fred's going to tell us all the reasons, all the exceptions to these rules and why, and the experiences where he's had to do that. But like, and that's good. That's fine.
Amos: I want him to come on and tell us. Come on Fred.
Chris: Yeah. We're summoning you now. No, I'm sure there's always a reason that you wouldn't do something right. Like that, where you do need to get down below the lower layer and that's fine. That's why you build systems in layers. That's why you build, you know, everything on top of the next thing, right? Because then if you need to go get access to the lower level thing, it’s just right there, you can just go use it. That's awesome. Um, you don't want to have to care about that unless you do. And so I don't know. I've just been thinking about this in front of a couple of the first perspectives. One is like, how do you do this better? How do you get this, uh, how do you get this right more often? And because you are going to get it wrong, like you're going to do abstractions, you're going to build abstractions. You're going to build, you're gonna encapsulate details and it's going to be wrong. And so I've been thinking a lot about like how you get better at doing more things correct more often. So I think is really the trick, right? Statistically speaking, like, you just want to be right more than you want to be wrong and you want to be kind of moving the, you want, you know, you want the, you want the derivative to be looking good. Um, and so I think, you know, there's something about that. I was just, I don't, and to some degree, I want to reclaim some of these ideas because I don't think they're bad. And I think like we do ourselves a disservice by speaking incorrectly about stuff that we don't like and trying to ad hoc, justify it using, you know, big words like impedance mismatch. Read a book people.
Amos: I look forward to your very long blog post about all of this.
Chris: No, see, that would be too much to write. I couldn't, I couldn't, I, I can barely speak-
Amos: One paragraph.
Chris: Let alone, let alone write anything.
Amos: Well, you gave me some things to think about.
Chris: Go get a copy of Horowitz and Hill and look up impedance mismatch. That's all I'm asking of you. It is an expensive book. It's an, is a pricey book, but it's the best.
Amos: If you want to know anything about electronics, you should buy that book.
Chris: Yeah. Yeah. What impedance mismatch means. It has nothing to do with ORMs, as it turns out. Has literally zero you're, you're gonna, you know, you're going to be stunned when you open it up and you realize they're not, there's not an ORM in here.
Amos: You know that-
Chris: There is a lot of ohms in there but there's no ORMs.
Amos: You know, that every ham radio operator licensed person is like, I know what an impedance mismatch is.
Chris: Do you think that that's the problem is that people, people heard ohms, but then misheard it as ORMs. And now they're like, oh, that must be what that's about.
Amos: I think, no, I think, I think it is that the terms get reused and change for I, and I think that that's fine.
Chris: Wait, you're saying that it's okay that language changes and evolves over time? Blasphemy.
Amos: Yeah, it has to be.
Chris: Incorrect. No way. Not cool.
Amos: I know that you don't like it.
Chris: No, I actually -
Amos: If you can't find it in your 1812 dictionary, you're like, nope. Not a word. Ye all.
Chris: I don't know. Ye is in the Webster. So that's all I'm saying, but I have no problem with no,
Amos: And refactoring is not.
Chris: I have no problem with language changing. I have a problem with people speaking imprecisely about things, when- like, if you don't like ORMs, that's fine. I don't like ORMs. Like we can have that party together, but let's talk precisely about what it is that we don't like, because that’s what’s interesting to me. What are the things that we could actually fix? And if you just toss around a bunch of nonsense without actually specifying what it is you don't like, then you're just complaining. That's not useful. Like that's not an interesting thing, right? It's like all the people on the Elixir forum, which is still the most useless thing I've ever seen, who complain about Elixir, not having quote unquote strong types. First of all, that term doesn't mean anything. And you sound like an idiot whenever you use it. I immediately assume.
Amos: What is the intention? Wait, wait, what is their intention whenever they use the word.
Chris: I don't know! Complaining, I think. Because I clearly, they've never built anything in Elixir. Anybody who complains about it because it's not a big deal as it turns out, right. And like, you know, I just quietly sit over here building a real system that still continues to work somehow. Uh, and you know, and yet I don't have any sort of strong ties. I mean, I hit this keyboard pretty hard. I don't know if it's strong enough, but uh, we'll see. But you know, it's stuff like that where it's like, well, that's not actually useful in the same way that honestly, you know, to, to, to, to argue the other side, right. Talking about building open systems and about, you know, fighting against, you know, being a dynamic, typing apologist, right. Isn't actually a useful thing when there are type systems type algebras out there that are really good at building open systems. Like they exist, right. We just don't tend to use them and people don't tend to like them.
Amos: Well, and I, I think the people that are complaining, their complaining is more like, I really like systems like Haskell. I wish that Elixir had a typing like Haskell.
Chris: Well, you know what, Napoleon, you can leave. But I, I just mean that like, it's not, it's also not useful to, to like disregard every language that has structural typing and be like typed languages, don't handle data well. And it's like, well actually like structured languages with structural typing do. Turns out Haskell doesn't have structural typing, and it's the worst one, but everyone feels like they have, you know, it's like Haskell is like fricking reading, you know, To Kill a Mockingbird or The Great Gatsby as a 15 year old and you have a good English teacher, right. And all of a sudden, your mind is open to like, oh, you're right. Look at all this symbolism and meaning here. And it's like, now you're going to, you know, you understand the world all of a sudden, like everybody has these emotional attachments to these books that they read, right. Haskell's like, oh wow. I like truly understand what it's like to understand types now. And monoids and like, yay. But like, it turns out, and if you want to talk about a language that deals with data, Haskell's the worst because it doesn't handle any sort of structural any of it right. There's languages out there that do, we just don't tend to give them any sort of airtime, right. And that would be an interesting thing. Like how do we push a type system that does handle ad hoc data representation? That's interesting. That's an interesting conversation, but you can't have it as long as everybody's arguing, like, around the fundamentals to begin like the first order of fundamentals.
Amos: Right. Is that because -
Chris: And it really just because it, and I think it's because people just complain, like people just complain then validate their argument using like ad hoc rhetoric. And that's not interesting. And I mean, I'm doing, I'm guilty of that. I'm doing it right now, but-
Amos: I'm glad that you brought that up.
Chris: I mean, I am, I mean, that's just how that's, that's just human beings, but it's not interesting, right? That's not, that's not, it doesn't lead to an interesting conversation. I'm interested in like, reclaiming that, like I'm interested in figuring out how we make things better. Like what would a, what would a, what would a library in Elix- like that allowed you to build queries and execute them, look like in Elixir? That wasn't Ecto. Not that I like hate Ecto or whatever, like everybody chill out. But just because like, I think that's interesting. If you have a problem with Ecto, what is the problem? And if you have a problem with Phoenix, what part of it do you not like?
Amos: And how do we solve it?
Chris: And saying it's too big is not an answer. Like that's not helpful.
Amos: You have to talk about the trade-offs of specific decisions instead of just stating something.
Chris: And, and also the goal is the goal here is not to arrive at agreement, right? It's not to change anything necessarily, but it is the goal is to arrive at understanding. The goal is to arrive at understanding about why people made the trade-offs that they made and like what the point was and what they were trying to do and what problems they were trying to solve, right. And like, not enough of that happens because, you know, you just like throw big words around and you, and you have opinions and that's not helpful. It's not useful. Anyway, these are all things that have been bouncing around in my head.
Amos: As we say, from our soap box.
Chris: Well yeah. This is my soap box and no one else is here. So I'm allowed to say whatever.
Amos: I'm here, ya jerk! No, this is good. You you've given me a lot to think about today. I do have to get out of here though.
Chris: (sigh) Fine.
Amos: Soon. I know I missed you. We've not been able to be on for a while because of sickness and travel and sickness and sickness, sickness. So it's, it's nice to be back and get a little more, but you know, I have some, some impedance mismatches that I need to go refactor today-
Chris: Yep. Good luck.
Amos: Into a less leaky obstruction. Thanks for hanging out today, sir.
Chris: All right. Have a good day.
Amos: Alright, you too. Later.