315 - Dave Thomas, RubyConf 2026 Keynote Speaker

In this episode, I talk with Dave Thomas about RubyConf 2026, the essence of a good conference, and the philosophy of programming, including abstraction and the art of using AI in coding.

Links:

• The Pragmatic Programmer
• The Pragmatic Bookshelf
• PragDave.me
• Nonsense Monthly

Transcript

Snail Mail Newsletter For Developers

SPEAKER_00 0:00

Hey, it's Jason, host of the Code with Jason podcast. You're a developer. You like to listen to podcasts. You're listening to one right now. Maybe you like to read blogs and subscribe to email newsletters and stuff like that. Keep in touch. Email newsletters are a really nice way to keep on top of what's going on in the programming world. Except they're actually not. I don't know about you, but the last thing that I want to do after a long day of staring at the screen is sit there and stare at the screen some more. That's why I started a different kind of newsletter. It's a snail mail programming newsletter. That's right, I send an actual envelope in the mail containing a paper newsletter that you can hold in your hands. You can read it on your living room couch, at your kitchen table, in your bed, or in someone else's bed. And when they say, What are you doing in my bed? You can say, I'm reading Jason's newsletter. What does it look like? You might wonder what you might find in this snail mail programming newsletter. You can read about all kinds of programming topics like object-oriented programming, testing, DevOps, AI. Most of it's pretty technology agnostic. You can also read about other non-programming topics like philosophy, evolutionary theory, business, marketing, economics, psychology, music, cooking, history, geology, language, culture, robotics, and farming. The name of the newsletter is Nonsense Monthly. Here's what some of my readers are saying about it. Helmut Kobler from Los Angeles says, thanks much for sending the newsletter. I got it about a week ago and read it on my sofa. It was a totally different experience than reading it on my computer or iPad. It felt more relaxed, more meaningful, something special and out of the ordinary. I'm sure that's what you were going for, so just wanted to let you know that you succeeded. Looking forward to more. Drew Bragg from Philadelphia says, Nonsense Monthly is the only newsletter I deliberately set aside time to read. I read a lot of great newsletters, but there's just something about receiving a piece of mail, physically opening it, and sitting down to read it on paper that is just so awesome. Feels like a lost luxury. Chris Sonnier from Dickinson, Texas says, just finished reading my first nonsense monthly snail mail newsletter and truly enjoyed it. Something about holding a physical piece of paper that just feels good. Thank you for this. Can't wait for the next one. Dear listener, if you would like to get letters in the mail from yours truly every month, you can go sign up at nonsense monthly dot com. That's nonsensemonthly dot com. I'll say it one more time nonsense monthly dot com. And now without further ado, here is today's episode.

SPEAKER_03 3:53

Hey, Jason, great to be with you. Always fun.

SPEAKER_00 3:57

So uh you are keynoting uh RubyConf 2026, which I am absolutely thrilled about. Um and I wanted to bring that up right off the bat, uh, because I think a lot of people will be very excited to see you there at RubyConf. Um and it's happening in uh Las Vegas where you spoke at Sin City Ruby. Um so that'll be exciting to see you in Las Vegas again. Um anyway, uh what have you been up to lately? What's been on your mind?

SPEAKER_03 4:30

Well, I gotta say before we do that, I am really excited to be there too. I I'd I'd love the uh the Ruby community. I love meeting up with old friends and new, and so this is gonna be a blast. So I really appreciate it.

SPEAKER_00 4:49

Yeah, and uh without saying anything negative about past RubyConf uh events, um part of my vision for this conference, uh, because I'm co-chairing this this conference with Freedom Doomlao, is to kind of breathe new life into RubyConf and to make it very fun and eccentric and lively and all those things. And so I want to say to anyone who's thinking about maybe attending RubyConf 2026, expect something different. Um, expect expect those things. Um and I'm curious for you, Dave, just for conferences in general, what do you what do you like about conferences? What makes a good conference to you?

What Makes Conferences Worth It

SPEAKER_03 5:39

I like conferences that uh first of all that don't have like 15 parallel tracks. Um I it always upsets me that the opportunity cost of there's two talks I want to see at the same time just bugs the crap out of me. Um I like conferences that have a decent gap between the talks uh because I find that I get as much out of the conversations afterwards as I do from the uh the actual talks. Um I appreciate conferences where the sound is good. Um I have to say I've been to a few uh over the last couple of years where they didn't pay too much attention. They had like a lot of people now are using these massive LED screens, which are phenomenal, absolutely great. And then they slap up a couple of you know PA speakers, and you either are blasted out or you can't hear what people are saying. So sound to me is quite important. But fundamentally, it's it's just a good conference gets out the way, and it encourages a certain set of behavior and then lets people get on with it. That's what I think.

SPEAKER_00 7:06

That's really interesting. I want to digest that a bit. A good conference gets out of the way, it encourages a certain kind of behavior. Um, can you expand on that a bit?

SPEAKER_03 7:18

Um yeah, stupid stuff. Like um a good conference will have uh like soft drinks and snacks available through the day. Uh because that encourages people to meet up at certain places. You know, you'll be standing in line waiting for your next pretzel, and you'll get talking to somebody. Um they'll have an area where they have, I don't know what they call them, but you know those kind of bar tables, the ones, the round ones that you stand up at?

SPEAKER_00 7:52

Yeah, the high tops.

SPEAKER_03 7:53

Yeah, high tops, thank you. You have you have an area with something like that. Because one of the things I really hate is I'm carrying my laptop bag. I've probably got like um you know conference stuff in one hand and a cup of coffee in the other hand, and I'm sitting trying to talk to somebody, you know? So just having like high tops where I can put my drink down, it encourages people to get together and chat.

SPEAKER_00 8:16

Okay, yeah, so the the high tops and stuff, those those encourage people to congregate.

SPEAKER_03 8:22

Sure. So all of those kind of things encourage people just to stop and get together and you know, just in groups of two or three, just chat about stuff. Um a really great example of that was a conference I was in Amsterdam that was held in an old customs house. And uh they had a big room, which was kind of the general assembly area, plus it was also the vendor exhibit hall, but it wasn't like all vendor exhibits, they were tucked into one side. They had um uh local coffee shops had stalls set up where you can get a really good cup of coffee. One of the vendors, bless them, was making stroke waffles. And uh so I visited them quite a few times. Uh they had high tops, they had regular tables you could sit down at. And it was just at the end of a talk, everybody came in there and just hung around, you know? And it just made it really, really nice to be able to just carry on conversations and and see what people were up to.

Social Norms That Spark Conversations

SPEAKER_00 9:30

Yeah, that is a great point. And that's something that I tried to do at SinCity Ruby to to have nice big long breaks between the talks, and I think people enjoyed that. Um, and so as much as I can influence that at RubyConf 2026, I'll try to make sure to have that be the case as well. Um, and I don't know how much of a difference this makes, but I also want to try to set the tone and set some certain social norms. Um, and say, for example, uh, this is a conference where it's encouraged and expected that people will come up to each other, total strangers, just come up to each other and just say, Hey, my name's Jason, uh, how are you? And then uh kind of uh give people a template for that kind of interaction and say, if you see somebody by themselves, approach them. It if you feel like it, approach them, introduce yourself. And if somebody does that to you, if they come up to you, uh here's what you say back, and that kind of thing, to set that tone. I don't know if that's gonna do a lot, but I I think it's helpful to at least uh encourage that behavior.

SPEAKER_03 10:47

Yeah, although uh I think you can you can take some of that too far, I think. Um uh I got a horrible feeling you did this at Cincinnati Ruby, but I'm not too sure. Um but conferences quite often have these opening sessions where they have like a um an exercise that all the attendees have to go through where you pick a random group of five people and you know build a bridge out of Lego or you know, talk about the world's problems, whatever it is. Um and I'm not too sure personally, and I I mean I'm weird, right? So you can't take that as being any kind of thing. I don't know if that actually really helped going forward in the rest of the conference. Um I think I like, I mean, your idea of giving people like almost like a script when they're talking to other people. I think a lot of people would find that helpful.

SPEAKER_02 11:54

You know.

SPEAKER_03 11:55

Um and you could suggest that the first question people ask shouldn't be who do you work for or what do you do? But it could be something like, you know, what are you excited about? Or uh what's your hobbies? You know, or something uh name a vegetable. Name a vegetable, yeah. I don't know. Something something left field, but something that doesn't like invoke the standard social reflex.

SPEAKER_00 12:32

Yeah. Yeah, I I think I know what you mean. Because like if you if you go down that path, it's kind of like a rut. Uh it's a well-worn rut, and then you are in that rut and and you kind of go down that path of normal small talk or whatever.

SPEAKER_03 12:50

But if you start Yeah, and you're also like in a way in a way you can get kind of guarded, right? Because either you you love your job, but you've also got to be careful about what you say, or you hate your job and you've got to be careful about what you say, you know. Um whereas if you say, you know, what are you really excited about? Or you know, uh, do you do you do you play around with raspberry pies? Or you know, something you're just tightly off the side. You know, I think that that really would help. But anyway, so what's your favorite vegetable?

SPEAKER_00 13:25

Um well the the question I was asking was not what's your favorite vegetable, but just name a vegetable. And the first vegetable that the first vegetable that came to my mind was carrots. Um and and you know, there's different questions you can ask about carrots. First of all, do you like carrots or do you not like carrots? And then there's a big uh raw versus cooked controversy. Some people like only raw, some people like only cooked. I personally prefer cooked, but under some circumstances, I like raw carrots too, like maybe in some kind of salad or something like that, uh, but usually cooked. How about you?

SPEAKER_03 14:04

You get your carrots, you stick a skewer through one end, across them, and you suspend them so half of them are in the boiling water of the pan and the other half aren't. And then you boil the water, and after you finish, you then have a carrot that's half cooked, half raw. And then you can get to experience the gradual shift between cooked carrot and raw carrot.

SPEAKER_00 14:27

Is this something you've actually done? Hell no. Okay, this is just an innovative idea you came up with.

SPEAKER_03 14:35

You know, I I am I'm full of them, you know? Yeah.

SPEAKER_00 14:38

Yeah, wow. Actually, we went to this French restaurant recently where they had some incredible carrots. It was like uh there they were cooked, but they weren't like mushy. Uh and then they had a sauce. It was like a sauce of like pureeed carrots mixed with butter and cream or something like that. It was it was really good.

SPEAKER_03 15:00

Yeah. Yeah. I used to make these caramelized carrots, which are kind of the same kind of idea. That you you put a small amount of water in the carrots, and then you put honey or sugar or and and some salt in the water, and then you basically boil it until it's not quite dry. And so you end up with like a caramel glaze on the carrots.

SPEAKER_00 15:22

That sounds good. Um, yeah, okay, so we've just demonstrated an instance of not starting in this rut of where do you work, blah, blah, blah. But we went in a totally different direction, name a vegetable, and uh it leads to all sorts of wonderful places. It does.

SPEAKER_03 15:41

It does, and it's healthy.

SPEAKER_00 15:44

The the conversation or carrots or both?

SPEAKER_03 15:47

Both. Both. It's a twofer. It's a twofer.

SPEAKER_00 15:52

Um okay. I I want to mention I saw some or all of the talk that you gave at SF Ruby. Uh something about objects uh and classes and all that, and I loved it. By the way, I read your um bio that you sent for uh RubyConf. And it said something about you give talks that are sometimes uh interesting, sometimes annoying, something like that. Oh, and you said uh here here's the thing that I was trying to remember. Um sometimes you have controversial opinions or something like that. And I love that because me too, and I love a good contrarian. And I feel like a lot of the things that you shared in that talk that you gave at SF Ruby were both controversial and super correct, which I loved.

SPEAKER_03 16:50

Yeah, that was a talk about the overuse of classes. Um that uh in the Ruby community we have fallen into the trap of thinking ourselves uh as a class-oriented language as opposed to an object-oriented language. And so we end up with abominations like service objects. Um we end up with the abominations like base classes, right? Uh which I think you tweeted about yesterday. Um that um shouldn't even exist, right? Um and it's kind of like this is borne out. I've been for the last five years, I have been um well actually birth further back than that. Starting back in like 2016 or so, I was doing a fair amount of Elixir work, and Elixir is not an object-oriented language, although actually I would argue Elixir is also one of the most object-oriented languages there are. Um but on the surface, it doesn't have objects, it has functions and values. And after I got used to that, I found that my programming style was a lot clearer, I guess. So when I went back to writing Ruby, I found myself writing far more in that style. So I did not reach for a class every time I had to do something.

SPEAKER_00 18:24

Wait, sorry, when you say in that style, what style is that?

SPEAKER_03 18:28

So the style is that you don't write you don't think about what you're doing in terms of objects. You think about what you're doing in terms of values that you uh manipulate's not the right word, transform. And you think of your program as effectively being a transformer from its input to its output. And then you you you layer you layer that as sets of objects, not objects, I'm sorry, set of functions that you kind of nest in order to get the transformation that you want.

SPEAKER_00 19:05

And how much does this have to do with maybe the idea of functional programming and the distinction between an imperative and a decorative style?

SPEAKER_03 19:14

I don't I'm increasingly thinking that functional programming is a kind of meaningless phrase. Um because it means so much to so many different things to different people. So to some people you're doing functional programming if you're using each map. Um and to some people you're doing functional programming if you have immutable data. Uh and then to the purists, you're doing functional programming if you're programming pretty much exclusively in types. Um and I don't know where on the spectrum I fit in that. Um what I do know is that the style is way more about functions than ever about classes. And typically now when I'm writing Ruby or just about anything else, JavaScript, whatever, I find that the only time I use classes is when I need a data store that also has to have some convenience methods. You know, like a two-string or uh serialization to JSON or whatever it might be, then I'll stick that, but the class will not have any uh application domain things in it. Right. Instead, those will all be external and I'll just be passing uh my data structure between them. And by doing that, two things happen. First of all, I'm decoupling representation from processing right in a class of both of them together. And so you have to think about both at the same time. Um when you do it separate, you think about what data I need, and then you think about what do I need to do about that data. And they're two separate activities. Um the second thing it gets you is a lot more transparency in terms of what you're doing. Um if you think about pipelines, then a pipeline is simply a series of functions that you pass something between, some value between. So a value goes in one end, gets transformed, gets passed to another function, gets transformed, gets past another function, and eventually pops out the end. And the cool thing about that is that at any point I can insert another function in that in that pipeline. And the obvious example is I want to inspect the values for debugging purposes as they go through. This pipeline, so I can inspect a value. If I want to do testing, then I can choose any arbitrary string of those functions and test them as a unit. I can test individual functions, I can test two, I can test three in the middle of the pipeline, whatever I want to do.

SPEAKER_00 22:18

Because of the loose coupling?

SPEAKER_03 22:20

Because the fact that they don't rely on an over they don't live in this overall context, right? A function is is purely a transformer of data. So whereas in conventional OO programming, half of the joy of testing is constructing all of the various objects that you need to create the context for the test. If you're doing it in a functional style, then all you have to do is to create the struct that you're going to pass to your function. And that makes your testing a lot, lot easier.

SPEAKER_00 22:58

Man, there is so much there. Okay, I want to ask you a question I might have asked you before. Um and it's maybe an unfair question to spring on somebody, and also an obnoxious question, but here it is. Um do you think there's a single most important idea in programming? And if so, what do you think it is?

SPEAKER_03 23:37

I think programming is not a thing. Um there are many different kinds of programming and many different reasons to program. And each of those probably has its own emphasis and biases and everything else. I think for the kind of coding that uh most of us do on a day-to-day basis I'm not gonna say it's the most important because I don't believe in absolutes, but I think an important thing that we always have to keep in mind is that the reason we're programming is to add value to someone's life. And so as we're programming, we need to keep thinking about what it is, no, sorry, not what it is, but why it is that we're writing the code.

SPEAKER_00 24:38

Right. Right. Um something I wrote in the book that I'm working on now is that basically all programs exist for some business purpose with business meant in the broadest sense. Um and something that we always have to keep in mind is the the value that we're intending to create with what we release into production.

SPEAKER_03 25:08

It's slightly more than that, though. Um I uh for various reasons, I was researching Luddites. Um and I I had the same idea that I think everybody has about Luddites, that they were a group of um workers who were being displaced by automation, and so they went around destroying factories uh to prevent that happening. Um and I read a really interesting Smithsonian article about Luddites that basically said that's not really the story. The the story was that they were saying you are uh adding this capability to your factories, you know, automated knitting machines. It would seem reasonable to us, the workers, if you were to train us on how to use them. If you were to start apprenticeships so that people coming through could learn how to use them. Right? We are not against the technology. What we're against is the fact that you are basically firing us because you believe this technology will take our place. And their vision was that a skilled worker in combination with a knitting machine is better than either on their own. And that's kind of what they were fighting for. And when you frame it that way, I am 100% in support of that kind of idea. Um that if you think of it now about say I AI, there are some companies that are just firing everybody saying, hey, I could just replace them all with Claude. Um and that is remarkably dumb, you know, for two reasons. Uh first of all, because uh Claude isn't that good, and is not yet that good. Um and secondly, because it really ignores the future. Right? What's gonna happen two years from now when you don't have the programmers that will be able to work with Claude, because you didn't have any junior programmers now. Um so the kind of Luddite uh resistance to that would be to say you shouldn't be just firing people, you should be transitioning people into their new roles, into working effectively with these AIs. And you know, everybody gets to benefit.

SPEAKER_00 28:09

I think I totally agree. And it's interesting, I I think there is another layer to this which is a little bit less obvious, which is uh I don't know that we can say that we know that companies are firing people because of AI. All we know is that they're firing people and saying that it's because of AI. And I have a strong suspicion that in a lot of those cases they have some other motivation for laying off people, and AI is merely a good pretext for doing so.

SPEAKER_03 28:51

Yeah, but companies in the past have not been uh shy about just laying people off. You know.

SPEAKER_00 28:59

That's true.

SPEAKER_03 29:00

I'm not too sure they need an excuse to do it.

SPEAKER_00 29:05

That's true. Although part of what I'm thinking is like if you just lay people off because, you know, oh, we wanted to um decrease expenses or something like that, it kind of raises questions like why'd you do that? Like, are you are you in trouble? Like, are things not going well? Something like that. Uh whereas they could alternatively say, oh, things are going great. Um and now that we have AI, we don't need all this overhead, we can do even more with fewer people.

SPEAKER_03 29:36

That could be. I can see that.

SPEAKER_00 29:38

Yeah. Kind of irrelevant to the point. Um, but I I wanted to say that because uh it's uh it's not totally clear to me that what people say is happening is is what's actually happening. But back to the um the Levite philosophy or whatever, um don't fire us, uh train us on this new technology because a skilled person with the technology in combination is going to be better than either one alone. I can totally buy that.

Working With Claude Without Chaos

SPEAKER_03 30:16

And the the the the danger, I think, with AI is that I mean I've been using Claude now uh extensively for like a month or two. Um and I am constantly surprised at just how damn good it is. At the same time, I know that if I wasn't there with some kind of hand on the helm, just like steering it, then we would end up with a probably working but unbelievably ugly, hard to work with chunk of code. Um so it's been very interesting for me uh kind of educating myself on how to be effective as a partner in that kind of coding exercise.

SPEAKER_00 31:06

Have you found okay, so do you do the thing where you add like um skills or whatever markdown files that that kind of guide Claude to code in a certain way?

SPEAKER_03 31:18

I uh yeah, I do some of that. Um I'm not one of these people that tries to skill everything. Um and I'm not above stealing skills off the net if I find something that's useful. Um I have tried using like uh the prescriptive skill frameworks, you know, the Wiggins stuff and things like that. And I found that because they don't work the way I think, I'm not as very I'm not very productive with them. Um so I prefer um uh I spend a lot of my time in planning mode. And I spend a lot of time chewing the fat with Claude, you know, and it wants to sit there and say, hey, I'm ready to start the plan, you know, and I'll go, no, let's sit down and think about this and that and the other. And it is really interesting that over time Claude has kind of like adapted to that. Every now and then when we're doing something and I like the way it's done it, I ask it to write a skill that describes that so that I can do it again in the future. Um I also, it was really interesting. I um, as an exercise, spent a couple of days with Claude on a kind of meta project where I asked Claude to evaluate which coding standards made it easier for Claude to work with my code. Because it strikes me that we are uh we have a history now of a whole bunch of quote rules that we follow that are designed to make our programs easier to work with, easier to read. But those are all for humans. And so I wondered what it would look like if I said to Claude, write a program that is optimized for your understanding in future.

SPEAKER_00 33:21

That is so interesting. I've never heard anybody look at it from that angle before.

SPEAKER_03 33:26

So the fascinating thing was it actually in many ways took me back to the 1980s. Um it was really, really big on uh comments, adding comments everywhere. Uh it was really big on variable naming, uh, and it was really big on keeping the number of variables that are in scope down dramatically. Like it said, it did, and this wasn't just an opinion, it actually ran experiments. It was really fascinating because I started this off saying, you know, I would like to study or something, and it got it into its head that I'm some kind of scientist, and so it came up with an actual scientific protocol for running experiments, and uh so it would run uh tests against itself. It would actually write code in different ways and then clear its clear its context and say, okay, now do something with this code and look to see how effective it was. And so it found that leaving comments for itself describing uh what was going on and the context was really helpful. It found that long variable names was really helpful. But it also found that when you get above five variables in scope, whether they're parameters or regular variables, it combinatorially explodes the context. And it said that it was it it actually produced this really beautiful graph of what happens when you increase the number of variables to the accuracy of its understanding. So uh based on that, I've got like a really small skill file that just basically lays out those things as well when I'm coding. Yeah.

SPEAKER_00 35:31

Wow. Okay. Man, what a time to be alive. Uh this stuff is is so amazing.

SPEAKER_03 35:41

I gotta say, I was expecting it to produce code that was unintelligible to humans. I was expecting it to produce some kind of like encoded form that would be kind of like, you know, computer easy to understand. But given that it's actual, I guess, I don't know anything, but I mean I'm just guessing, that given that LLMs are basically trained on human context, that they work best when what they get is would be legible to humans.

SPEAKER_00 36:19

Um maybe maybe I would rephrase that a little bit, um legible to a mind.

SPEAKER_03 36:27

Yeah, okay.

SPEAKER_00 36:29

Yeah, and you know, the it's not coincidence, obviously, that that something that's legible to a human mind is also legible to a um computer mind. Because human brains are just computers.

SPEAKER_03 36:43

Um yeah, but it's more than that, though, isn't it, Jason? Because you got like they are they are trained in text. Right? So they are trained on the result of human thinking expressed as text, or maybe expressed as images or whatever else, right? So they are very unlikely on their own, I think, to come up with some form where it says, actually, I'm gonna program at the AST level. You know? I don't need to program using source code, I can just program an AST. Which, if you were just pure computer-to-computer, that would make sense, you know? It's an abstract representation that can be manipulated as a graph, way easier than code. Uh, but they don't do that.

SPEAKER_00 37:39

Yeah, well, okay. Um here's the angle I was coming from it, I was coming at it from. Um I'm thinking about like time and space complexity. Um, and to take your example of uh the number of variables in a scope, um, the more variables in scope, the more space that requires, the more stuff you have to hold in memory. And that's true of human, you know, human brains to me have RAM and disk, you know, because we have short-term and long-term memory. And you can only hold so much in your RAM, just like a computer can only an LLM can only hold so much in its context. And so uh LLMs find it easier to understand code with fewer variables in the scope uh for the same exact reasons that that humans do.

SPEAKER_03 38:34

I I could see that. I could see that as well. Um yeah.

Naming History And Scope Limits

unknown 38:40

Okay.

SPEAKER_00 38:41

Yeah. And so that's really interesting because um, you know, you're aware that I've been working on this book that I uh started to call the philosophy of programming, but now I'm calling software design from first principles. Um and one of the big things about the book is I'm trying to make arguments for objectively good software design. You know, how how much of software design can we say is objective? And there's it can be tough because like um why is it better to give variables clear, uh sometimes long names rather than cryptic names like X or something like that? Uh and the obvious argument is just like, well, it's obvious, but that's not really an argument, you know. Uh somebody could say, like, I think variables named X1 and X2 and stuff like that. I find that that's fine. Who are you to tell me that I'm wrong about that? But what you're talking about is like empirical tests for the understandability of a certain way of writing code, and that's fascinating to me.

SPEAKER_03 39:50

But understandability to a patent matching engine. Now I agree our brains are most likely also patent matching engines. Um but there's um do you know why people tend to call loot variable indexes i?

SPEAKER_00 40:14

No. Is it because it stands for index?

unknown 40:17

Ha!

SPEAKER_03 40:18

No. That would be too easy. Okay, but we normally have long variable names, right? Except we typically will have for i equals one to ten or whatever, right? And there are those people who religiously will say, you know, while uh loop underscore index underscore variable equals one to ten, they're just idiots. Um everybody is happy with i. And the interesting thing is the reason we use i is that in 1955 or 6 when Fortran came along, uh it had typing in it, it had integers and floats. And any variable whose name, I'm gonna get this wrong, but it was like I think it was ijk and l, I may be wrong about that, was an integer. And all other variables were floats. And so in Fortran you'd write a for loop as do 10 i equals 1, 50. And that's because i was an integer and your loop index had to be an integer. And so that's why we tend to use i as your loop variable.

SPEAKER_00 41:44

It's just a historical accident.

SPEAKER_03 41:46

It's a historical, yeah, but it's not. It's more than that. It has become a uh I don't know what the word is for it. A tradition or a convention or custom. A custom, whatever else. And that is I think there's a whole bunch of programming where those kind of um customs are adopted, uh, and we can't necessarily say why. Just that you know, at some point in the past there was a reason for it that we've gotten. So I'm not too sure you can say what makes good design on in any kind of objective way without taking about without taking some kind of note about that side of it.

SPEAKER_00 42:51

Right. Yeah, and I agree. And reality is complex and nuanced, and I think that uh things like what you just described uh have to be taken into account in any such conversation, because there's exceptions. Like, even if you're not going to call your variable in the loop I, um I've encountered many cases, as I'm sure you have, where if I use the entity's full descriptive, clear name in a loop, just the sheer size of that name uh gets in the way. The name constitutes then a large percentage of the amount of code in that loop, and it creates undue prominence for whatever that thing is, and it's a distraction, and when I collapse that name down to just a single letter, it becomes so much clearer.

SPEAKER_03 43:52

Yep. And I think actually that's a really interesting point. There's judgment there, right? You said It gives it too much prominence. And you would think that in a loop, the index variable was actually the most important thing, right? Because that's why you're doing a loop in the first place. But in reality, it isn't. In reality, it's just a convenience. And the fact that somehow you say, yeah, I know that. I don't need to worry about this. This is just I. But I am going to give prominence to the things I'm manipulating in this loop. That's a really profound ability.

SPEAKER_00 44:41

Yeah, that's a good point. It's like whatever the thing is that you're operating on, it's like, yeah, I get it. I'm not going to forget what that thing is that I'm operating on. The thing I want to focus on is what I'm doing to this thing.

SPEAKER_03 44:53

Yeah. Right. Which in a way comes back to functions.

SPEAKER_00 45:00

Okay, say more.

SPEAKER_03 45:02

Well, it's to do with not losing of separating out the mechanics from the uh state.

SPEAKER_00 45:13

Separating the mechanics from the state. Okay, what do you mean by that?

SPEAKER_03 45:17

So in a for loop, then the mechanics is the ability to iterate and change the value of some index. The state is the reason you wrote the for loop.

unknown 45:32

Okay.

SPEAKER_03 45:33

You want to add up a list of numbers or whatever it might be. Yeah. And so if you think the state is important, then you would probably have like a name like, I don't know, um uh cost of goods or something, right? And then you would have a total cost variable, and somewhere you'd have total cost plus equals cost of goods I. Yeah. You want to focus on the state, not the mechanism by which you're updating that state.

Abstraction As Lossy Precision

SPEAKER_00 46:10

And that beautifully brings me back to something that I wanted to bring up earlier. And I pulled this book off my bookshelf just now, um, Designing Object-oriented software by Rebecca Werfs, Brock, and some others. And there was a sentence that I came across in this book which mildly shocked me when I read it because it's just so such a stark statement. Um, the first sentence of a paragraph here says, Abstraction is the key to designing good software. Abstraction is the key to designing good software. I find that so interesting and just like what an unqualified statement that is. And it made me reflect. I'm like, huh, is that true? What do you think?

SPEAKER_03 47:07

I think it's true but trivial.

SPEAKER_00 47:10

Interesting. Why do you say that?

SPEAKER_03 47:12

Well, software is by definition abstraction. Um it is not the problem. It's a representation. Well, it's not the solution, I mean, it's a representation of the solution.

SPEAKER_00 47:28

And this this thing, you know, this this one sentence that I read drove me down a month's long rabbit hole. I guess I'm still down there. Um and it made me ask what abstraction is, and it made me realize that I really don't understand it. And I think I understand it now because I've thought about it a ton, but I realized that I I I wasn't even close.

SPEAKER_03 48:00

Yeah, I think people misuse the word abstraction. Um people say abstraction when what they mean is layering. Abstraction is the removal of unnecessary detail. And uh think about an abstract painting.

unknown 48:26

Right?

SPEAKER_03 48:27

An abstract painting, uh, a figure may what not have two eyes, two ears, a mouth, and a nose, right? But it's still recognizable as a figure. And an abstraction in that sense is a lossy process that lets you think about something.

SPEAKER_00 48:47

Can we use a different example? Because I think that one might actually be I'm not sure that quite hits the nail on the head. The one that I've been using is a wave in the ocean. Um a wave has an identity that is independent of the specific material that makes it up. Um and the reason that I use that example is to show that abstraction is not uh, I'm not sure if this is true as I say it, it's not a human-made concept. Um, abstractions exist in nature. Uh, there are more abstractions than just contrived ones that humans make up. And I also wanted to raise the point that an abstraction doesn't have to be very abstract. You know, a wave in the ocean is not very abstract, it's just a little bit abstract because we're not talking about the specific water molecules in the wave, because once the wave hits the shore, it's different water than when the wave started. It's this entity that's separate from what makes it up. What is a wave an abstraction of? What is it an abstraction of? Interesting question. I don't think all abstractions are an abstraction of anything.

SPEAKER_03 50:15

They have to be. That's the definition. Oh, why is that? Because an abstraction is something with unnecessary detail removed.

SPEAKER_00 50:26

Oh, well when we when we regard a wave, we are throwing away the information of what exactly makes up the wave.

SPEAKER_03 50:52

Okay, so by that definition, naming is an abstraction. Okay. Why is that? Because we throw away the content in order to give something a label.

SPEAKER_00 51:13

We throw away the content in order to give something a label. Can you give an example?

SPEAKER_03 51:19

You're Jason. Uh-huh. You're not, you know, the trillion water molecules and other stuff. I mean, in that way you're no different to a wave.

SPEAKER_00 51:31

Right.

SPEAKER_03 51:32

So I've called you Jason, I've called you a human being. And so by giving you a name, I don't have to think about the fact you're actually trillion molecules.

SPEAKER_00 51:41

Right, exactly.

SPEAKER_03 51:42

But I don't think that's an abstraction. I think that's a name. And I think there's a difference. Well, it's I think this has to be- Well, actually, maybe I don't think it's a difference. Thinking about it, maybe I don't. Maybe uh the same thing.

SPEAKER_00 51:54

Yeah, it has to do with uh levels of abstraction. You know, you you're not a doctor and I'm not your patient, so you're you're regarding me at a certain high level of abstraction, whereas a doctor might regard me at a lower level of abstraction, thinking about my body as a system and stuff like that. But that's that's not appropriate for this situation. What's appropriate is just to regard me, you're not even necessarily regarding my body other than what you see on the screen. You're more regarding my personality and mind and stuff like that. It's a very high level of abstraction.

SPEAKER_03 52:33

That's right. Yeah, I love you for your mind, not your body. Um, but uh okay, so if you take that definition, then why are you surprised by Rebecca Satan? Because by definition, the act of writing code is an abstraction. Doesn't matter whether it's good or bad, it's an abstraction.

SPEAKER_00 52:57

Yeah, well, I was a different person back then. I was I was not as seasoned as I am now, and so that it it it it struck me differently when I first read it than it than it would now after all this study. Um code, okay, so when you say code is an abstraction, I'm I'm not quite able to apprehend what you're saying yet. Um but maybe something that I have put my finger on is what we do as programmers, if if you buy this, is we design, build, and maintain software systems. And a software system is a collection of abstractions. Um and you know, I I think a lot of programmers think of an abstraction as something that is generalized, like you have two things that are similar and then you unify them and make that thing more general so it can cover these different specific instances, and so that generalized thing is an abstraction. And it's true, but that's not like the quintessential example of an abstraction. And with my wave example, I want to um really illustrate how like an abstraction does not have to be profound or generalized uh at all, um, but we invent abstractions to um package up different parts of the world to be able to regard them uh at the level of detail that is useful uh in our programs rather than a level that's too low or too high.

SPEAKER_03 54:45

I think that's that's exactly right. But if you uh and again, I think I think you're absolutely right there, but I think also you have to think about a slightly bigger picture in that the context in which a program is developed is also an abstraction. So for example, if someone gives you a requirement, well that's actually an abstraction over what needs to be done. Um all the way down it's or up, I guess, it's abstractions. Think about the way the company that's asked for the software is run, but the the CEO is not aware of every single molecule in their organization, probably not even aware of every single person in their organization, possibly not aware of you know entire offices worth of people. Um instead they work with abstractions, numbers, spreadsheets, diagrams. And that's what we do when we're writing software.

SPEAKER_00 55:54

Yeah, and I love that uh E.J. Dykstra quote um the purpose of abstraction is not to be vague, but to create a new semantic level at which one can be absolutely precise.

SPEAKER_03 56:08

Yeah. Yep. It's a I I get this wrong, but it's an it's an injection in a kind of algebraic sense, right? What you're doing is you're taking a domain and you're raising it up into a more constrained domain, so you can think about it, on the assumption that those two domains can be they're isomorphic, right? So the change in one will make a change, a corresponding change in the other. So it's it's an abstraction is simply a a co-domain for the original, which is more uh amenable to manipulation.

SPEAKER_00 56:46

Exactly. Yes. And I think this is both, you know, okay, so when I asked that question earlier, what do you think is the most important uh concept in programming? Uh apparently Rebecca Wurfsbrock thinks that it's abstraction. And so far I've been unable to come up with an argument that that is wrong. Um and and and the crazy thing is, it is simultaneously uh perhaps the most important idea in programming, or at least one of them, and something that hardly anybody ever talks about in any level of detail.

SPEAKER_03 57:25

So I think you've got to distinguish between programs and programming. So abstraction is probably the most important idea in programs.

SPEAKER_00 57:39

Yes.

SPEAKER_03 57:40

Because you cannot write a program without abstraction.

SPEAKER_00 57:46

Okay, you cannot write a program without abstraction. What exactly do you mean by that?

SPEAKER_03 57:49

Well, because every time you code, you're transf no, every program is transforming some real world activity into the activity of a machine. And therefore, it is always going to be a subset of the actual real world.

SPEAKER_00 58:18

Right. Like the program is kind of just an analogy. Like if you have an appointment scheduling program, every appointment in the database is just an analogy for the pro for the appointment in the real world.

SPEAKER_03 58:31

And also it's like your your calendar application says the meeting starts at 10, ends at 10.15. Right? But the user of the program knows that actually it'll probably start at 10.05 and probably overrun until 10.30, even though it says 10 to 10.15 in the calendar or whatever else, you know? Um so I think programs are abstractions always. But I think the programming is the context in which we program. And I don't think then that abstraction is the key driver of that. I think the key driver of that is what value are we adding, what features are we creating, what benefit are we bringing?

SPEAKER_00 59:23

That's an interesting distinction between a program and programming. Um because they are two distinct yet inextricably interrelated things. Um, I I I have a little bit of discomfort with the term programming, uh, terms like programming and coding and stuff like that, um, especially coding, because it gives a very different idea of what it is we're doing than what I think it actually is. Um what I think we're really doing is designing systems, um, and the programming and coding is just our effort to bring the system that we designed or are designing into existence.

SPEAKER_03 1:00:11

Agreed. And in fact, I think if you were to take that a step further, um I I let's still call it programming, just because I mean I like to be able to compare programs and programming, and it's almost the same word, and it just has more impact to me to say programming. But I think a good developer, a programmer will sometimes deliver a solution that does not involve code. Um a good programmer is looking at it from a systems point of view, not computer systems, but like, you know, worldly systems point of view, saying, what is the actual issue here and how can it be solved inside the constraints that we have? And a good programmer will not necessarily first reach for Visual Studio.

SPEAKER_00 1:01:11

Yeah, let me let me share an analogy that I think you might like. Um I don't know if this is a true story or whatever, but uh there's a hotel or apartment building, um, and the the tenants were complaining that the elevators were too slow. They would spend a lot of time just waiting for the elevators. Um and so what did they do to fix it? They didn't, you know, they could have tried to make the elevators faster somehow, but they didn't. They put mirrors in by near the elevators so people could look at themselves where they were waiting for the elevators, and the complaint stopped. And so I think that is analogous to what a programmer might do when they say, Oh, okay, we're getting this complaint. To be fair, a lot of programmers would probably start diving into the mechanics of the elevators and ask how can we make the elevators uh faster? But a more big picture thinker would say, like, okay, what's the actual problem? People are unhappy about waiting. That's the real problem. Let's make them stop being unhappy about waiting. Yep. And I think that's that's the kind of thing you're talking about, right?

SPEAKER_03 1:02:23

Absolutely, absolutely, yeah. And in in that respect, I guess it is an abstraction, isn't it? In that what you're doing is you're looking at the uh the statement of the problem, which probably involves average wait times and elevator speeds and all sorts of statistics, and then abstracting that away to the fact that people don't like to wait. You know?

SPEAKER_00 1:02:55

People don't like to be bored.

SPEAKER_03 1:02:57

People don't like to be bored. Yeah. So yeah, I mean, and it's actually kind of an intricate it's a it's an interesting example because there's like if you set yourself that problem and say, okay, how can I solve that problem? It's actually really cool to try and think of different ways you could you could solve that. You know, you could turn the buttons into some kind of game. You know? Uh or you could uh hint that there's some secret code that you can use to get the elevators to come faster. You know. Um or you could uh have like horse racing. You could have the two elevators competing against each other, you know, and then never whenever they stopped at a fall out at a floor, you could say, oh, you know, this horse stumbled and you know the other one's gonna get catch up in this kind of I don't know. But it's really fun to think about these problems and just try and work out what it is you're trying to solve, you know, and then and come up with like as many weird solutions as possible.

SPEAKER_00 1:04:12

Yeah, and you and you know how that problem would probably be presented. Um there would probably be some kind of elevator uh maintenance person, and somebody would go to that maintenance person and say, Hey, uh our elevators are too slow. Can you fix that?

SPEAKER_03 1:04:29

Yeah.

SPEAKER_00 1:04:30

Yeah. And it would take a very thoughtful kind of maintenance person to say, okay, you you're telling me that the elevators are slow, like what's really going on? Um yeah, and I think that is a uh that's a valuable skill for a programmer to develop.

SPEAKER_03 1:04:49

It is actually, I think, the most important skill for a programmer to develop. And in the era of AI, I think it's increasingly the most important skill because the ability to step outside and not just solve the problem that you're given is, I think, currently still a human activity. And I think it's the most valuable one that we can contribute.

PragProg Picks And Farewell

SPEAKER_00 1:05:21

Totally agree. Um, I think that is a great place to leave it. Um, Dave, well, before we go, is there anything you want to share with the audience? Links, books, any of that kind of stuff?

SPEAKER_03 1:05:37

What do I want to share with the audience? Love, peace, and pleasure, joy. Um also, I guess, um uh I know that books are somewhat passe in this age of instant information, uh, but I don't really believe that. Um so pragprog.com is always a good place for. programming books, including of course the audiobook of the Pragmatic Programmer, which stunningly is actually doing almost as well as the physical book. It's uh it's really quite interesting. It's also quite polarizing because uh it has a foley to it. It has like sound effects and stuff and about half people saying, oh this is really, really great. And other people going, I don't want sound effects in a technical book. Anyway, um so we have that.

SPEAKER_00 1:06:30

And is is it read by the author?

SPEAKER_03 1:06:32

No, it's well it's it's interesting. It's read by a professional reader um who I happen to know. And so we interact quite a lot. Uh so there'll be question you know at some point she is the book. And every now and then the book will say Dave I don't understand this and then we'll have a little conversation about it. Fascinating.

SPEAKER_00 1:06:53

Well I'll have to get that now.

SPEAKER_03 1:06:55

Oh there you go. Yeah I think we've actually got uh three three voice actors on it and you know little small sound effects and music and everything it's kind of fun. Oh wow okay so anyway uh yeah so there's that um I'm at pragdave me uh although not doing too much on that at the moment I'm kind of busy um but that's really about it for now okay and since you didn't plug it Dave I will uh well you kind of did the pragmatic programmer in addition to being an audiobook it's of course a regular book um and I'd like to think that everyone on the planet already knows about it and owns it but there's still people who uh are new and haven't heard of everything yet so dear listener if you're not familiar with Dave already and you don't know about his book The Pragmatic Programmer it is a bona fide classic and I highly recommend it.

SPEAKER_00 1:08:03

I have it on the shelf across from me in this very room um and then Dave has a newer book called Simplicity also so please dear listener check those things out and Dave thanks so much for coming on the show