CoRecursive: Coding Stories - Story: Learning a new language with Bruce Tate

Episode Date: May 6, 2020

There’s joy that can be found in language learning and pain as well. Whether you’re a beginner or an expert, there are still some things you can only discover by picking up a new language.  Bruce Tate will tell us how learning new languages rekindled the spark of joy for him. “I find that learning a new language mixes a lot of joy in that pain, and that's when I grow most rapidly as a developer.” “You can't break somebody else through their own pain. They have to learn their own lessons, and they have to, at some point in the model, they have to feel more and more pain to break through to the expert.” “When you visit other places, when you learn other languages, the world gets smaller.” Episode Page Episode Transcript Links: 7 Languages in 7 Weeks Book 7 More Languages Joy Talk  

and even though you get marginally better at what you're doing you're not doing the things that make you curious and joyful and the things that brought you into programming in the first place i think it's it's actually poison hello and welcome to co-recursive i'm adam gordon bell that was bruce tate his books about programming languages are super fun today he's going to tell us about leaving java to explore less mainstream programming languages and along fun. Today, he's going to tell us about leaving Java to explore less mainstream programming languages, and along the way, what he thinks is broken in our industry and, you know, how we might fix it. I started off by asking Bruce about his career as a Java developer. So let's see, I probably started writing Java in 96 and went independent in 2000.

You know, so you started off in Java, you left for greener pastures. And I guess what I know you from is your kind of books about seven languages in seven weeks. So why learn another language? You were in Java for a long time. Conceivably, you could have stayed in Java till today. Yeah, conceivably. And a lot of my friends did. So there's a big speaker circuit

called No Fluff Just Stuff. And just a huge number of the big Java developers were there. THH built Ruby on Rails and the Ruby language was attractive to me. I got on it just before the Rails framework blew up. And there was another guy though.

His name is David Thomas. And there was another guy, though, his name is David Thomas. And I was at one of these No Fluff Just Stuff talk with Dave Thomas, which after that time has become my mentor and good friend. And so I started saying, well, I bet Ruby can't do this and I bet it can't do this

and I bet it can't do this. And the consummate British gentleman stares me down and says, Bruce, shut up until you've done something non-trivial in this language and then come back. And so I went away and with a business partner named Justin Getland, we built this application and we built it in just a small fraction of the time that it would take to build a similar job application. I mean, because it was right in Ruby's sweet spot, right? It was babysitting this big fat relational database with very tiny web UI.

And there were a lot of things that can do that better than Java can or could at the time. So we did that. And with so much success, I started saying, well, this is a pretty significant competitive advantage. I lived in Austin, Texas, and there was a tiny town called New Braunfels, proper German name.

And they had this company called Autogas, which was a huge company with a small niche. And they basically started the auto fueling. And the problem was that after they started that business, there were all these customers that didn't want to go into the stores. Right. So it became this rewards company. Right. So that they had to incent you to go into the stores with great coupons. So that's why you always see these programs like, did you get your rewards today for your latest fueling?

But they were having problems with a particularly nasty job implementation. And I told them on just a raw gamble that I could build their system for one third of their cheapest build and actually did that and made a good amount of money with it. So that's how I got into Ruby. And then at some point, the same thing happened to me within Ruby that was happening to a lot of people. I was hitting a wall from a lot of perspectives, from an organizational perspective, from a memory perspective. And I read the same paper that everybody else was reading called the free lunch is over, right? So that was the one that said, as processors double in speed, we get the economy benefits and our industry benefits. But one of the things that's

happening is that we are not getting all of the benefits out of Moore's law that we used to, or for physics reasons, right? Because if you keep cutting a circuit in half and cut it in half and cut it in half, again, eventually the space between your circuits is going to be just several atoms thick. And that's what was happening. So we kind of hit this wall and we couldn't double things in performance anymore by just doing the same thing, by cramming the same chip into something smaller and smaller. What we had to do is we had to stack them like plates in the pantry. And when we stack them, the languages that work on them had to walk and chew gum at the same time. They had to be concurrent. And so I wrote seven languages in seven weeks because I was afraid, right?

I was terrified that Ruby wasn't going to get it, do everything that I needed to do. And kind of the cool kids that I knew were leaving the room and moving on to something else. And I was watching this happen, but I didn't know enough to know what the next thing was going to be. So I wrote that book and hopefully to bring other people with me. And then several doors opened. Wow. I wouldn't have guessed that you wrote it from fear because it seems like kind of a fun, oh, let's take a tour of things. Right. I mean, it started to be out of fear. And then that was really the time that I became a language buff.

There's a language called Erlang that I'm sure you're familiar with. But for your readers, I mean, for your listeners, the Erlang language is a language with probably a good chunk of the world's messaging traffic. It's a language that was developed at Ericsson, created by a couple of gentlemen named Robert Verding and Joe Armstrong and a few other people that aren't as well known. But Joe Armstrong actually got the first draft, the first two chapters I ever wrote on this thing. And I didn't know that he was going to get the two chapters. And the two chapters were Erlang and Prologue. And my editor just sent them and said, hey,

I'm sending this out for review. And I said, okay, cool. And then after a little while, I thought, who did you send those chapters to again? And she says, oh, Guy. And I said, I knew her by this time. I said, who did you send the chapters to? She says, it's Joe Armstrong, but it's going to be good. It's going to be fine.

So he writes the publisher back and almost kills the project dead in its drops right because i'm a new developer right of functional languages i don't know any of this stuff anyway joe's note was not the super kind gentle note that he is known right uh it was like i get this this book is in trouble i get the sense that this author knows Erlang very well, which was not true, right? I mean, it was based on his example, which is why he thought that I knew it well. He said, but this author knows nothing about prologue. And so anyway, I kind of tucked my pride into this tiny little bag and then just approached

Joe and said, hey, can you teach me some prologue? And he did it. And so doors started opening for me. You know, I noticed a couple of people that have been on your past show, you know, Edwin Brady, he did an interview for one of my books and Philip Wadler and DHH, I got to meet through on one of the early books. But it was a very exciting moment for me because Joe was so excited about Prologue and as his joy kind of bled off on, right? So we were working on this problem by Sudoku Salt. And does this a phone call or how are you? Yeah, just an internet call. Here I'm this nobody developer talking to Joe Armstrong, who's really one of my idols, right?

So I kept trying to code the algorithm for the software. And he said, less, less. You know, and I would cut code away and I would cut code away and I would cut code away until all that was left was the rules of the game. I mean, literally, it's like this thing has like nine cells and all the rows, columns and squares have to be different. And then I press enter and the solution pops out. Right. And, you know, I'm in I'm on a different continent.

And Joe is laughing. He is just laughing. And I'm saying, whoa, what's this about? Is he making fun of me? I mean, no, it's the joy of the language. He said, you just had your prolonged moment and I was here to see it. Right. So it was just a beautiful moment. And I mean, we were going to miss Joe Armstrong, but that was a wonderful moment to be on the phone and to share it with him. I mean, I didn't have any idea at the time about his affinity with Prologue.

It was great. And since then, I've kind of talked to Dave Thomas, to a lot of other people about why learning languages is so important. And I've spent a long time trying to internalize that. That's a great story. I did talk to Joe myself very briefly. When he put out his Erlang book, I got like the early edition. And then I emailed him a couple of questions. Yeah, he responded right away.

I don't think I had any extensive phone calls with him, but he was very available. He was. He was such a gentleman. I mean, he was the ultimate ambassador for that language. The ultimate ambassador. Just very kind. So you mentioned it briefly there, but like, why should people learn programming languages? ultimate ambassador for that language. The ultimate ambassador, just very kind. So you mentioned it briefly there, but like, why should people learn programming languages? I assume you're not using Prolog day to day, but you found it valuable in some way.

Okay. So I have spent many, many years thinking about this and I have finally, I think, settled on why it's so important. So have you heard of the Dreyfus learning model? No, I have not. So the Dreyfus learning model is an old Air Force model for teaching pilots. And there's some science behind it. And basically, there's this big old pyramid. So if you Google for Dreyfus, you'll find like all kinds of resources for it. You know, a lot of things are based on it, but there's this big pyramid. And on the bottom, you always have some flavor of beginner. And on the top, you always have some form of expert.

And the DRIFUS model believed that you taught experts and beginners and everyone in between different ways. So for beginners, you learn mostly by lists and by, you know, so Joe Armstrong eventually wrote the forward for seven languages in seven weeks. And he would say, so the way to learn programming at the very beginning, you're going to code the program side by side with Bruce, and then you'll add to the program and then eventually you'll be able to do it yourself. Right. And that's very much the way the DRIVE-US model works. So one of the things that's interesting is that when you're at the bottom of that pyramid, there's this thing called pain and there's a lot of it, right? So I'm working

with a mentoring program for women and minorities in tech in Chattanooga. And there's a man named Evan Miller that was watching me teach this woman a particular concept. You know, she would struggle with something and then I would kind of make a little correction and she would struggle with it. And then Evan would shake his head and she would struggle and I would make a correction and Evan would shake his head. So I finally got frustrated and I turned around and I said, what? He said, Bruce, she's got to feel her own pain, right? So at the bottom of that Dreyfus pyramid, and we all know it, right? So you can't break somebody else through their own pain.

They have to learn their own lessons. And they have to, at some point in the model, they have to feel more and more pain to break through to the experts. But we found that developers need to scale that pyramid so many times because the pace of technology is advancing so quickly. So I find that learning a new language mixes a lot of joy in that pain. And that's when I grow most rapidly as a developer.

And I've actually, that's kind of the model I've built my company around. There's a tiny little subscription that you get. And then we basically knock you down the whole mountain, the whole pyramid, let you climb up again, right? Knock you down and climb up again. Every two months, there's another language and you get to get knocked down the pyramid to climb up again. I think it's really important. So is it because the learning a new language is hard

or because it's fun? Yes. I don't know what, yes. Yes, it's all of that, right? It's hard. So there are a lot of things that are important here. So the first thing is that you get your brain, you get out of your expert's brain and into your beginner's brain, right? So that ability to go

from a one to two to three to four to a five, that's the core skill of a programmer. It's not whether you can code React or whatever. And it turns out, I believe that if you invest in people in this way, and people, there are companies, most famously Google, that have invested in this approach. Let developers play. And when they play, when they experience pain, and when they experience joy in the context of learning, magical things happen. I learned before there's like an HR type term for this. Is there? Yeah, well, maybe HR is not the right term. Maybe economics. The economic term is like discretionary input. So it's like input that people feed into their work that is discretionary.

That's like above their requirements. Yes. And I think that we ought to think of it like an investment, right? So I think that if you wind up clearing the deck for somebody for whole let's just say friday afternoon or friday morning whatever if you clear the deck magical things happen it turns out that you're going to the first couple of months it's going to be an investment you know it's not the sunk cost right that money will come back because that developer will get more tools in the box, and that developer will learn to learn more quickly. And as new technologies come online,

they won't be afraid to deploy them. It will 100% pay for itself. The way to turn a passionate beginner programmer to a passionate intermediate is to give them playtime. The way to turn a passionate intermediate to passionate advanced developer is to give them playtime. And when you do that, you get the benefit of basically lower cost for a little while. You get the benefit of somebody who actually enjoys what they do. And the endorphins that kick in when you're enjoying the learning process are just supercharging the whole development improvement cycle. And then what if I'm just a developer and I want to learn something new? Like how do I find time for that in my world? Yeah, so that's a loaded question, right? So there's a number of questions and one of is, where are the resources and how are they shaped? And

that's a problem because the resources for an expert are different for the resources for a beginner, right? So if you want to make a habit of going down to the bottom and climbing up to two or three, or maybe even a four in a language on a regular basis, then you have to have media that's not just a book or not just a video series or not just a test first problem, like an exorcism.io or something is a great resource for that kind of thing. So that's one problem, right? Is where do you get the media? The second problem is how do I get my boss to buy off on this concept? And those are difficult problems. And of course, we're trying to, we have our take on it.

We believe that you have to have multiple types of media to learn. So we have links that you can go off and read, tiny problems that you can go solve. We have a piece, a slice of a book, a slice of the video. But whatever your take is, this is all kind of new stuff. And some people believe you shouldn't script the fun. I think that you can and you should script the fun and that if you do script the fun, you learn more quickly. Other people believe that, well, gosh, as soon as you start scripting the fun, it becomes not fun anymore. You don't get the same endorphins. I don't know. I don't know

the science behind that. But yeah, so that's hard. And it's also hard to make a case to management that, hey, I'm going to do something that is other than what you told me to do and you're going to be happy that I did it, right? So that's a statement of faith. And so you basically have to be able to defend yourself and talk about the test cases like the Googles

and there are a number of companies that I work with that do the Friday projects. But the people that do them and make that investment, their developers tend to grow. A complete non-answer, right? No, no, it's an answer. It's tricky. I get what you're saying. What about, if I can push on this issue, what about if my work is not collaborative with this? If I just need to do my job, how do I prioritize learning in that type of world? So I believe to be a healthy developer, I mean, there's all kinds of studies. I just gave a talk in Bangalore called Joy.

And I wanted to give that talk in particular. It's a functional programming conference, but I wanted to give that talk in particular because we're starting to notice that Mumbai and Bangalore developers under stress are developing heart problems at the same rate and even a more extreme rate than similar groups in the United States do. So I wanted to give the talk that says, hey, you have to take care of your career. You have to work on finding your joy. You have to do things that make you curious and take you away from your day-to-day programming profession.

And your value system, that is the Western value system, isn't considering all of the facts. So I've been thinking about this, and I think that the way that we're building developers is wrong. I think that we don't think enough. I think that we tend to build people to the point where they can do these repetitive things very quickly to the point where they don't enjoy them anymore,

and then we ask them to keep doing them under more and more pressure as the code bases grow and with raising expectations because now you're maintaining a larger and larger code base doing the same thing and then we're not giving people enough breaks to and not just breaks to walk away from the keyboard and take a walk but that's important but breaks to allow the brain to grow in other ways. Yeah, I would agree with that. And the whole service industry, which a lot of the Bangalore kind of world is billable hours,

I think that is just stressful in and of itself. It's very tightly measured. It's broken, right? Yeah. It is broken. So you add to the fact that they're basically upside down from the United States where a lot of those companies serve, right? So you take a highly, highly motivated population that lives probably an hour and a half out of town because everywhere is an hour, hour and a half from where you work.

Yeah. Right? So you build in three hours of the day. Then you say you have to be around on both of the margins, right? When people come in and when people leave, and you have to be productive during the rest of that time. And that's a recipe for killing a generation of fathers that never know their kids. I think it's a really difficult thing. So the nice thing about being at the functional programming conference there was that many of the leaders in Bangalore were there.

And I was able to give that talk that said, hey, don't discount your personal passion and your joy. You know, so I saw people that were 40, 50 just break down and cry because it resonated so well. I don't think that they're alone. I think that we have a whole generation of developers in this country. I mean, if you think about the pattern, is that we were successful with the software development model.

And we say, hey, keep doing the same thing. And more and more tickets, more tickets, more tickets. Then at the same time, we're growing the code base. We're not providing time to refactor and make code base better. And even though you get marginally better at what you're doing, you're not doing the things that make you curious and joyful and the things that brought you into programming in the first place. I think it's actually poison. It's great talking to someone like Bruce,

who's been in the industry for more than five years. Our industry is so young, and I think we have lessons to learn. One of them is what Bruce is saying here. You can't build a long career at a place where the work is never fun, where you just have to crank out ticket after ticket. There's a related question that I wanted to ask Bruce as well. Does learning a language have to have some payout in career aspirations? No, no.

Learning languages, I mean, for Joe Armstrong, it was the prologue moment. You know, as I wrote Seven Languages in Seven Weeks, I didn't expect to sell a single copy of that book. That was about bringing people on the joyful journey with, right? And in an age where every publisher is trying to strip the personality of a book actually comparing languages

to movie characters that just didn't fit right and so what i was trying to do is move a person's head with me as i went from page 89 you know the end of io and to 90, the beginning of your prologue or whatever, or, you know, when you went from prologue to the functional family of languages, I was trying to bring people along in the journey and move their brains. I don't really care about, I don't know. The payout is secondary, right? So the payout, the joy is the journey, right? So I have this coding club at a high school in Chattanooga where a lot of the

kids don't have their own computer. So we basically just pair around a problem. So we were working on Tetris at the time. And we throw out the t-shirts for Groxio and for our conferences and I kind of strut in. They love them. But the favorite t-shirt that I ever saw there was a t-shirt that said, I hate programming. I hate programming. I hate programming.-shirt that I ever saw there was a t-shirt that said, I hate programming. I hate programming. I hate programming. It works. I love programming. I said, yes, that person gets it. That's the joy, right? That's the tinkerer's joy. I always found that like side projects can be very enriching sometimes just because you get to throw away, you know, like a professional world,

you tend to, there's deadlines, there's things to do. And then if you just get to build something on the side, you know, and in my mind, I'm like, whatever I'm building here is going to change the world. But actually the fun of it is that it doesn't actually matter that I can just build it and throw it away and there's no bug reports or whatever. So there's a great talk at a conference at our lunch or our lecture conference in Austin. So the talk was the Royal Bank of John John, right? Where this guy said, hey, there's this framework called Nerve so we could code stuff. And so what I really want to do is put an ATM in front of Amazon. So he actually made this, you know, this hardware software project that let the kids put in a card and pay with John John Bucks.

His name is John, right? And actually pay for products on Amazon. And they would kind of teach their kids financial responsibility. But he had more fun with that project. Never use it for anything beside the house. But he had more fun with that project than anything. So I completely agree with you. So what if I just ask you some questions about languages? What's the most fun language that you had fun learning? So there's a lot of different categories there and I'll answer a few

of them, right? So one of the questions, one of the things is what's the most mind bending programming languages, right? And there are probably three. One of them is a language called Elm from a guy named Evan Cieplicki. And he worked for Prezi for a while, worked at NoRedInk for a while. And that language was a user interface language, but it was strongly typed. And it was a beautiful React-style flow, but it worked that way end-to-end. And that was just mind-blowing, right? So Evan had built this Mario game, and you could code on it a little bit here and change

the parameters, and suddenly Mario was jumping higher. So that was mind-blowing. So the second one, you've had Evan Brady on the podcast before. Yeah, yeah. He has this concept called dependent typing. Well, not him, but there's a research field called dependent typing, where you build not just the character of a type in, but also values into the types as well. So that if you have a list of six and a list of seven, and you add them together, you have a list of 13. And what was interesting for me about that language is I kept saying,

I don't get it, I don't get it. I was just grinding through these types and having a horrible time. And then so I ground through the types and says, oh, man, the functions are going to be terrible. And then I started using the tool, and I kept pressing tab, and the program just wrote itself. I said, oh, I think I can see where he's going here, right? Because, you know, once you had all the thinking done in the language itself, the rest kind of wrote itself.

So that was really cool. Yeah, he had an example in his book where I think it was transposing a two-dimensional array and like you didn't even type anything. It was just like hitting buttons. And then it was like, you wrote out the type and then you kind of auto complete auto complete auto complete right right it was insane yeah i mean and so i had a very similar experience with run length encoding like a zip algorithm so yeah that was cool so the third one is there's a program called mini camera which is closure meets prologue which was absolutely mind-blowing so i wrote about that in seven more languages in seven weeks and actually it was jack muffet i believe that wrote about that language and it was so stunning

he had the story algorithm he had like a story generator that was cool, that would basically take these beginnings and these ends and weave together a plot in between based on facts and language, right? There are certain languages like Smalltalk that are beautiful, but flawed in fundamental ways, right? Like Smalltalk, it's great to work in until you have to extract the freaking program from the image, right? You can't get it out to package it. It's like, where's the line around this program?

Well, with Prolog, it's input-output. And so when you can marry Prolog with a language like Clojure that is about as extensible as a language could be, beautiful things can happen. So I like those three in those ways. So I think that Elixir is a really cool language. That's my favorite at the moment.

I like Elixir because it has this idea of OTP, which is super advanced, right? Simple concepts that kind of grow up in an advanced way. Have you ever seen the IT crowd, the British company? I have. I have seen it a little bit. Yeah. Did you try turning it off and on again? Right.

So that's every episode built to answering questions. Did you try turning it off and on again? Right. So that's every episode built to answering the question, did you try turning it off and on again? Well, that's OTP, right? So if you have a little server and anything breaks, it'll shut it down and turn it on and last in a good state. So I like that. But I also like that I can take my beginners and I could teach them Elixir. And there are simple transformations. We do them in Elixir and pipes, which means you feed the output of one function as the input as a first argument for another function. And when people see pipes, they say, oh, I get it. I get that you can build a

program as this series of transformations. So yeah, those are some of my favorites. And the last two that I've explored, there's the Crystal Language, which is kind of like a high-performance Ruby, which is cool. A fully typed Ruby. And they get a lot of the dynamic feeling of Ruby, but instead of doing it with opening the classes, they get it with MapWorks. And so that one is wild. It's just all the things that I thought wouldn't be possible with stronger typing, you can

get about 90% of the way there. So that was fun to see. Yeah, you would think a strongly typed Ruby is not anything like Ruby. Right, right. Well, it turns out it's pretty different, but the programs look very, very similar, right? So they did a lot of investing in their macro system and a lot of investing in type inference. And so they got surprisingly far, I would say.

And then the last one that was interesting was a language called Pony. Have you talked to any of those folks yet? No, I had a request from somebody to interview somebody about Pony before, but I'm not familiar with it. The one you want to talk to is a guy named Sean Allen. He's just a brilliant guy. So the guy who built it is a guy named Sylvan Klevich. But it's a really fascinating language because they built in, it's this C-like language in terms of performance with typing that's turned up to 11. So really, really extreme typing.

And they bake into the language this concept of reference capabilities, which are part of the types. And a reference capability won't let a program compile if there were any concurrency type conflicts in there. Oh, it sounds a little bit like Rust, I guess. Yeah, but more like 100% safe on the concurrent level, right? So Rust solves it for a narrow window of the system. And it's very much cooperative, right?

And with Pony, if anything is broken in there from a type perspective, it won't compile. So you spend a lot of time fighting the type system. But once you beat the type system into submission, your program works. And it will work. So I like language creators that try to think of language creation from a completely different perspective. And that one's interesting because it said, well, what if we had the performance of C, which allows copyable... One of the problems with the Elixir language is that you can't do high-density in-place computation because everything is immutable, right?

So with Pony, everything is mutable as it is with C. And they're just type rules that enforce concurrency safety. So it's kind of cool, right? And to see that applied in the places where they did like financial systems. I feel like this might just be my own feelings. There's always a danger when I learn something new that I want to use it a lot in like places that maybe it doesn't fit. Oh, that's terrible.

Yeah, man. When you really engage that curiosity and get so hooked on something that it looks interesting enough to actually jump into your bag of tricks. Sounds like a bad thing. No, I guess I mean that. Yeah, I don't know. So let me say it this way. If you learn like you're a Scala yeah, I don't know. So let me say it this way.

If you learn, like you're a Scala developer, you like currying. So currying is, when I think in terms of currying, even when I'm building frameworks in Elixir, there are problems that I will carve up that way. Yeah. Right? Having been exposed to Scala and languages like it that effectively curry. And Idris was another one. There are languages.

So there's a man at our conference. We had a back and forth on a podcast there called Elixir Outlaws, I think. And he was talking about embracing the joy of programming. And one of the things he liked to do is code games that he liked. And I mean, board games, not like Tetris, right? So he loved to code this program called the longest or this problem called the longest road and settlers of Catan, which is a common board game. Right. And that's a prologue problem.

And so I told him so. And I said that it's really interesting that you struggle with that problem in Ruby, but you were excited about solving that problem in Elixir because the guy who created Erlang loved Prolog, which is the ideal language for that problem. And that's why your solution gave you so much joy in the language and the genealogy of Elixir. yet Prolog. And that kind of led to the four comprehensions, which were kind of created by Prolog's unification. So I think learning languages changes the way it provides tools in the back. It doesn't necessarily provide something you use every day, but it gives you tools in your toolkit.

It strikes me that maybe you're a perennial early adopter. You're a very curious person and you hit Java on the upswing and then you hit Ruby and... Yeah, yeah. And get some advantages out of that. Some disadvantages too, right? So I made some mistakes that I could make it better.

I can tell you about some time. I adopted some stuff that was a little early and we were okay. Mostly we were okay because we were building on such high leverage technologies because we were willing to pick our eyes up and we were willing to say, okay, what can I build with a small number of very good developers? What can be built with a small number of very good developers? I feel like everything good was built that way at some point. You know, around 2007, I got the book Programming Erlang

that Joe Armstrong wrote that we've been talking about. And it was just so much fun. And I was always telling all my co-workers that we should be using Erlang for things, which we never did. Which kind of gets to Bruce's point about how sometimes just learning things and exploring your curiosity is just a way to like enliven yourself and your career, just to bring some of the joy back to it. I think it's a great message. And I recommend people check out Bruce's talk called Joy. Before I let Bruce go, I wanted to check in with him on whether he agrees with me that people

should be spending more time doing this, just playing with weird technology just for the sake of it. So if everybody has followed your path and learned a number of languages, how is the world different? I say that there's less fear. I say that there are, just like when you visit other places, when you learn other languages, the world gets smaller. We all know people who treat our favorite database model as a religious platform, or our favorite framework as a religious framework. When you've seen a few, maybe not so much, We talk about things in terms of their strengths and weaknesses. We're more able to adapt new things and programmers are happier and healthier. Sounds like a good world.

I like it. So this has been great, Bruce. Yeah, for me too. Thanks for the invitation. I really, really appreciate it. I saw DHH's talk and I thought, yeah, I really appreciate your interviewing style. I don't know if you're really good at this. Oh, thanks. I try. I don't know. That was the show. Sorry I got it out a bit late. I did actually reach out to Sean Allen, who Bruce introduced me to. And so there should be a super interesting interview with him coming soon.

Stay subscribed to the podcast if you want to hear that. It seems like Bruce might be a great resource for me, able to introduce me to all kinds of interesting people. Until next time, thank you so much for listening.