Crafting Code Podcast

[00:00:17] Allan Stewart: Welcome to episode 17 of the Crafting Code podcast, where we discuss the importance of doing the right thing at the right time with the right tools. I'm Allan Stewart, a software architect, and lately I've been thinking about the inter-connectivity of software development practices.

[00:00:33] Dave Adsit: I'm Dave Adsit, a technologist. I've been thinking a lot recently about balancing systems to avoid resource starvation and resource queuing.

[00:00:42] Matt Baker: Hey, I'm Matt. Lately I've been thinking about switching to a Mac from a different operating system because it's something that I did this week.

[00:00:50] Allan Stewart: Our episode topic today is programming languages. I like this topic because it really fits in well with the whole concept of crafting code. If we're going to write code, if we're going to be professional about how we write code, we have to write code. And that comes in a coding language, a programming language of some sort. So to kick things off, what are your thoughts, Matt, about about how programming languages relate to this idea of crafting code?

[00:01:19] Matt Baker: Well, I have lots of thoughts. I'll open with one that extra sticks out to me. I think of your programming language as your tool. An analogy I'm sure everyone can anticipate is like a woodworker with their tool or, you know, some sort of craftsman working with an actual material, their tool. And I think of programming language like that. And so it's from that space that one One of the first things that come to my mind is the tools you use influence your end product. And especially on the topic of programming languages, how complex your tools are will contribute to the complexity of the end result of your product. And I've always found that to be an interesting kind of squishy thought, but it definitely makes me look critically at everything I need to do in order to ship something in a particular programming language.

[00:02:08] Dave Adsit: Borrowing on your analogy a little bit, I think about the way that a craftsman works with tools, and, you know, sometimes, like in woodworking, sometimes you make your own tools, often you make your own tools, and they may be single purpose or they may be the tools that you use for a long time, but you also buy some really nice professionally made tools to accelerate certain certain pieces of the work. A good craftsman can make a nice output with simple or poor tools, and a novice can make a huge mess regardless of how good the tools are that they have in front of them. I think about that a lot when it comes to building software systems and the tools we choose to use for them.

[00:02:54] Matt Baker: Yeah, I have kind of this, I don't know, this feels like a meta topic, which sometimes they feel like they go nowhere, but this one I think is interesting. The tool you use to keep riffing on what you're saying, Dave, and then I'm thinking specifically about a programming language right now, but that tool, I think it has a pretty dramatic impact or influence on how you think about the problem as you're solving it. So like as you're working in it, right, it kind of puts you into a scope where certain things are possible and certain things aren't possible. Like if you're in, I've been thinking about F# lately, if you're in F#, if you want to put a file into the directory structure of an F# project, it compiles top to bottom. So you can't reference something in an upper file that's not stated until a lower file. And it's just based on the way it's read off the disc that changes the way you think about the problem. In some cases, it's pretty annoying. In other cases, it works. And sometimes it seems kind of cool, but like at any rate, the way you solve that problem, given that constraint might be different than when you don't have that constraint. So that's maybe a more more extreme example, but I do think it scopes your thinking and the result you produce might change if you use F# versus C# versus node versus whatever.

[00:04:03] Dave Adsit: I completely agree with that. That's been my experience as well. I think when it comes down to it, every programming language we use is Turing complete. So presumably you can express any of the programs you need to write in any of the programming languages available at our disposal, but how do they end up? What do do they look like? What's the habitability? What's the maintainability? What's the readability? There's that joke about Perl that it's just executable line noise, right? And that the easiest way to debug a Perl program is to create a new file and write it again from scratch. I don't know. I don't have any experience with Perl, but that's what I've been told.

[00:04:42] Matt Baker: I've got lots of thoughts coming now. I think also there's the relationship between someone one and the tools that they pick. As you go on in your career and you get more wisdom, I think you start to choose better and better tools. But I'm sure we've all been at places where it was clear the wrong tool had been applied. And then the feedback saying that this is the wrong tool, you shouldn't apply this, that feedback's just ignored. And they just kind of doubled down and continued to use the wrong tool. Or maybe it was the right tool at some time and it's no longer the right tool now because of a change of context. I don't know what you would call it, but I do know that as you get better at building software, and to this point of, like, how to programmatically just relate back to crafting code, like, if you want to craft good code, you're probably going to screw it up a lot at first, but eventually you'll start to understand which tool applies to which scenario. And sometimes it's subtle and it's hard to detect. There's an interesting relationship there because

[00:05:32] Allan Stewart: some tools fit certain jobs better than others, but on the flip side, you can craft good code in probably any language. Like, I don't know that it matters what language you're doing. Like, there's exists a way to write good code in that language. Just like what Dave was talking about with the mess. Give me any programming language and I'm sure we can find some just horrific code that is problematic in multiple levels. Sometimes we see it really at a surface level and we're like, "the syntax of this, I'm not used to it. And so I don't like it. It makes my brain have to stretch a little bit to remember that there's a different operator for string concatenation or for or accessing a method on a class or something like that." And so it's really easy to fall into these really superficial judgments around languages. However, some languages also just have stigma about them. It's not always fair. Poor PHP, the double-ended claw hammer joke image that's on the internet. It's not fair. There's some great programmers out there that like write really clean PHP. They're using modern practices like dependency injection and they're adding all kinds of features to the language, but that doesn't take away the years of poor coding practices that were spread throughout the internet. It doesn't take away all the stack overflow posts that you can find where somebody gives you an example, like here's how you can solve the problem that has a security vulnerability that they hadn't noticed or that has some other bad practice that makes it hard to unit test or something else. And so there's an environment that surrounds the language that influences your product and how the tools work just as much as how well you can express the problem domain in the code.

[00:07:24] Matt Baker: It's really interesting. And your comments about PHP make me think of this funny presentation I saw one time where a guy got up in front of a room, put up a slide that had a number of string manipulation functions on it, like length or slice or search or find or index, and there were a lot of the same function. What were clearly the same functions given different names, like string underscore slice versus substring versus, like, str slice, and he's like, "look, as you become a programmer, it's really hard to navigate all these programming languages with all these different variations on common operations." And then you click to the next slide, and he's like, "and these are all just in PHP."

[00:08:07] Allan Stewart: Yeah. Yeah. It's, it's near to me right now because I'm working with teams that are working on a lot of PHP code. There are some good practices that we can apply there and I'm trying to help them understand unit testing and SOLID principles. But then there's sometimes just things, the way that method calls can be expressed as strings or the lack of generics, because you just throw everything into an associative array, which is really great at times and then really terrible at times when you're trying to navigate through the 17 different code files that take you from the UI down into the database.

[00:08:46] Dave Adsit: That has me thinking about the philosophy behind each programming language and why it came into being. The one that has the most well-known and understood is probably Python. There's a manifesto about why Python. I think there's probably manifestos for a lot of programming languages, but if you think about the context of why a language came to be, the idea with Ruby was, "hey, what if it were just fun to code and I didn't have to deal with all these restrictions that I have in C? Sure, we'll have AND as an operator and a single ampersand as an operator and a double ampersand as an operator. And you can use whichever one you like. They all mean something slightly different, but don't worry about it." That's kind of cool. That's a cool design choice that they made. Then there's languages like Java and C# that were like, "you know what? We really, really like C++, but you know what? We're bad at pointers. Also memory management. And so let's add garbage collection and let's hide the pointers." Then those two languages were born at about the same time. That was kind of the fundamental philosophy. And I coded Java for a little bit and a lot of C#. And I'm like, "yeah, that was the right choice. Good job, guys." Meanwhile, the Python and Ruby folks are like, "what kind of new devilry is this?" But I think that one of the important things about a programming language is try to understand what the philosophy behind the language is and whether the philosophy of the language matches the problem set that you're working on. And then add to that the environment or the ecosystem of the language. How is package management handled? How do people consider editing the code? Is it Vim or Emacs? Or do you have to have a proprietary IDE or somewhere in between? We've probably all worked in all of the different toolkits. I remember writing a lot of code with Notepad and Notepad plus plus, which was a lot better than Notepad.

[00:10:58] Matt Baker: It was, it really was,

[00:10:59] Dave Adsit: but also a lot more complex.

[00:11:00] Matt Baker: I had an FTP plugin that was.

[00:11:05] Allan Stewart: Oh yes. Very nice. I think it's interesting to think about within that ecosystem, system, there are benefits and drawbacks around what has become idiomatic for a language. You can see this a lot with languages like JavaScript that have evolved a lot over time. And you take somebody who did JavaScript back in the IE6 days, and you show them what people started doing around ES6 or so, and just how different it was. And there can be some really different approaches. Like some people really want to write their JavaScript in a functional way. They're using, like, const and let, and there's no semicolons anywhere. Comparing that to how code used to be written, it makes a big difference in how people approach the code. So I think about that. I think about how consistency is probably the most important thing. If you're working together with a team, working in a group, you want to be able to have some consistency in how you you write your code. You don't want to be constantly with every single git commit changing the formatting of the page because everybody had a different preference or something like that. But it's interesting because there's a lot of that idiomatic code gets into your system. And sometimes it's great because it helps with that consistency. It helps with understanding code online, but also in that environment, in that ecosystem of the language, a lot of the time, the examples, the things that become idiomatic aren't necessarily there for maintainability or for readability or to keep your framework at bay. If you go to look at how to use the thing with the framework, they're going to show you how to couple to it like nobody's business so that they can ensure that they stay together with you. And it's a lot easier to read, right? Like their framework seems really complicated if they have to add in these extra layers of abstraction.

[00:12:56] Matt Baker: abstraction. My mind goes a lot of ways thinking about what you just said. I'm thinking about, like, this point, you should use a tool how it was designed to be used. And we called it out with PHP as well. And it's hard when the way the tool should be used changes so much. I agree with what you're saying. Like, if you're going to responsibly adopt a framework, you need to, like, oftentimes you need to abstract a little bit away from your system. But even then, like the points of abstraction that you should introduce, like, it can kind of, they can change as the updates change, or things you did do may no longer work, and it, it's hard to always respond to that change. And, and I think I've, the thing I've seen as companies grow, at least places I've worked anyway, you pick a tool and, and you use it right for a little while, and then, like, you start to contort it, right? And you you start to do some interesting things with it. And sometimes you're just like, we mentioned this a little bit ago, like, sometimes it's very clear that what you had was no longer right, or at least the way you're using it is no longer right. And keeping up with that, you know, the places I've seen do it really well, they just bake into their week, uh, time to do things like that, right? Like some places I've seen do, like, one in every five days, or, um, I don't know, once a month, they take take three days or something, but there's some scheduled thing that says, "we'll do stuff like make sure the way we're using these tools are still appropriate given our current context."

[00:14:30] Allan Stewart: I like that. There's a lot of reasons why you might want to have those things be updating. The industry is always changing. The programming languages themselves are changing, like you mentioned, but then there's also, like, frameworks and other things where you might come up on a new a new concept. I remember in one code base that I worked on, we decided that we wanted to start using the maybe monad in C#. It actually was really cool how we could change how we expressed some of the logic. I think it was awesome, but we had to spend the time to introduce that and be consistent with it because if 20% of the code base used that, but then the other 80% of the code base is still returning nulls everywhere, then you're going to have a bad time. So those changes can be complicated, but also it's kind of represents your evolution. If you just stay stagnant, you're not going to be happy. And for programming languages, recent changes in the JavaScript ecosystem have really improved our ability to write good JavaScript and build much more complicated apps than we could tackle in the early days, with the browsers changing along with it, of course, too. I also really like C#. It's probably my favorite language. And it's really interesting to see as it evolves more and more functional capabilities like immutable records and things like that over time that have made it easier to do what I want to do. But it also means there's that transition that you're talking about, Matt.

[00:15:57] Matt Baker: What's your favorite part about C#? You said it's one of your favorite languages.

[00:16:01] Allan Stewart: Well, this will take us down a rabbit hole. Maybe we'll have to come back to some of the things I mentioned, but I think just generally speaking, I have a preference towards strongly typed languages. So we should come back and talk about that in a bit, but C# does a good job of giving you a lot of those types. It's got strong type inference so that you can quickly navigate about a code base, especially as it gets complex. I love writing just like simple things in JavaScript where it's easy and it's dynamic. But as soon as I've been in the same code base for 30 days and I look at the thing, I'm like, "what even is this? What properties are on this object? I can't even remember, and I have to, like, debug it every time to find out." Then I get sad. So yeah, like, just I think it's, it's a good expressive language that figured out how to be a better Java without having too many service bus impl factory abstract generator decorator pattern things that were were very prevalent in the time when I was writing most of the Java that I wrote. And so C# felt like a better Java to me in my circumstance at the time.

[00:17:13] Matt Baker: I have a friend that says C# ages really well. And I agree with that. Like it consistently seems to figure it out. Right. And it seems to keep up and it's impressive. Like, I also agree with what you said. I think Java, I feel like these are like shots fired kind of words, but I think Java has fallen behind. C# between the two is the clear, clear leader.

[00:17:35] Allan Stewart: Some of it is just my own stubbornness though, too. Right. So like there's some other cool languages out there. Like, I mean, F# is pretty cool. The Haskell, Scala, like those seem like things that I would like to play around with, but then I'm like, "Oh, the syntax is just enough different. I'm lazy. I don't want to learn." And so that sometimes restricts my changing and exploring these other new languages because it just feels like if I just wait a year, then the next version of C# will have the thing I want. I mean, they gave me already the thing that I really wanted as a Mac guy. You know, I was born and raised a Mac user. And so when .NET Core came along, that was it. Finally, the marriage of the two things that I really wanted to do, C#, Mac OS.

[00:18:23] Dave Adsit: Which honestly, that was a thing that held C# and .NET back for a long time. I think that it comes back to the philosophy of the two different virtual machines. The JVM philosophy was, "here's Java, and it's good enough for all your business apps. And if you want something else, just create another language," which is why the JVM has so many languages, Clojure and Scala. And I don't even know because I haven't done any JVM for 15 years. But there's a bunch of different languages on the JVM. And when the CLR came out, they're like, "we can do that too." And then they immediately stopped supporting all of them. All my IronRuby and IronPython went into the recycle bin because the only languages that really get support on the CLR are C#, F#, and VisualBasic.net, which I think is now just Visual Basic again. Oh, really? But because of that, in order to stay relevant, they had to evolve, which means that C# is constantly adding some of the coolest features, I think, like LINQ, the language embedded query language or querying or whatever, and generics and type inference and, like, all the things. And so it's really cool to see the language evolving and keeping up with the industry. And I think that Java is seeing that and starting to catch up as well. Like I've also got the feeling that Java is behind, but that's partially because there have been so many other options. I think if you're doing Android on the JVM, you are almost definitely going to be writing Kotlin, which from what I can tell, looks an awful lot like Java, which probably has got a bunch of Kotlin people already mad at me.

[00:20:17] Matt Baker: I will say I worked on an Android app, uh, on a little side project for the last couple years, and it was in Kotlin, and I really liked it. I thought the language was pretty crisp.

[00:20:26] Dave Adsit: Yeah, which, it's just different philosophies. Evolve what we have or create new. And that's the choice that we are faced with every single day as developers. Do you evolve what you have or do you just create new?

[00:20:43] Allan Stewart: It's not just a developer choice. It's also a strategic business choice. What programming languages are you going to use in the thing that you're building? And I say languages because in my experience, you almost always have several. Pretty much everybody uses JavaScript in some fashion, but you're probably going to be using something like, you probably have a database and it probably has a language. It might not be like a full-fledged programming language, but it's something else that you have to know. A lot of times the backend language will be different from the front end language. And so that's a choice that you're making. How is it going to impact you? There's the whole idea of the right tool for the job, but can you hire developers that are proficient in that stack? Are they going to cost you more?

[00:21:25] Dave Adsit: When you say stack, that's what it feels like is if you start at your database, you're learning some flavor of SQL or whatever your database technology query language is. So you've got your SQL and then you've got your backend language, which could be anything, Ruby or Python or Clojure or C# or JavaScript or whatever. And then you've got to have your front end toolkits. And there's things like, do you consider HTML to be a language? Maybe you don't even write HTML because you just write JSX, which looks a lot like HTML, but is definitely different. Front. And also, are you writing JavaScript? Or are you writing TypeScript? Or are you writing Elm? Or, like, what are you doing on the front end? And there's a lot of choices there too. And so by the time you've actually stood up a website that does anything interesting, you've got at least a handful of languages that you're using on a regular basis. And that can be be a challenge to even know which ones to pick because there's an almost infinite number.

[00:22:35] Matt Baker: I feel like this programming language is a strategic business choice gets downplayed or just, like, outright neglected so much. So, so much. And I have some, like, some optimistic and some cynical theories as to why, but I definitely think that it does. It's hard for me to this whole, I don't know, this thought's kind of squishy in my mind. So it's hard to express clearly, but there's this thing that happens when you go to pick a language as a programmer. If you're, so I'm going to scope this. If you're in a position where you get to choose the language that someone who's paying you is going to be saddled with, like a new company or a new project, whatever, you get to choose the language. There's something that happens there, and it goes any number of ways in the programmer's mind. But if we're being real, like, some of those ways are, "what would be interesting right now? Like, what would be a tool that I would enjoy using?" And I don't think that's always wrong. Like, sometimes I think if you're a smart employer, you'll say, "Hey programmer, you get to do whatever the hell you want. Like, you are in total control. I recognize your jurisdiction here. Um, we'll have a problem if it stops working, like, we're going to have to talk about that. But short of that, you're, you're in control. I recognize your expertise." Teach. That's what I think a smart employer does. So if you're at a place where they do that, right on, cool, enjoy it. But if you're a place where they don't, or you haven't explicitly stated it, maybe it's questionable, you know, to, to just say, well, I'm going to choose this thing. If you're just totally optimizing for what's fun. Um, or if you're optimizing for, like, some people get, myself included, some people get, like, purist, right. Where it's like, "well, well, code should be written this way." It's easy to pick on functional people, which I love functional programming, don't get me wrong. But like, you all know you're at the conferences being like, "you all write code wrong unless you do it in a functional language."

[00:24:26] Dave Adsit: See, I love picking on functional programmers. So it's a good match, Matt.

[00:24:31] Matt Baker: Yeah, yeah. And so like that, I know that when you're making the decision on what programming language to choose, there's a least precedent for you to maybe be considering your own interest there over the person who's paying you money, right? And so it doesn't get surfaced all the time. I guess that's what I want to say. It doesn't get surfaced all the time that sometimes these choices really matter. Sometimes they don't at all. At least be aware of where you stand, both as the employer and then as the engineer. Make sure if you're indulging a little bit of your love for programming and it's in a contracting gig where the budget is tight and they need it as quick as possible. I don't know, that feels wrong to me. It feels like a bad time to indulge. I think you should go with what you know, or you tell them, right? Like, "Hey, do you care, person who's has a tight budget and tight timeline? Do you care if I extend it, like, arbitrarily because I want to play around?" Like, saying it like that, of course, they're not going to say yes. Right. And so I think there's cases where it's not the right thing. And I think as an engineer, like, we, we could do a better job maybe embodying this point. And it changed for me. I, I think when you are the person who's writing the check for the code being written, and your lens on this changes immediately. And you start to see how it is more of a strategic choice. And you start to see how it doesn't, it does impact the amount of money you have in a bank account, which when you're trying to start up a company is small, right? And so you're trying to, like, squeeze every drop you can get out of every dollar. And so in that mode, to be, to hire someone, think about it from their perspective for a minute. Like, to hire someone that comes in and indulges, like, their, you know, coding fantasies to a degree, like, you rightfully so, you're going to be a little bit upset. And so there are cases where it's not the right choice. But again, like, I think there are, like if you're, I do believe if you're a smart employer hiring engineer, you're telling them, "hey, come here, do whatever you want, like, you're within these confines, right? Like, we need these things, these met, but other than that, these choices are yours." And so all that is to say, I don't think we give enough credence and enough thought to programming languages. And like when you choose them, that you are making a strategic choice for the business, and it will impact, you know, bottom line.

[00:26:32] Dave Adsit: Yeah, completely agree with that. I think about it from the perspective of what kind of a business are you? Are you a products business? Are you a services business? Or are you a technology business? And if you're not a technology business, you're not going to be shipping your tools to people. You're not going to be showing people around your workshop, right? So you should be making a choice based on what is best for the business. And for me personally, that comes down to what language can I use or languages realistically? Realistically what languages can I use to express this business concept best, fastest, most maintainable, most serviceable? Like, what can I deploy into production? These are all the considerations that I want. Do I know how to operationalize this? Do I know how to run it in production? Do I know how to run it at scale? Do I know how to debug under fire? What do I know about this language? Can I use this language in anger, as they say, like, when, when I am frustrated or time constrained or whatever? Can I express the concepts without worrying about where the semicolons go and whether or not we're using curly braces and should I be using tabs or spaces for the white space here, because it matters? And I can't remember, or are we doing this to learn and play? If you're in a technology company, then the technology itself is the product. And so the technology choice may be made for you, or it may be that you get to make it. And again, it's still a strategic choice. One of the things that's really important as a professional, we talk about crafting code and professionalism. If I leave this company, is this product dead? That's a concern that you need to have as an engineer.

[00:28:16] Matt Baker: Expand on that real quick, Dave. Why would it die?

[00:28:18] Dave Adsit: Well, let me tell you a story. One of my friends worked at an organization where they did everything in Java. And what that meant from the production perspective is they did everything in the JVM. Their operations team was really good at running JVM on Linux. And so they had a developer who wanted to learn Scala. And he was like, "no one can tell the difference because it's already compiled to bytecode." And so he wrote an application in Scala. And then he got a job offer to go do something better. And he left. And the developer who came in after him was a Java developer because the company hired Java developers. They tried, they wasted probably six months of time trying to fix the Scala, but there was enough nuance in there. And he had done the thing that used to be fashionable in Scala and no longer is from what I understand, where he had used special Unicode symbols and mapped them to functions and all kinds of things. And his Scala was really cool, and they had to throw it all away and start over, and they lost six months of time debugging it. And then they lost another year rewriting the application from scratch. So he made a strategic decision for the company and somebody else had to pay the consequences. And they didn't even know what had happened to them because it was on the JVM. And so those are the kinds of things that I think about when I think about, like, "just do whatever, balance having fun with delivering product and delivering value." And I think that's all great. But at the end of the day, hey, if I walk into somebody's code on my team and it's VB, I'm going to be like, "okay, we are rewriting the Visual Basic into C# because, okay, two things, both of these are prejudiced. I don't want to write VB and I don't want to hire VB developers." My experience is VB developers are less serious about the profession than C# developers. If you picked a .NET language, you probably picked C# unless you're an amateur. And then VB is a little bit less intimidating.

[00:30:21] Matt Baker: I think it's important to, like, uh, I think about this as a golden rule, what you're talking about, Dave, this, this person that wrote the Scala app and then left the company, uh, left him in a lurch. Right. And I don't know anything about what happened, and I'm sure there was a very good reason for everything that went, you know, for the way it went. But, um, end of the day, his, their, their choices, um, left the company and, uh, you know, kind of poor spot. And for me, this just kind of comes down to the golden rule. If you're being paid to do something for someone, you should act the same way you expect people to act when you pay them to do something. One of the best things a programmer can do is pay someone to write them code. If you get the opportunity to do something where you can actually become the person writing the check to have the code written, take it. And I believe your perspective will broaden and you'll have a lot more empathy for what we're talking about, which is the employer's perspective in this transaction. It's when you're in a room with a bunch of engineers, the employer's almost like never represented, right? It's just always a bunch of engineers sometimes railing against stuff their employer's doing, which rightfully so sometimes. But other times that whole perspective just gets lost. And so I do think it's important to, I don't know, check in with the way you're acting and say, "do I, you know, am I behaving a way that I would be okay with if I was paying someone else money?" And maybe you don't care about that. I don't know. I do. And so that makes this topic of what tool we choose and what we'll do to my employer. That makes it important to me.

[00:31:58] Dave Adsit: Well, and that goes back to like knowing the context a lot, right? Like there's the TIOBE language research website. I can't remember what the the details are on it, but I know that they have a list of the most popular programming languages. And if I'm writing code for somebody else, I want to probably stay in that list. So I think right now, Python is the number one programming language on their list. It wasn't a few years ago. A few years ago, it was probably Java or C# or maybe even C++, but you know what you're not going to see on the top of that list is Rust. I could probably name him a few other languages, but I don't want to call them out. Okay. Visual Basic, except Visual Basic probably does make the list because there's a lot of amateur programmers. And thank goodness there are because they're building a lot of code that we wouldn't otherwise have in the industry.

[00:32:50] Matt Baker: I was going to say Rust is interesting. And like, it's a fun programming language, the top to bottom, right? Like the ecosystem's fun, like the culture, the allure around it is fun. Like it's, it's a cool thing, but I agree with you. Like, if I'm gonna have to go hire people, or maybe if you're confident, you at least as far into the future as you can see, staff for Rust, great. But I think Dave's point is, if you can't, if you can't, don't, don't pick it. Like, or, and if you're being paid to write some software for, for someone else, I consult them, at least be like, "hey, here's, here's a consideration to make your, your ability to hire into the future and your ability to like continue to, you know, operate this product, this impacts that. What do you think?" And I think we could probably guess what they would choose.

[00:33:35] Dave Adsit: Well, and, and the thing about that is, is that sometimes you choose a language or a tool for a very specific reason, and you are willing to pay the cost of onboarding and training people because it turns out any competent professional programmer can learn to work in any programming language. It just takes some time and probably some mentorship and maybe somebody pairing or hand-holding for a while. And honestly, part of the reason that we don't move to new languages, for me personally, I use C# for almost everything. I recently started a new job and we had a small existing Python code base. I can't run Python in production. I don't know how to run Python at scale. I barely know how to write Python at all. It's interesting. It's nice, but it's not my thing. So I ended up rewriting the entire, as the solo developer, I ended up rewriting the entire app in C# so that I could stop thinking about the programming language and focus all my mental effort on the business problem we were solving, which is more important than the programming language right now. If I'd had somebody who I was working with who knew Python well, I would have been happy to learn Python from them, but I don't feel like it was my employer's responsibility to teach me Python and slow down the project and deliver fewer features later so that I could come up to speed on Python.

[00:34:56] Allan Stewart: Well, what's interesting there, Dave, is that I happen to know that you're also using React for this project and you kept that despite that not being a core proficiency

[00:35:06] Dave Adsit: for you. That's true. I did. And the reason I kept that is because I had some mentors and some some coaches that I could reach out to occasionally and learn the paradigm and learn the way of dealing with React in a way that I didn't for the Python code. And I've been writing JavaScript back since you had to write your own blink tag.

[00:35:31] Allan Stewart: That probably helps. It helps.

[00:35:35] Matt Baker: It does. That decision you're talking about, Dave, to rewrite, that's a tough one. I don't know, like, a guidance for that other than you just, comes with time, you get better at knowing when to do that, because there's definitely scenarios where that's not the case, right? And there's, uh, there's definitely scenarios where you shouldn't rewrite it, um, into a language you're more fluent in. And I don't know, it's, I try and, like, as you think about that, I try and distill it down to, like, what's the nugget of wisdom there. And it kind of just comes down to, it depends. I'm like, "you just have to go through it a few times, and you'll get good at it, and you'll understand when it's right to do what Dave did and when it's right to go the other way or there's something else entirely."

[00:36:14] Allan Stewart: Yeah. There's a lot of variables there. We talked about who's available, who can you hire, right? Like the hiring pool, but then also just sharing knowledge. Sometimes we think about it in terms of sharing knowledge across teams. Like, can we build up shared libraries because people are using the same code base, but it might also just be, yeah, what people do you have to reach out to? Like Dave was saying, does he have somebody who can help him with React?

[00:36:38] Dave Adsit: In my case, it was a lot of someones and they all got slightly abused. I could just go down the list. "Okay. Who haven't I asked in three days? Okay. What do you do when this in React?" And then there's also comes, like, pound your head against it and figure it out.

[00:37:00] Allan Stewart: I think it's interesting to think about the number of languages that you maintain in, in sort of your stable of languages, both as an individual, how does it affect you and your ability to work within your employer? Can you work across projects? Does it make you a more valuable developer? Like if you're ready to move on to your next job, that can be a benefit if you have experience. But if you have too many languages, personally, it makes it so that that you're not, you tend to broaden out and you don't get as deep in, you know, like, those T shaped, or sometimes people call it like the V shape, like, some things you should know really well, you can go really deep on it, but you don't want to only have one thing that you're really deep on. But then also for, for a company, right? If you have to manage 17 different languages across the company, you know, and there's, there's only 10 teams, then it's going to be difficult. But if you only have one language, then you might be getting into that golden hammer territory where you're using the same thing over and over, regardless of how ill suited it is for a particular problem. So I kind of feel like both individually and as companies, you need to have kind of a smallish stable that has a few different programming languages in it, but not just one.

[00:38:23] Matt Baker: Allan, how do you think about introducing new languages into an ecosystem like that?

[00:38:29] Allan Stewart: Well, I think it goes back to the idea of, like, there is a strategic choice that you've got to make. So you need to be mindful of that and in all the same kind of ways that you were just describing a minute ago. And then the other thing that I like to think about is how different are they? We see this a lot with databases. I feel like people understand this well with databases. If I've already got Postgres, then maybe I don't need MySQL or SQL Server because they're all very similar in, like, this relational flavor of database. But maybe having Redis or, I'd say, Cassandra, except for now that's hard to operationalize, as it turns out. But maybe, you know, there's managed services, right? So maybe you want to use Dynamo or something out of AWS, or there's different ones provided by these different cloud providers that have different characteristics of how you're doing data. We do ourselves a disservice if we just say relational or NoSQL, just because NoSQL has broadened out so much and it can mean so many different things. I think the same thing applies in programming languages. Don't pick two languages that are really similar and have the same kinds of use cases. You might be doing yourself a disservice if for your Java team, you're also picking up C#. Well, maybe you should pick up something pretty different instead, just so that you expand the horizons of the team, but also can use them in the places that they're particularly good at.

[00:40:01] Matt Baker: I was reading this paper. So the main assertion in the paper was that complexity comes from the the way you manage state in your system. And they talked about state in a few different ways. There's intentional state or state that's necessary to function in the domain you're in. And then there's accidental state that you didn't mean to introduce and it's not necessary for you to function in the domain you're in, but for any number of reasons, you become dependent on it. And that's the way I think of redundant programming languages the way you were talking about them, Allan. Like if you are already using Postgres, why would you bring in MySQL unless, I'm sure there's some reason, I'm sure. I get it. Yeah, but generally, like, it's also true that people actually do what Allan's saying for no good reason. Like, they they have Postgres and then they bring in MySQL. And if you think about this paper and their idea that complexity is sourced from accidental state, it rings true for me. Like, as I look at the, maybe if you look at the software organism in a company and this kind of ecosystem system, it does feel like it just ratchets up the complexity for no good reason. And maybe most of the time it doesn't matter, but maybe the way you, like, back up MySQL is different from the way you back up Postgres. And so now Ops has two things to deal with. And it just, it always seems to, like, show up somewhere, you know? And so, like, there's, you should just have a good reason for doing these, these things that could be argued away. Like, what is, I, yeah, anyway.

[00:41:29] Dave Adsit: Anyway, one of the things I think about when you ask that question is, am I learning this new language for myself to expand my capability and my way of thinking? Or am I introducing it into a business where a bunch of other people depend on it? If it's for me, like I've gone through Seven Languages in Seven Weeks and I've done a lot of code retreats. And early on at code retreat, we'd be like, "pair with somebody in a different language." And that was always really fun. You're like, "show me your language. Show me how to do Ruby or Python or whatever." I've paired with people on Pharo Smalltalk at a code retreat and I was useless, but it was really cool. And the thing that I took away from that, you know, trying a bunch of languages yourself is that you can do whatever you want in a low stakes environment and you can play with things and you should. And it can be useful to expand the number of tools in your toolbox. But it's a different thing entirely when you bring that into an ecosystem where other people depend on it. So I would say if you want to introduce a new programming language into a business, one that I happen to be a leader at, I'm going to ask you how many times you've operated it in production and how large of a scale and what you did when something went wrong in production. It reminds me of the question that you ask when you're interviewing ops people is, "tell me about the time that you caused a production outage." And you don't ever hire a senior ops person who hasn't caused a production outage because they don't really understand the stakes yet. In fact, I don't think you can be a senior ops person until something you did accidentally caused a production outage. I think that's one of the checkboxes. But I'm not encouraging anyone to go out and cause a production outage. I'm just saying it's inevitable because we're people.

[00:43:20] Allan Stewart: Maybe not a senior developer either, if we're being honest. Yeah.

[00:43:26] Matt Baker: I think if we're talking about chaos engineering, you should. Yeah. Don't just cause some serious outages, but point made, like if you haven't- Be prepared for it. Yeah, exactly.

[00:43:36] Dave Adsit: Be prepared for it and then kick over a server. Speaking of Cassandra, one of the conferences I went to had Cassandra running on a collection of Raspberry Pis on Wi-Fi, and the presenter hit one of them with a hammer. And he's like, "look, it's still responding to queries just as fast." And I I was like, "you just hit your computer with that." Speaking of chaos engineering, nothing brings chaos quite like a hammer. It had a power button. Yeah, you could have just turned it off. You didn't have to destroy it. But yeah, like, it's a different answer depending on how many people depend on it, right? If you want to sit down and write some IO code or whatever, go learn IO, go learn the truth of prototype languages, you know, JavaScript is a prototype language, but you can probably mostly ignore that fact. You probably can't ignore that very much in IO for very long. And you might learn something really interesting there that you wouldn't learn if you just stick to your C derivative OO languages, Java, Scala, C#, C++, whatever. Though Scala would probably say that we're a functional language, and, like, well, you've got a lot of OO characteristics.

[00:44:48] Matt Baker: If someone asked me how to vet a technical decision of the company, how a non-technical person could do that, maybe the only good answer would be, or not the only good answer, but a good question to ask if you're a non-technical leader of your technical employees could be, "why is it necessary? And can something we already have accomplish it?"

[00:45:09] Dave Adsit: Yeah.

[00:45:09] Matt Baker: You know, I won't get everything, but it'll catch a lot and it'll get a lot of what I think we've been highlighting here, which is all the different reasons people make choices that aren't from that perspective.

[00:45:21] Dave Adsit: One of the things that I like to point people at is the Heilmeier Catechism from DARPA, which asks a series of questions. And one of the questions is about reversibility. If you try it and it works, what are the consequences? What's the benefit? If you try it and it fails, how do you reverse it? And if you've got good answers for those, then you should have enough slack in your system to be able to experiment with things like that and bring in new tools. If we stuck on the same tools that we picked up when we first started, I would be writing HTML packages as stored procedures inside of the database. Because the first thing that I put into production was a website served out of an Oracle 8i database server. I'm really glad that we get to evolve and learn new things because that was a terrible place to be.

[00:46:15] Matt Baker: Well, it's like, I know we've talked about this before, but technical leadership, or at least, like, a technical recognized expert in the company, you need someone to be able to navigate what Dave's talking about, where there's so many subtle things that come with the evolution of a technical system. And one of them definitely is, is this tool still the right, it's going back to what we were talking about earlier, actually, is this tool still the right thing for the job? Or like, even if this tool can continue to solve the problem, yes, it's taking us down a path, a paper cut or an inch at a time that in aggregate over a period of time is going to really hurt us. So we need to start changing this tool out now, right? Like, you need that kind of wisdom. What am I trying to say? I feel like that perspective gets undervalued often.

[00:47:03] Dave Adsit: To that exact point, as an example, if you have an Android app and it's still written on Java, you should be migrating it to Kotlin. Because the Android developers that you want to hire want to write Kotlin. They don't want to write Java anymore because they haven't written Java for many years.

[00:47:22] Matt Baker: When they don't, like, when they're looking from the engineering perspective, you're like, "why would I, I'm not going to go there when I can go to this place that's on a new tech where I can really propel my resume forward?" And like, there's definitely a benefit to an engineer using the new tool and in the right scenario. Like, well, I will say that engineers absolutely choose jobs sometimes in part based on the tools they get to use.

[00:47:46] Dave Adsit: We've all heard of resume driven development. "What is the right answer to this problem?" "It's an event log based microservices architecture." "What makes you say that?" "You see this hole on my resume where it's supposed to say event log based microservices architecture? That's why I know."

[00:48:07] Matt Baker: This is one of the funny things about, like, technical recruiting, because I feel like engineers are so, at least, I don't know, I'm sure, I'm sure not all engineers are this way. Some engineers, what they value might be surprising to the people trying to hire them, you know? Like, an engineer seriously might take ten thousand dollars less, fifteen thousand dollars less a year to use the language that they want to use. Seriously. Or they might, they don't care about your, uh, I've riffed on snack walls before. They don't care about your snack wall, and they don't care about your in-office perks. In fact, you could probably save money and not do some things and emphasize other things. Anyway, I think this ability to play with new tech is undervalued.

[00:48:50] Dave Adsit: I think you're right. I think I've worked with teams who just for the sheer fun of it, wanted to rewrite their tools or write all their new tools, new products in a different programming language than they had before. And if you have the right support for that, that can be a very powerful motivator to get more done, get it done better, to learn and make the job exciting. And if you don't have the resources in your company to support that kind of a thing, they just drove a nail into your coffin.

[00:49:21] Matt Baker: It drives innovation. It's crazy the things that come out of that kind of place, like when you have a bunch of people showing up stoked to work because they're on a new project with a new language and they're working with people, like, they enjoy working with. You'll be surprised, you'll be surprised at what they produce. And to Dave's point, if you can foster that by doing things like understanding when it's time to maybe wipe the slate clean on your current system or parts of it, or like you're saying, if you're on job on Android, it's time to invest in getting over to Kotlin, um. Those can be moments where the people that work for you have a ton of fun and really can be thought of as a benefit.

[00:50:00] Allan Stewart: Especially if there are those low stakes places where you can develop that learning. There is that need to be able to operationalize these things. And so if you're operationalizing an internal website that is used just by employees of the company and customers never see it, well, then there's a lot more ability to do that. You know, you can be a lot more forgiving of failures and errors if it's all internal than you can if it's customer facing.

[00:50:28] Matt Baker: That's a great point.

[00:50:29] Dave Adsit: That to me is the decision maker. What is the stakes? What is the bet that I'm making? What am I putting on the line? Am I putting my business on the line, or am I putting on the line some internal application that sees ones of concurrent users?

[00:50:44] Allan Stewart: So we've talked about, like, different types of languages, functional and OO get thrown around a lot. People think about that. But one of the things I mentioned earlier, so we should come back to is dynamic versus statically typed languages. I don't know if this is my own bias, but I kind of am feeling like, over time, what I'm seeing is that if I'm on a large project and there's a lot of people, I want static typing. If it's a long running big project, I just, I tend to want that. And I think you can see things like TypeScript coming along. Why would anybody bother to create TypeScript unless there was something about JavaScript that wasn't working for these really large projects like Angular? So they're have some additional way to understand what is going on in our system. And so they put TypeScript on top of JavaScript so they can build Angular. I think there's something there, but on the other hand, I've also really enjoyed working in dynamic languages. And I hear tales of, like, if you're doing dynamic languages, you need to be really good at test-driven development. And you use your tests as a way to express what's going on. And then you don't need the typing, and you can have a lot more flexibility and, and some of these things. And I'm just curious what experiences you two have had. Am I completely crazy in what I'm saying? Or is there something, is there something there?

[00:52:14] Matt Baker: I definitely think there's something there. Like, I feel like JavaScript, the evolution of JavaScript, it's like the biggest instance of a code-based rotting that I've ever seen. The whole ecosystem, and before you get pissed off, I don't mean that in a bad way because it happens everywhere all the time. It happens in all code bases forever. They get big and they rot, and then you have to figure out how to deal with it. The JavaScript ecosystem, I think, given the challenge in front of them, has done a pretty good job. It's such a massive scale of language innovation that, for the first couple of years, sucked so bad. It was just like, every time you looked at JavaScript, there was some new engineer telling you that you're a dum-dum because you didn't understand this, like, new build pipeline or new syntax that's on, ES, like, strawberry vanilla, and you have to patch, like, your system 32 times to get access to it. And, like, and that was happening. Like, let's, if we're being real, that was, that was actually happening, and it was a big pain, but it's, I think it has settled. Like, when I play with React, for instance, I feel like React is starting to mature into a pretty good tool, uh, or a great tool, rather. I'm impressed with it. I don't think it's anything I could ever pull off. They've done a great job considering how to design that thing. Are there warts? Absolutely. But, like, again, like, look at what they had to go up against. It's, uh, it's crazy. But to maybe more directly to this point you're talking about, Allan, the language, the dynamic dynamic language that was touted by everyone as, like, any person you talk to in JavaScript would tell you early on, at least, circa, like, pre jQuery days, right? When we, yeah, they would. And then even into jQuery days, say, "well, no, it got really bad when, once node came around, because then I was so much bigger." So yeah, around node, JavaScript developers would tell you, like, "I don't have to type. It's so much greater. I can go so much quicker." And in a certain context, absolutely true, like, a green filled project, yeah, definitely. But as the project grows and the number of people want to grow, as that changes, and you see it in JavaScript itself, it went along this dynamic path, and at some point someone was like, "this is crazy." They had the brilliant idea to introduce types, and so they realized, like, "oh, okay, at a certain scale, um, you, you do need types." And I, I'm sure I'm paraphrasing, I'm, like, dumbing down and distilling, like, a lot of things that went wrong, and I don't mean to misrepresent that whole thing, but that's my, like, my lens on it as I watched it. And it's funny to me because I see it a lot of companies, every dynamic code base I've ever worked in that lived for any length of, like, any serious length of time, eventually hit this constraint where it's like, "I don't know what's going on anymore. Like, this language, it's just going crazy on me and I had no safety." And so, like, Allan was talking about, you can't solve that with tests, but you can also solve that at build time, like with your compiler. It can help you with that if you introduce types. And so they introduce types. And so I just want to go back to all those arguments like, "dynamic is better. Like, typing sucks. Dynamics, the new way," and just point out, like, "Hey, I appreciate, like, watching you go along your evolution to learn my point."

[00:55:21] Dave Adsit: Yeah. I, I gotta say I am team static typing all the way. And if it weren't for TypeScript, I would, I don't know what I would be doing for the front end of my web app. React would intimidate me without types, I think.

[00:55:35] Matt Baker: I don't know. Just one more thing on that. Just so I don't get misrepresented there. I think it's so contextual. This whole choice, I think, is so contextual. And that's why I'm making fun of this argument that dynamic is always better. What a dumb thing to say. What do you mean? It's always better? No, like circa 2007 JavaScript developers, it's not better. It's contextual. And over time, as that code base grows, you'll see.

[00:56:05] Dave Adsit: There's a lot of constraints that we have or don't have. You know, if you had a constraint around memory management, you probably want a very statically typed language so you know exactly how large each object was and how many of them you could have. We don't really have those language constraints. I think the computer that I'm using right now is got a mere 32 gigabytes of RAM because I haven't upgraded it to 64 yet. But that's not the case for everything. Sometimes you're writing software for a watch. One of the things that I think is the best about the evolution of the JavaScript ecosystem is that if you stand back a little bit and you didn't get all up in it, like I spent a lot of time writing backend and software architectures instead of writing front-end code. And my favorite part about the JavaScript ecosystem was watching the JavaScript developers rediscover every fundamental of computer science one after another, like testing and dependency management. All of the different tools and all of the different things that the backend developers had been using for a while, seeing the frontend developers discover them as though for the first time was, it shows you that there's cycles in all things.

[00:57:14] Allan Stewart: Well, we might have to invite a guest on sometime that is really into, you know, the dynamic languages just so we can, yeah, I, I don't know if we have the right mentality here. I think we're on, on a similar similar opinion length here, so I'm going to keep believing it, but leaving open a little space for maybe I'm wrong, and I just need me to figure out how, because I think that goes back to the whole idea of craftsmanship. We're doing this the best way we know how, and we're willing and open to the possibility of having a better way of working. But speaking of better things, what are some of the cool features or things that you have appreciated in different languages, either as they've evolved or as you've exposed yourselves to new languages? What are the things that you found just like, "oh, that's really cool or convenient?"

[00:58:11] Matt Baker: For me, writing functional code code in JavaScript is the most pleasant code I've ever written in my life. And specifically node, the way it embraced streams makes it a dream when you can get it right, when you can compose your functions correctly and then just start piping and put the output and chain those together and, like, maintain that little, like, beautiful little Lego. It's just, it's just a joy to write code in that language or in that way. And writing functional code in JavaScript is the, that's the time where I can get there there most because you can do all this cool stuff, but it's, it's loose. It's not as, like, draconian as some other, you know, like a lot of functional languages, languages with a lot more rules.

[00:58:53] Dave Adsit: I've got a new one and it is the JavaScript spread operator. I love it. And I have accidentally tried to use it several times in C#. I had not used it before this year. I think the first time I wrote it in code was earlier this year. And I think it's great. In case you don't know, you put dot, dot, dot in front of an array or an object, and it decomposes it into all of its elements that you can then use to create a new object or a new array. And you can add additional elements or whatever you need to. And it's really, really nice. The C# equivalent is array.unionOtherArray.toArray. And that creates a new array with the contents of those two previous arrays. And the spread operator is so much nicer.

[00:59:51] Allan Stewart: Yeah. Kind of related to that. I really liked when I finally started to understand, like, destructuring, uh, pattern matching, I think is also a really cool feature that is finding its way into more and more languages.

[01:00:04] Matt Baker: Yeah. When I get the chance to use pattern matching, I'm always a little excited. It's fun to implement those.

[01:00:09] Dave Adsit: I like using pattern matching to, to destructure elements in, in C# in a way that it wasn't previously possible and is only possible because people programmed in multiple languages and said, "this is a nice thing. I would like to take it home with me. I'm going to buy one and put it in a bag and take it home with me and then put it on my shelf and then use it there."

[01:00:33] Matt Baker: You do it like in the, is it in the clause? It's like in the pattern match statement, like you can destructure when you're putting the condition. Yeah, see, that's so slick. It's, it's in

[01:00:42] Dave Adsit: it's in C#. You use it a lot with tuples. Got it. You're like, "I want this part, but I don't care," so you can name and or you can use it with records. Yeah, it's so slick. Yeah, and I agree with what you

[01:00:53] Matt Baker: just said, Dave. Like, that didn't come from C#, like, that wasn't, like, born C#. There's people going out and be like, "oh, this is cool, we should bring this in." And then what we were saying earlier, C#'s done a good job saying, "okay, and we'll do it." Yeah, like adding record types is another one

[01:01:06] Allan Stewart: that I like, right. Getting into that immutability that wasn't there before.

[01:01:11] Matt Baker: Can you assert equality based on value with a record type, like even in a, like a complex object? Yeah. And then there's no, is there any concept of, like, this particular instance is different from that particular instance, even though we had the same values? No. Cool.

[01:01:26] Dave Adsit: The records are only use value-based comparison. I think you could probably override and do whatever you wanted. The default usage of a record is like, if they have the same values, they're the same record. If you go back to your Domain-Driven Design, they are the value types. One of the things that I really, really like, again, borrows from the functional paradigm, it's the LINQ functions. The LINQ as a concept, language-embedded querying in the .NET languages, especially C#, is super powerful. It brings in a lot of those concepts of treating functions as a first-class citizen so that you can pass them as predicates to all kinds of filters and projections and things like that. Of course, because they were coming from a database paradigm, they used the wrong words for them all and called them where and select, but it's the same concepts. And so it's really awesome.

[01:02:23] Allan Stewart: Well, and it's interesting because I found over time, I have stopped using LINQ for anything database related. Like no longer do I use LINQ in order to query databases. But once I have data, I use it all over the place in my C#, just not in the database.

[01:02:44] Dave Adsit: 100% agree with that. If I find LINQ touching my database, I'm going to restructure that code, rewrite that code. I don't even want to use the word refactor because typically if you're linking to your database, you didn't use tests.

[01:02:57] Matt Baker: What's the lesson there? Why are you both so averse to it?

[01:03:00] Dave Adsit: I think for me, the biggest problem is that there's an impedance mismatch between the way OO code is structured and the way relational databases are structured. And there's a lot of traps that come with the way you accidentally query using an ORM. I avoid ORMs like the plague these days. If you've got Entity Framework in your code, that's fine, but I'm going to take it out if I work on that code for any length of time. And I feel like that's just the responsible thing to do because you end up fighting your framework too much. There's that adage, "whatever your framework does for you, it does to you." And I feel like ORMs have done too many bad things to me in the dark of night, and I don't like them anymore. I'd more or less agree.

[01:03:49] Allan Stewart: But for me, what I found was it was less intentional over time. Like, I didn't really realize it. It was just kind of came to me one day. I was like, "wasn't this built to query databases?" It's born out of, like, these ideas of how to interact with SQL. And I don't do that at all.

[01:04:05] Matt Baker: For me, it was. So I agree with the praise for LINQ. I blew my mind when I saw it. And it's one of those times where it changed the way I write code a little bit. Right. All of a sudden, you, like, when you see something like composability come into a language that you're really familiar with, because I was writing C# at the time, uh, for my job, and it was really cool, and I, I also started out using it right against the database as well. And the thing that, I agree with everything you both said, and then the very day-to-day thing that would bite me was, um, misunderstand, I can't remember what it's called, but misunderstanding when, like, the the IQueryable is, what do they call it? Binding when it actually executes and goes to the database. And, like, there's certain statements that, that bind and cause that transaction or that database trip to occur. And there's certain ones that don't. And at the time I wasn't good at under, like, it wasn't intuitive for me to understand which ones were going to the database and which ones weren't. And even broader than that, like, just what kind of queries were being written in response to my LINQ statement. But the, that one in particular would bite me a lot and it would just show up, like, why is this just massively excessive queries going on, and queries at bad times, where, like, a LINQ statement part way through might load up a whole set of data and then start to filter it, but because the way I wrote the LINQ statement, it loads the whole table into memory and then starts to filter it. And so definitely boo on me, but I, that was a practical one, day to day, that caused me to get away from it. And then I read, I can't remember who wrote the, there's some paper or some article on the impedance mismatch that Dave's talking about. It might've been a DHH person, but they, uh, somewhere they, they wrote that, and that really resonated with me. And that was around, that was when I kind of stopped using ORMs as well. I arrived to it, I think like we all did, was just distaste for them. But then I read that paper about impedance mismatch, and it put to words something that I couldn't, you know, I definitely couldn't put to words myself.

[01:06:02] Dave Adsit: One of the things for me is that the introduction of an ORM is an attempt to hide away the fact that you have to learn another language. Structured query language or SQL is not the hardest language to learn. Like, you could probably learn it in a day or two. I say that having used it for the last 25 years. If that's not true, I apologize. But if you just learn SQL, you realize that the queries that you want to write weren't that complex and you don't need a tool to write them for you.

[01:06:34] Matt Baker: You're not wrong.

[01:06:35] Dave Adsit: So you can get rid of your ORM.

[01:06:37] Allan Stewart: And I think you should avoid queries. SQL should be relatively easy to learn because most developers, most of the time, I will assert, should use a very small part of it. Don't get really great at joins and stored procedures and materialized tables and views. And you can do all of these things, but just don't. Just get the data in and out of the database and let your business logic do the business logic.

[01:07:06] Dave Adsit: What are your opinions on delete triggers?

[01:07:10] Allan Stewart: Triggers are just my favorite thing ever. I love triggers and stored procedures.

[01:07:17] Dave Adsit: All of your code should be written as one giant trigger.

[01:07:19] Allan Stewart: I think that we should go back to your Oracle 8i days and just only have databases.

[01:07:27] Dave Adsit: So I guess that's the thing is that every language has a lot of dark, scary parts that you shouldn't use. In fact, I said earlier that C# was an attempt to remove the necessity of memory management from C++. But C# has in it the ability to do unsafe code that just manages memory directly and does bad things to it. So there's always scary parts. We have a mutual friend who always talks about reflection. And we have another mutual friend who always tells him to knock it off. That's not the right way. That way leads darkness and madness.

[01:08:14] Allan Stewart: It's true. There are definitely some features of languages that are annoying or problematic. Noisy syntax bugs me when I feel like there's just, like, excessive stuff that I have to do. And I don't know. There's going to be some people who are in some languages and they're looking at C# and be like, "oh my gosh, there's so much overhead." But compared to yet other languages, I feel like C#'s a nice middle ground. You don't have to have a ton of extra noise in there. Another one that bugs me is significant white space because I can't see the white space. And so it's hard for me to know whether or not I've just completely changed the control mechanism of a file accidentally.

[01:08:57] Matt Baker: I put this in here in response to that, the significant curlies, depending on who you are and what you like. When I saw significant white space, I thought of Python people. I assume that's what you meant, the white space. I wonder if they can read it as naturally as someone who writes curly languages can read the curlies. Because I'm like you, it comes, it's definitely less natural to me to, like, use white space to, to indicate the scope or the structure of the programming language, but I'm getting more used to it, but I fall back to curlies. Yeah. So I don't know, maybe different strokes.

[01:09:34] Dave Adsit: Probably the one that I thought of when you said significant white space was YAML because everybody I know who writes YAML has at some point been burned by having a space or four spaces instead of a tab or whatever it is. I can never remember. I stay away from YAML and I use JSON because I'm just not that elite.

[01:09:54] Matt Baker: See, it shows up again there. Like, well, I definitely have the trend towards curlies as well. I hate YAML. People are like, "they've got to write this YAML file." I'm like, "ah, fine."

[01:10:07] Dave Adsit: Well, you just, you end up opening a different editor that has turned on visual indicators for the different types of white space. And you're like, "what did we save? What did we save?" Or you load your YAML into a YAML specific editor that throws an exception or highlights the line in red if you typed whatever the wrong character is. Or a linter, yeah. Or a linter. I have personally experienced the bug where you have an if statement followed by a single line of code and you didn't put curlies around it and somebody added another line of code and they indented it properly and it looked like it should be part of the previous statement, but it turns out it wasn't. I may have written that bug. I've definitely experienced it.

[01:10:55] Matt Baker: Subtle.

[01:10:56] Dave Adsit: I think we should all go back to XML or SGML if we can. Do you remember XSLT? Oh, sure. Oh, yeah. I wrote several entire applications that used XML and XSLT to generate something. Sometimes it was HTML. One time it was CSVs so they could be loaded into a legacy system that had no concept of even XML. Don't even talk to me about JSON.

[01:11:24] Allan Stewart: For me, it was SOAP. You got to transform one SOAP call to another. Yeah.

[01:11:29] Matt Baker: Oh, yeah. It kind of makes me cringe a little bit when I think of XSLT specifically. I think it was all me just writing just horrible code. But it was definitely a fight every time I had to work on it.

[01:11:42] Dave Adsit: I ended up writing my own XML tools several times where you could paste XML and XSLT and hit a button and it would generate the output. And so you had, like, this manual testing loop, but you could loop quickly and figure out, like, where it had exploded. Because it was always wrong until it was right.

[01:12:03] Matt Baker: I did not have that luxury. What you just said is brilliant. And I should have done that. Like I said, I was dumb. Arguably still am, but definitely wasn't. And the, I was writing XSLT on top of a, uh, it was a suite of tools that could be extended with XSLT, so we had some out of the box websites, and you could, it was all custom software that we wrote in-house that allowed you to edit the forms that would be eventually be HTML, and you could extend those with these little, like, arbitrary scripting screens that had no IntelliSense. To test what you wrote in that screen was, like, a three minute loop because you'd have to, like, let it get into the system, and then it had to rebuild and refresh. And it was, it was maybe, now that I'm saying that, maybe that was the more painful part.

[01:12:58] Dave Adsit: That may be, and that actually reminds me of one of my other pet peeves or, or annoyances when it comes to languages, is proprietary languages. Like, I know that they're super important for certain things. Like, if you're an Apex programmer, good for you, I'm sorry, but proprietary languages really bug me. I don't even have a good reason for it other than I feel like you're putting a programmer in a box. And if you're working on a proprietary language, I would strongly encourage you to go learn one of the more common general purpose languages as well. Yeah. So that you can, you can extend your understanding of what is possible in programming.

[01:13:39] Matt Baker: I went to dinner with a guy that, due to business. So he was a specialized programmer. I'm not going to say what stack, but you would, you would know it if you heard it. And he's, or what app location, or what's sweet, you know, I went to dinner with him. It was a business dinner, and he was a developer in this particular ecosystem and he just spent a lot, at least some of the dinner, talking about how it was horribly misunderstood and if everyone would just learn it, they would see how powerful it was. But it was one of those things where it had a very specific execution context inside the suite of tools, and it was not something you could extract and do anything with outside of that. Like, it was just interwoven. It was very, what did you call, proprietary language. And I, like, due to the business relationship, I just smile, and it's like, "oh, that's a lot of good points." Like, had it been more casual, you know, like, "you're crazy, you should stop telling people that. Like, some poor, like, new developer might hear you say that and actually take it." So clearly I'm biased, right? But it's a very annoying feature, going back to this, the topic we're on, it's a very annoying feature of those languages, that whole proprietary, like, little world you had to get into.

[01:14:53] Allan Stewart: It sucks. Another one that I was split on for a while, that at first I was just like, "this is really annoying." It was async await. Pretty quickly I adopted it in JavaScript land and a node and stuff like that. Like, "okay, actually, this is pretty cool." I changed my mind. I like it. But then over in C#, I noticed this tendency that like all the things are becoming async. Every function was async. And it felt like it was this cancerous growth spreading, infecting the whole system that really bothered me. And so I fought against it for a long time. And then one day I was talking to somebody about some functional programming stuff. And we were were talking about how Haskell has the IO in its syntax. You have to mark the things that have input output. Something clicked with me where I said, "oh, I think that's what all those async methods are doing. It's actually just showing me all the things that have IO in my system." And then I thought about it in terms of functional core imperative shell, and it really changed my mind. It kind of turned around from this thing that I thought was super annoying. It was just like, "you're messing up all of my C#" to, "okay, I get it now."

[01:16:10] Dave Adsit: It just feels like it's the wrong way, right? Because of the evolution of C#, they had to add a flag or an indicator that this is async, as opposed to just saying, by default, everything is except the things that aren't. Yeah.

[01:16:24] Allan Stewart: There's a little bit of that. And also I ran into several problems where if async await isn't done well, especially if there's no return object. A lot of times the IDEs, especially early on, they didn't detect for you and be like, "hey, by the way, this is going to start running and then the request will end and it will get terminated before it's done." And so I had a bunch of problems with that that kind of turned me off from the whole concept early on. And I was just like, "this is just super annoying." But I've come to terms with it.

[01:16:54] Matt Baker: I same conclusion on how to wield it successfully, Allan, by pushing it to the edge and And the imperative shell functional core, I think, captures it. There's a joke I heard that I really like for this one. If you take a barrel of water and add a drop of urine, you have a barrel of urine. And that's the way I think of async. As soon as you introduce it, it better be at the edge and you better watch out because it is clawing its way in every chance that I'm getting. And then you'll be like Allan, where you're like, "why is this async call right here?" And that's when you know you have a barrel of urine and you got to look at your code again and push all that stuff to the edge.

[01:17:39] Dave Adsit: So this isn't a language feature per se, but it is something I thought was pretty cool. When I finally learned how to use it well, and that's fluent interfaces, where you can basically chain your method calls together because each method call returns this as an object, I'm going to do a thing and return myself so that you can just keep chaining methods on. And that is a style that I have used occasionally and found very powerful, especially when combined with things like LINQ.

[01:18:10] Matt Baker: That's another one of those, just like aesthetically pleasing moments and coding where you're like, "ah, I like this. This just feels good."

[01:18:17] Allan Stewart: Probably also one that you have to be judicious with. If you get on the fluent train and you're like, "all codes should be like this all the time," then you may not be happy after a while.

[01:18:31] Dave Adsit: You may not arrive at a destination you prefer.

[01:18:36] Matt Baker: If you write pipelines only for the happy path, God be with you. Because when one of those bits in the middle of your pipeline throws an exception, it all goes, it all falls apart. Yeah. Yeah, I think that's what I take from what Allan was saying. Like, be judicious. Like, it's, it's good in small doses, and it can go out of control super quick. The final annoying thing I'll share is when a language doesn't get package management right, everyone, or every language that was designed prior to this new world of package management we live in. Okay, and I think they've all got to figure it out, and it's, that's really hard to make their stuff backwards compatible. That's a hard design thing. I get that. But new systems, you have no excuse. When you get package management wrong in this day and age, it's like, "well, why'd you do that? This language is beautiful." And then right at the end, you just knock me out cold with this bad package management. I don't want to use it. Rant over, I guess. But if you're designing a new language, please, please get the package

[01:19:41] Allan Stewart: management right. So we talked a little bit about how important it is to experiment with other their languages so you can learn some of these new ideas, learn different paradigms that you hadn't been exposed to, and bring them back, possibly bring them back into your language and it gets added in as a first-class citizen. But how do you do that? Like, how do you avoid getting stuck just in a particular language stack or a particular design that you've been using?

[01:20:08] Matt Baker: Martin Fowler has a, I don't even know if he's the one who said it, but he said something like, "change your company or change your company." I think that applies. So assuming you're at a place where you have some freedom though, I would say rewrite a lot in small chunks. And to put a practical value to that, I think if you try to rewrite something and it takes more than a day or two, I think it's too big, personally. But in small increments, I think you can have a massive effect on a code base if you just rewrite little bits often. I know there's been stories come out of places like Google where they did this a lot, and it really yielded a lot of fruit. I've done done it at places I've worked before, and I always appreciated it. It was, it was more pleasant. And also I think it brought a better result. And, and I also think you should stop thinking about your code as something to be revered, uh, your code. I, I, we have show notes, and I wrote in the show notes, I'm just going to read verbatim. So I don't sound like a total idiot, but here's what I wrote. I said, "it's an ugly, disgusting risk-ridden liability that should be killed and regenerated it often." Just, like, but I feel that way. Like, when you let code rot, it, or when you let code grow old, it rots. It doesn't often go with, like, cheese and get better with age. It usually goes quite the reverse. And so anyway, I think one thing you can do is just always be rewriting little bits at a time, take the opportunities to try out new languages, new approaches, new tools, new frameworks, whatever. And some of them are going to be painful and gross, and you're going to say, "that was a bad bad outcome. We don't want it." And good. You can just rewrite it again. And then some of them will hit, and you'll say, "Hey, that's an advantage for, for what I'm doing here."

[01:21:42] Dave Adsit: Dan North has said a few times that functionality is an asset and code is a liability. So that's just an echo of what you were saying, Matt. Yeah.

[01:21:50] Matt Baker: That's actually how I got it from. I was at a workshop with him out in somewhere, and he said, "all right, everyone who thinks code's an asset on the left side of the room, liability on the right side of the room." And then, like, he spent the rest of the time talking people over there from the asset to the liability side.

[01:22:04] Dave Adsit: It's totally true. So code is more like brie and less like bourbon. I don't know. I'm just trying to throw it out and throw that out there so we can make t-shirts and make some money. So just cut that whole part and throw it away.

[01:22:17] Allan Stewart: Nice. But I think part of the trouble there is there's that kind of euphoric sense, like when you write some good code and you took the time, you tested it, you refactored it, you got it condensed down as small as was right, you know, not too small. That was just like this cryptic one liner, but you got rid of all of the excess. Doing that is doing a good job. You should be doing that. You should be experiencing that sensation in your code. And it's easy to forget that what's actually important there is that you did a good job of building a feature and delivering business value. And that was where where the value was. And when we think about the code as the value, and we get mixed up, and then we're like, "well, I don't want to, I don't want to change things." You know, we've got to remember, it's like, "no, that's the liability." And why you feel good about it is because you've minimized, if you did a good job with writing your code, you've minimized the liability. And so you feel good about that, but there's still liability there. And so I think you're right. And I can't emphasize enough how much I agree with the small chunks, but it's hard, especially when you've got like a interconnected, highly coupled mess of code, then breaking up in small chunks is really hard, but worth it.

[01:23:37] Dave Adsit: You say along those lines, one of the thoughts that I've had, and I don't know if it's true or not. And so I'd like to hear other people's experiences, but I had this thought that maybe you have to leave behind your programming language in order to leave behind the bad habits and practices you learned in it. Maybe you just have to learn a new one so that you can learn why those habits and practices weren't necessary. I don't know.

[01:24:01] Matt Baker: This term just, like, went right across my brain that said, like, "code baggage." Like, emotional baggage, but code baggage. And I agree. I totally agree. Like, go, if you've never ever only ever programmed in one language, you're crazy. Like, you're, go programming another one and just start to get a sense for, like, the, the air that you're breathing, you know what I mean? Because there's a lot of stuff you're taking for granted if you haven't gone out and explored other languages. And I absolutely agree with what Dave said. Like, we attack, I don't know what it is, um, I was just gonna, like, pretend, like, psychologically I understand why that happens. I don't know what I'm talking about. But I do know in my experience that, like, I attach ways of coding to particular particular languages, more than just idioms. Like, there's certain patterns I fall into. There's certain, like, ways I'll set up the environment that are just things that developed alongside me learning that language. And I have to go learn something new in order to shake that up. It's just not another way to do it.

[01:24:54] Dave Adsit: So when it comes to learning new languages, one of the things that I used to tell people to do is go to a code retreat because early we used to talk about code retreat being an opportunity to get exposure to a bunch of new languages. And then I realized that for me personally, that's not a good way to learn new languages. Maybe you get exposure, but as soon as you start applying constraints, which is typical at a code retreat, suddenly I can't help. I don't know how to do something funky. I don't know how to write an application without loops or if statements in your language that I've never coded in. Yeah. So I stopped doing that. I stopped trying to use code retreat as a way to learn new languages, but I still think it's important to get exposure to new languages. And so I always look for things like the Ouroboros Quine, which the one that I've seen most recently has 128 languages in it. And basically it's Ouroboros because it's a snake that eats the world. And Quine has something to do with code that generates its own source code. And so the Ouroboros Quine is, I think it starts with Rails or Ruby. I think it starts with Ruby, and then it generates the Scala or Scheme or something that generates something that generates something that generates something. And it goes through 128 programming languages all the way back to the final program. The final code that executes generates the same Ruby file again. So you could repeat the loop again. It's an amazing artwork. It's definitely not the kind of thing you should do in your production code unless you You are, in fact, a code artist.

[01:26:31] Matt Baker: What if you do it with reflection? Can you do it with reflection? Oh, well, that's okay.

[01:26:36] Dave Adsit: Matt, you are forbidden. You are forbidden to use reflection to generate the Ouroboros Quine in production code. Take away that person's keyboard. So what was the first language you guys learned? Do you remember? The first line of code you ever wrote, what language was it in?

[01:26:57] Allan Stewart: Bash.

[01:26:58] Dave Adsit: Bash.

[01:26:58] Allan Stewart: Gosh, mine was HyperTalk, which is extremely obscure. There was a program called HyperCard that ran on Macs back in the day. And when I was in elementary school, that's what our computer teacher used to interact with us. And mostly we just did, like, simple little animations. It was a lot like Visual Basic, but earlier. And that's how I first started to learn. So I had to leave behind all of my baggage there because you can't, I mean, except for emulators, nobody does HyperCard anymore.

[01:27:32] Dave Adsit: That's awesome. My first, I believe, was Apple SoftBasic, which I only recently learned was actually derived from Microsoft Basic, which was interesting to discover. Ever. But then I went from there, you know, at school we had Apple IIe's and so I got to do Apple Soft Basic on the Apple IIe's, but at home we had an Atari 800 XL. And so I wrote Atari Basic at home, and it was just different enough that I never got very good at any of it and ended up putting it away for a while. What else is there to say?

[01:28:14] Matt Baker: Programming's fun. I've recently switched switched back to coding full time. And it's been, yeah, it's just reminded me that I really like to write computer code. You asking about the first language I ever learned reminds me that it started out as a hobby, and I hope it ends as a hobby. You know, I hope that after I, like, I'm not working anymore, I'm still fiddling with it, because there's something about, like, constructing your thoughts under the set of constraints that a programming language introduces the scratches. So much fun. When I, one of the thought, when we talk about programming languages, like, I think we can just sit here and talk all day about, like, the way one language does pattern matching versus another. And I think it would, we would just have so much fun doing it.

[01:28:56] Dave Adsit: I agree with that. I also recently switched back to writing code full time and I'm having a blast. It's really cool to see short feedback loops of delivering value into our production system. I am relearning the pleasure of front-end programming recently, which is that whatever you do, you see the immediate results, which is different from leading teams where whatever you do you may see results eventually if you know how to look, and where to, where to look, and how to measure, or building architectures for large scale systems where success is measured in milliseconds saved versus, "I changed this code and now that thing is blue instead of yellow." And that's pretty cool.

[01:29:47] Matt Baker: I sat down, um, that one of the days this week, like with the, my morning, um, whatever it was. And the first task on my list that day was to read a bunch of AWS documentation for, um, and it doesn't matter, but it was a series of technical docs. And I looked more, I looked forward to that morning more than I have for a little while. Like, it was cool to be like, "Oh, I'm the only thing I'm going to do today is deep dive on some interesting technical topic." And, uh, it was, it was a great day, and those days have just been happening more for me. And so it's, again, I'm just saying the same thing over again, but, uh, you know, building things with computer software and all the things that come with that, you know, it's fun.

[01:30:30] Allan Stewart: Yeah. And sometimes it's just like that little project that you do on the side, through some, some line art with a HTML canvas or something, just for the joy of it. So there you have it, programming languages. They're really key to the software development world. It's a foundational thing, and it impacts our ability to craft code and choose the right tools at the right time for for the right purposes. Music for our podcast has been generously provided by Todd Fisher. And as we wrap up, as always, we recommend joining a community of professionals by attending a Software Crafters group or meetup near you. The Utah SC group at utahsc.org has a virtual meeting the first Wednesday of each month. Maybe we will argue religiously and zealously with you about your favorite languages there.