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:51] 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 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 Extras accepts. 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 some sort of craftsman working with an actual material on their tool. And I think of programming language like that. And so it's from that space that 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. 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. Borrowing on your analogy a little bit,

[00:02:10] Dave Adsit: I think about the way that a craftsman works with tools. And sometimes 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 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: Trey Lockerbie 1 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 sharp lately, if you're in F sharp, if you want to put a file into the directory structure of an F sharp 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 disk. 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 my opinion. Trey Lockerbie 1 Maybe a more extreme example, but I do think it like it scopes your thinking and it, the result you produce might change if you use F sharp versus C sharp versus a node versus whatever.

[00:04:03] Dave Adsit: I completely agree with that. Like that's been my experience as well. I think, you know, 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 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

[00:04:41] Matt Baker: been told. I've got lots of thoughts coming now. I think also there's the relationship between someone and the tools that they pick. Like as you go on 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 do programming languages 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.

[00:05:29] Allan Stewart: There's an interesting relationship there because 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 you'll get it. 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, oh, the syntax of this, you know, 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 accessing a method on a class or something like that. And so it's really easy to fall into these really superficial point. 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 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 of 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: That'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 functions, what were clearly the same functions given different names, like string underscore slice versus substring versus like strslice. 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 he clicked to the next slide and he's like, and these are all just in PHP.

[00:08:08] Allan Stewart: Yeah. Yeah. 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 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

[00:08:45] Dave Adsit: database. 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 A and D 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 sharp that were like, you know what we really, really like? C++. But you know what we're bad at? Pointers. Also memory management. So let's add garbage 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 sharp. 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++, which was a lot better than Notepad. It was. It really was. But also a lot more complex. It 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, there are benefits and drawbacks around what has become idiomatic for a language. You can see this a lot JavaScript is anchored into JavaScript. JavaScript is anchored into JavaScript. JavaScript is anchored into JavaScript. JavaScript is anchored into JavaScript. JavaScript is anchored into JavaScript. JavaScript is anchored into JavaScript. JavaScript is anchored into JavaScript. JavaScript is anchored into JavaScript. JavaScript is anchored into JavaScript. JavaScript is anchored into JavaScript. JavaScript is anchored into JavaScript. JavaScript is anchored into JavaScript. JavaScript is anchored into JavaScript. JavaScript is anchored into JavaScript. JavaScript is anchored into JavaScript. JavaScript is anchored into JavaScript. 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 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

[00:12:55] 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 updates change or things you did do may no longer work. And it's hard to always respond to that change. And I think the thing I've seen as companies grow, at least in places I've worked anyway, you pick a tool and you use it right for a like, you start to contort it. And 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 weak time to do things like that. Right? Like some places I've seen be like one in every five days. or I don't know, once a month, they 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 concept. I remember in one code base that I worked on, we decided that we wanted to start using the maybe monad in C-sharp. 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 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-sharp. It's probably my favorite language and it's really interesting to see as it evolves more and more functionally. 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-sharp? 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-sharp 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 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 debug it. I have to debug it every time to find out. Then I get sad. So yeah, I think 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 very prevalent in the time when I was writing most of the Java that I wrote. And so C-sharp 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-sharp 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. I think C-sharp 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-sharp is a good language. I think C-sharp is pretty cool. 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-sharp 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-sharp, Mac OS.

[00:18:23] Dave Adsit: Which honestly, that was the thing that held C-sharp 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, you can do it. 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 Iron Ruby and Iron Python went into the recycle bin because the only languages that really get support on the CLR are C-sharp, F-sharp, 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-sharp is constantly adding some of the coolest features, I think, like link, the language embedded query language or querying or whatever. And generics and type inference and 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. 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 on a little side project for the last couple of years, and it was in Kotlin. And I really liked it. I thought the language was pretty crisp.

[00:20:27] 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:42] Allan Stewart: Yeah, 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? 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, it's just a language. Sometimes the back end 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. And then you've got your backend language, which could be anything Ruby or Python or closure or C sharp or JavaScript or whatever. And then you've got to have your front end tool kits. 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. 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 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. 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. 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. Or if you're optimizing for like. Some people get myself included. Some people get like purist, right. Where it's like, 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: 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. Yeah. Yeah. and they need it as quick as possible. Like, I don't know, that feels wrong. That feels like a bad time to indulge in that thing you should go with what you know, or you tell them, right? Like, hey, do you care? Person who 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, we could do a better job maybe embodying this point. And it changed for me. I think when you are the person who's writing the check for the code being written, 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 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 hire someone, think about it from their perspective for a minute, like to hire someone that comes in and indulges like their coding fantasies to a degree, like, 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 math, 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 is what is best for the business. And for me personally, that comes down to what language can I use or languages realistically? What languages can I use to express this business, this 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 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:15] Matt Baker: And... Hey, expand on that real quick, Dave. Like 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, 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, you know, balance having fun with delivering product and delivering value. And I think that's all great. But at the end of the day, 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 sharp because, okay, two things, both of these are pretentious. 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 sharp developers. If you picked a .NET language, you probably picked C sharp unless you're an amateur. And then VB is a little bit less intimidating.

[00:30:21] Matt Baker: I think it's important too. Like I think about this as a golden rule, what you're talking about, Dave, this person that wrote the Scala app and then left the company. It left them 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 end of the day, their choices left the company in a 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. Like 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 people. 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 Tyobi language research website. I can't remember what 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 sharp. 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 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 is fun. Like the culture, the allure around it is fun. Like it's a cool thing. But I agree with you. Like if I'm going to have to go hire people or maybe if you're confident, 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, don't pick it. And if you're being paid to write some software for someone else, like consult them at least. Be like, hey, here's a consideration to make. Your ability to hire into the future and your ability to continue to operate this product, this impacts that. What do you think? And I think we could probably guess what they would choose.

[00:33:36] Dave Adsit: Well, 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-sharp 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-sharp 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 process. and delivered fewer features later so that I could come up to speed on Python.

[00:34:57] Allan Stewart: 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 for you.

[00:35:07] Dave Adsit: That's true. I did. And the reason I kept that is because I had some mentors and 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.

[00:35:33] Matt Baker: It helps. That decision you're talking about, Dave, to rewrite, that's a tough one. I don't know a guidance for that other than it just comes with time. You get better at knowing when to do that because there's definitely scenarios where that's not the case. And there's definitely scenarios where you shouldn't rewrite it into a language you're more fluent in. And I don't know. I try and, as you think about that, I try and distill it down to what's the nugget of wisdom there. And it just comes down to it depends. 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 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. Like you 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 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 you're not, you tend to broaden out and you don't get as deep. 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 wanna only have one thing that you're really deep on. But then also for a company, right? If you have to manage 17 different languages across the company, you know, and there's only 10 teams, then it's gonna 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 this?

[00:38:57] Allan Stewart: 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? Like, so maybe you want to use Dynamo or something out of AWS, or, you know, 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 Sharp. Well, maybe you should pick up something pretty different instead, just so that you expand the herd. But also can use them in the places that they're particularly good at.

[00:40:01] Matt Baker: I was reading this paper. See, so the main assertion in the paper was that complexity comes from 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. If those two anchors are anchored together, those anchors are anchored together. If those anchors are anchored together, those anchors are anchored together. If those anchors are anchored together, those anchors are anchored together. If those anchors are anchored together, those anchors are anchored together. If those anchors are anchored together, those anchors are anchored together. If those anchors are anchored together, those anchors are anchored together. If those anchors are anchored together, those anchors are anchored together. If those anchors are anchored together, those anchors are anchored together. If those anchors are anchored together, those anchors are anchored together. it rings true for me like as i look at the maybe if you look at the software organism in a company this kind of ecosystem 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 my sequel is different the way 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

[00:41:27] Dave Adsit: yeah 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 like pair with somebody in a different language and 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 i've paired with people on small pharaoh small talk 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 tool box 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 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 tips are great but those tips are great but those tips are great but those tips are great but those tips are great but those tips are great but those tips are great but those tips are great but those tips are great but those tips are great but those tips are great but those tips are great but those

[00:43:22] Matt Baker: either, if we're being honest. Yeah. 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 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, 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. JavaScript is a prototype. 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 Sharp, C++, whatever. Though Scala would probably say that we're a functional language and like, well, you've got a lot of OO

[00:44:47] Matt Baker: characteristics. Yeah. If someone asked me how to vet a technical decision, I would say, well, you're not the only person in 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? Yeah. 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 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 with 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

[00:47:20] Matt Baker: written Java for many years. 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

[00:47:46] Dave Adsit: use. 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 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 $10,000 less $15,000 less a year to use the language that they want to use. Seriously, or they might, they don't care about your I've riffed on snack walls before they don't care about your snack wall, but and they don't care about your in office perks. In fact, like, you could probably save money and not do some things but you and emphasize other things. Anyway, I think this ability to play with new tech is, 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 were saying, if you're on job on Android, it's time to invest in getting over to Kotlin. 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 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 different types of languages, functional languages, 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 like, okay, we want some types so that we can have some additional way to understand what is going on in our system. And so they put TypeScript on top JavaScript so they can build Angular. I think there's something there but on the other hand, I've also really enjoyed 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? I definitely think there's

[00:52:16] Matt Baker: something there. Like I feel like JavaScript, the evolution of JavaScript, it's like the biggest instance of a code base rotting that I've ever seen, right? Like the whole ecosystem. And before like 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. And Java, the JavaScript ecosystem, I think like given the challenge in front of them has done a pretty good job. It's such a massive scale, like 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 dumb dumb 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 say 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 reacts is starting to mature into a pretty good tool, 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, it's crazy. But maybe more directly to this point, you're talking about Allan, the language, the dynamic language that was touted by everyone as like any person you talked 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, 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 so much. Great. I can go so much quicker. And in a certain context. Absolutely true. Like a greenfield project. Yeah, definitely. But as the project grows, and the number of people on it grows, that changes, then you see it in JavaScript. 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, okay, at a certain scale, you do need types. And 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 a 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, like, hey, I appreciate like watching you go along your evolution to learn my point.

[00:55:21] Dave Adsit: Yeah, 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. I just one more thing on that. I just so I don't miss get misrepresented there. I don't have, I think it's so contextual. This whole like choice, I think is so contextual. And that's why I'm making fun of this argument that dynamic is always better. What is it? What a dumb thing to say, like, what do you mean? It's always no, like circa 2000. What's that 2007 JavaScript developers, it's not better. Like it's just it's contextual, you know, 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 back end and software architecture. 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 back end developers had been using for a while, seeing the front end developers discover them as though for the first time was, it shows you that there's cycles in all things.

[00:57:37] Allan Stewart: 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? For me, writing

[00:58:12] Matt Baker: functional 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 maintain that little beautiful little Lego. It's just a joy to write code in that language or in that way. I think writing functional code in JavaScript is the, that's the time where I can get there most because you can do all this cool stuff, but it's loose. It's not as draconian as some other functional 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 sharp. I had not used it. 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 sharp equivalent is, you can add a new array, dot union, other array, dot two array. And that creates a new array with the contents of those two previous arrays. And the, 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 pattern matching, I think is also a really cool feature that is finding its way

[01:00:02] Matt Baker: into more and more languages. Yeah. When I get the chance to use pattern matching, I'm always a little bit. It's fun to, it's fun to implement those. I like using pattern matching to, to destructure

[01:00:13] Dave Adsit: elements in, in C sharp in a way that it wasn't previously possible. And it's 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

[01:00:31] Matt Baker: it on my shelf and then use it there. 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.

[01:00:41] Dave Adsit: It's it's in it's in C sharp. You use it a lot with tuples. You're like, I want this part, but I don't care. You can name it with records. It's so slick. And I agree with what you just

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

[01:01:06] Allan Stewart: is another one 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?

[01:01:25] Dave Adsit: No. Cool. The records are only use value-based comparison. I think you could probably override and do whatever you wanted, but 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 link functions, the link link as a concept language embedded querying in the dot net languages, especially C sharp 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, as predicates to all kinds of filters and projections and things like that. Of course, because they were coming from a database paradigm, they use the wrong words for them all and call them where and select, but it's the same concepts. And so it's really awesome.

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

[01:02:42] Dave Adsit: just not in the database. A hundred percent agree with that. If I find link 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, why are you both so averse to it?

[01:03:01] Dave Adsit: I think for me, the biggest problem is that there's an impedance mismatch between 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. 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.

[01:03:47] Allan Stewart: I'd more or less agree. 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

[01:04:04] Matt Baker: at all. For me, it was, so I agree with the praise for LingQ. It 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, like when you see something like composability come into a language that you're really familiar with, because I was writing C-sharp at the time for my job and it was really cool. And 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, I can't remember what it's called, but misunderstanding when like 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 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 link statement. But 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 link statement partway through might load up a whole set of data and then start to filter it. But because of the way I wrote the link statement, it loads the whole table into memory and then starts to filter it. And so definitely boo on me, but that was a practical one day-to-day that caused me to get away from it. And then I read, I don't know, I don't know, I don't know. I don'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, somewhere they wrote that and that really resonated with me. And that was around, that was when I kind of stopped using RMs 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, I definitely couldn't

[01:06:01] Dave Adsit: put to words myself. 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:34] Dave Adsit: So you can get rid of your ORM.

[01:06:37] Allan Stewart: 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:11] 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 I8 days and just only have databases.

[01:07:25] Dave Adsit: Mm-hmm. So I guess that's the thing is that every language has a lot of dark, scary parts. In fact, I said earlier that C-sharp was an attempt to remove the necessity of memory management from C++, but C-sharp 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. Yeah. Yeah. Yeah. I 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-sharp and be like, oh my gosh, there's so much overhead, but compared to yet C-sharp. I feel like C-sharp is 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. And I wonder, I assume that's what you meant, like the white space. And 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's definitely less natural to me to use white space to indicate the scope or the structure of the programming language. But I'm getting more used to it when I fall back to curlies. Yeah. So I don't know, maybe different strokes.

[01:09:33] 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. 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 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.

[01:10:31] Allan Stewart: Yeah.

[01:10:32] Dave Adsit: 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 just, I think we should all go back to XML or SGML if we can. Do you remember XSLT?

[01:11:03] Matt Baker: Oh, sure.

[01:11:04] Dave Adsit: Oh yeah. I wrote, 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: Yeah. It just like, it kind of makes me cringe a little bit when I think of XSLT. specifically. Like it just, I think it was all me just writing just horrible code. Um, but it was definitely a fight every time I had to work. I ended up writing my own XML tools several times

[01:11:46] Dave Adsit: where you could paste XML and XSLT and hit a button and it would generate the output. 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. I did not have that luxury. What

[01:12:05] Matt Baker: you just said is brilliant. And I should have done that. Um, 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 allows 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. Cause you'd have to like, let it get into the system and then it had to rebuild and refresh. It was, it was maybe now that I'm saying that maybe that was the more painful part.

[01:12:59] 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 to a proprietary language. 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 suite, you know, I went to dinner with him. It was a business dinner and he was a developer in this particular ecosystem. And, 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 it? Proprietary language. And I like due to the business relationship, I just smile. And I was like, oh, that's a lot of good points. Like had it been more casual than 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. It sucks.

[01:14:56] Allan Stewart: 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 node and stuff like that. Like, okay, actually this is pretty cool. I changed my mind. I like it. But then over in C-sharp, 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 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 imperative shell. And it really changed my mind. I 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 sharp to, okay,

[01:16:08] Dave Adsit: I get it now. It just feels like it's the wrong way, right? Because of the evolution of C sharp, 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. There's a little bit of that. And also

[01:16:26] Allan Stewart: 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. Yeah.

[01:16:56] Matt Baker: Same conclusion on how to wield it successfully, Allan, by pushing it to the edge and the imperative shell functional core, I think captures it. There's a joke I heard that I really liked 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. Like 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, 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 link.

[01:18:10] Matt Baker: That's another one of those just like aesthetically pleasing moments in 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 just gonna put those together.

[01:18:42] Matt Baker: and put those together and put those together and put those together and put those together and put those together and put those together and put those together and put those together and put those together and put those together and put those together and put those together 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 to uh 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 like you this language is beautiful and then like 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 management right so we talked a little bit about how important

[01:19:45] Allan Stewart: it is to experiment with other 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 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 martin fowler has a i don't even know if

[01:20:10] Matt Baker: he's the one who said it but uh 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 a lot in small chunks and to put a practical value to that i think um 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 it at places i've worked before and i always appreciated it it was it was more pleasant and also i think 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 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 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 uh and some of them are going to be painful and gross and you're going to say that was a bad outcome we don't want it and good you can just rewrite it again and some of them will hit and you'll say hey that's an advantage for for what i'm doing here dan north

[01:21:42] Dave Adsit: has said a few times that functionality is an asset and code is a liability so that's just an

[01:21:49] Matt Baker: you're saying that yeah that's actually how i got it from i was at a workshop with him out and 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 it's totally true so code is more like brie

[01:22:08] Dave Adsit: 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 nice

[01:22:19] Allan Stewart: 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 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: I think 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 thoughts on that. 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

[01:23:59] Matt Baker: weren't necessary. I don't know. 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 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 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. I was just going to like pretend like psychologically 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 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

[01:24:53] Dave Adsit: to do it. 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, you know, 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 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

[01:26:28] Matt Baker: code, unless you are in fact a code artist. What if you do it with reflection? Can you do it with?

[01:26:34] Dave Adsit: Oh, well, that's okay. 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:59] Allan Stewart: 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 integrate. interact with us. And mostly we just did like simple little animations. It was a lot like visual basic, but earlier. And, uh, 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,

[01:27:30] Dave Adsit: nobody does HyperCard anymore. That's awesome. My first, I believe was Apple soft basic, which I only recently learned was actually derived from Microsoft basic, which was interesting to discover. But then I went from there, you know, at school we had Apple two E's. And so I got to do Apple soft basic on the Apple two E'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 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 that scratches so much. It's fun. One of the thought, when we talk about programming languages, like I think we could 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 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 one of the days this week, like with the, my morning cup of whatever it was. And the first task on my list that day was to read a bunch of AWS documentation for, it doesn't matter, but it was a series of technical docs. And I looked more, I looked forward to that more than I did. And I was learning 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 it was, it was a great day. And those days have just been happening more for me. And so it's, yeah, again, I'm just saying the same thing over again, but 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, drew some, some line art with a 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 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 zealotously with you about your favorite languages there.