Learning New Programming Languages

About this Episode

The panelists explore the value of learning new programming languages. The conversation begins with personal stories about their first programming experiences, discussing languages like Logo and BASIC and, later, more complex ones such as Java, Pascal, C, C++, Perl, PHP, Haskell, and Python. They emphasize how each language forces a developer to think differently about problems, highlighting the significant role of learning various languages in a developer's growth. They also touch on the practicalities and peculiarities of different languages, like the ease of PHP compared to C for web development and the sophistication of memory management in languages like Java and Rust.

The discussion then pivots to the core question of the podcast: the value of methodically learning new programming languages. Mike shares his perspective, noting that while he hasn't learned a new language every year, the variety he has learned has been crucial for his career development. Tad recounts an insightful conversation with Matz, the creator of Ruby, about the joy and utility of learning diverse languages, even those with limited professional application. This leads to a broader discussion about how each language, with its unique approach to solving problems, can add valuable tools to a developer's toolbox.

In the final part of their conversation, they delve into the future of programming languages and discuss the potential of domain-specific languages tailored to particular industries or needs and the role of emerging technologies in shaping how we interact with technology. Mike speculates about conversational interfaces and their implications for future software development, emphasizing the importance of adapting to new ways of thinking and interacting with machines. They end with an affirmation of the continuous need for learning in the ever-evolving field of software development, underscoring that learning new languages enhances problem-solving skills and prepares developers for future technological advances.

Transcript:

MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike. I'm going to be hosting today. And together with me, we have Ramses and Tad. Today, we're going to be talking about learning new programming languages, specifically what value you get from learning them. And beyond that [chuckles], not just learning them because you're forced to, but deliberately going out and learning languages regularly, you know, once a year or some cadence like that. And why would you do that sort of thing? That's the premise we're going to start with.

And before we really dive into the conversation, Tad, before we jumped into the recording, said, you know, a good place to start here is talking about the first language you learned. Like, yeah, you know, actually, that's a great idea. And thinking back to childhood, the first programming language I learned was Logo. They called it the turtle, but I think it's really just a triangle. And you [chuckles] make it go around the screen, and it leaves a trail behind it. And you could use it to draw pictures.

I didn't have a computer at home at the time, and I'd used it at school. And I thought it was just the coolest thing ever. I believe that it usually ran in a real-time mode, where it was interpreting what you put in. It was actually pretty sophisticated for back in that time. The read–eval–print loop is, you know, very common now in interpreted languages, but back then, that was pretty sophisticated.

My understanding is that Logo is a variant of Lisp. I didn't know I was learning Lisp. I was just learning how to move the turtle around. I thought it was the coolest. And I do remember that I could go back into a screen where you could actually write some code, rather than running in that real-time evaluation loop, and then have it draw cool patterns on the screen, and I thought that was just the best [laughs].

I remember thinking it was so cool, but then you had to have shared computer time with everybody else in the grade. It might have even been shared with everybody else in the school. So [chuckles], I didn't get a whole lot of time on the computer. And I didn't really pursue programming that much other than thinking that it was cool. Sometime after that, I couldn't say exactly when, but I think I had friends that introduced me to the BASIC programming language.

BASIC has a very different take on things. The lines are numbered. You always had to put numbers, and you developed a habit of incrementing by at least 10. You'd do line 10, line 20, and line 30. So, in case you ever needed to insert anything in between, you didn't have to renumber every line. I've had to do that [laughs] in BASIC, to go back and renumber everything. When my family first got a computer, it came with a BASIC interpreter. And we had a book, and I went through, and I did a lot of BASIC programming. And I did. I'd fill up all my spaces; then I'd have to go renumber everything.

The thing, though, about switching out of the languages, I learned about BASIC-supported subroutines, they called them. They had GOTO, so you just bounced around just at random [laughs]. If you wanted to be able to have any ordered thing at all, you would develop...it wasn't a function like you'd think about in more modern programming languages but the same idea what they called a subroutine where you could go to this region of code that would execute independently.

TAD: GOSUB [crosstalk 03:09] GOTO.

MIKE: Exactly. GOSUB [laughs]. I think you could even treat them as function calls and pass variables to them. Do you remember Tad?

TAD: You couldn't with the BASIC I learned. There might have been BASIC variants that could do that.

MIKE: Yeah. It seemed like they could maybe have return values. There was something that distinguished them from a GOTO. And then I did a lot of that when I was in my early teens. And the next programming language I learned was probably Pascal in school, and asked to learn Java, and C, and C++. And professionally, your first job, you usually end up picking up a language because you end up having to do stuff you haven't done before. I learned Perl and then did a lot of Java, PHP, web languages back in the day. But I ended up touching a lot of things. There was ColdFusion [laughs].

TAD: Oh gosh.

MIKE: Yeah. And then later, as I moved along in my career, there were actually some languages I learned just to learn, and I think I'm going to come back to that. But Haskell, specifically, is one that I deliberately chose to learn, and I'm glad that I did. I've learned Python somewhat in recent years, which has been a useful tool.

The interesting thing about this, I'd mentioned the subroutines [laughs], is that every one of these languages forced me to think about problems differently because these languages represent a way of thinking. They approach a problem in a slightly different way. There's a lot of overlap between them. Once you've learned one, it's a lot easier to pick up another. But making that switch between languages really forces you to recognize that maybe there's more than one way to think about a problem. And then you're forced to evaluate, well, which way do I want to think about the problem? And that switch between frames of thinking, I think, has been very useful.

I would strongly recommend that people take the time to learn other languages, especially languages that are very different than what you're used to. I think it's useful to learn Assembly language, for example, maybe not in-depth, but at least to understand how it works so you can think about how a processor works. I recommend learning a functional language. I've mentioned Haskell. It's a pure functional language that really forces you to think in a certain, very mathematical way, and it helps you approach certain problems differently.

And you should probably learn an interpreted language if you've been a compiled language person all the time and so on, approaching problems differently. So, there's my limited introduction. I'm saying this history of languages I've learned has helped me a lot, and I'd recommend others to do the same. Now, Tad, you've been talking a little bit. What's been your history with programming languages?

TAD: My first programming language was BASIC, which is probably really common for anybody who grew up in the '80s like I did. My parents bought the family an old computer. Texas Instruments used to have a computer that they sold that you could plug into your TV. It was called the TI-99. And if you put a cartridge in, then you could play that cartridge. But when it booted up, there was always a menu.

Number one was it dropped you into a BASIC shell thing, or number two was play the game. And so, after you've been using this computer for a while, you're like, huh, I wonder what that, like, number one option is, right? And it just basically just dropped you into BASIC. And, like you were saying, it came with a manual that gave you the basics of BASIC. It was, like, line numbers, and you'd always do 10. You're like, ten prints, you're awesome, 20 GOTO 10. And you're like, ah, like, you show your sister like, "Oh, look, our computer thinks I'm awesome," or whatever.

But yeah, like, that was just being able to have something to show up on the screen. It gave you BASIC syntax, you know, control structures like ifs and thens and all that stuff. If this, go to there; if else, go to this, that kind of thing. That was what I thought programming was all about was just big, long, BASIC programs.

And I remember later in the '80s, Macintosh Classics became pretty ubiquitous at, like, high schools or just different schools and stuff. They all came with HyperCard, which had a programming language behind it called HyperTalk. And I remember trying to look through the mail trying to figure it out because I looked at the examples, and they didn't have any line numbers. And I couldn't conceive of programming without line numbers. I was like, how do you go to something if you don't go to a line number? Like, how do you use your GOTOs if you don't have line numbers, right? And so, that was kind of an eye-opening idea that, wait a second, I don't need GOTOs at all? How does that even work, right?

MIKE: [laughs]

TAD: And HyperTalk was really interesting because it was very English-like. And the idea was you basically have a stack of cards. Each of those cards, you could put different buttons and different like UI elements on that card. And then, you could have those UI elements; each of them have some code behind them. And then you could swap between the cards and things like that.

And so, the very first thing that you could do was make a stack of cards and do a different picture on each card, and then your program would just be, show all cards. And that would just flip through all the cards and create a little animation for you, right? And just the fact that it was English and you could say, "Show all cards," and that was just intuitive, right? And was just kind of mind-blowing. You could set the speed that it shows all the cards. And so, something like that where it was very English-like, very intuitive.

But it was also evented. So, you could write little handlers. Like, you could say, "On mouse up," and then you would write the body of the things you want to do when the mouse is clicked, or whatever, or on button clicks and things like that. And so, it kind of put me into a mode of looking at things from, like, a UI perspective and event perspective, you know, messaging back and forth between the different elements and stuff. And so, that was a huge departure for me from BASIC.

And then probably the third language I learned was C, which, again, is very different because it's the first time I ever had a compiled language. It's the first time I really thought hard about functional programming, probably the first time I ever encountered libraries and shared libraries. Because I'd have to yell pound, include standard io at the beginning, right? You don't just get that for free. You have to, like, ask for io stuff. You have to set up a main function. You have to do those sorts of things. So yeah, that was also a very different language from the first two I learned as well. So, anyway, yeah, like, it's all very interesting to learn.

MIKE: You talked about HyperTalk changing your perspective because you thought, oh, things don't have to be this procedure where you control the flow yourself. The language can do some of that for you.

TAD: Right. Yeah.

MIKE: And teaching you about libraries. I mean, those are major concepts, right?

TAD: Yeah. I mean, my simple BASIC interpreter didn't have libraries. HyperCard just had everything built in. You didn't, like, grab things from external sources. I think you could, but I had no idea of what that was or what it meant.

MIKE: So, you know, there was that step, the step between this in a progression. Sounds somewhat similar to the things I did, I have learned over time. So, Ramses, I'll ask you, I don't know how many languages that you have worked with.

RAMSES: Certainly not as many as you or Tad, I'm sure [laughs]. Probably started with Lua, I want to say. Like –-

TAD: Oh, nice, yeah.

MIKE: Embedded development.

RAMSES: Yeah, it was great.

TAD: A lot of kids are, like, Roblox and stuff when they start learning Lua.

RAMSES: Yeah, it's a pretty good platform for that. It teaches a lot of the basics and gets you familiar with a lot of the core concepts of programming and, you know, communicating between client and server and back. And my primary, of course, is Ruby, mainly Ruby on Rails. I do have experience with JavaScript. I'm currently learning Java, and I have tinkered a little bit with Elixir, not enough to be proficient.

MIKE: Well, let me ask you a follow-up question. Maybe I should ask about Elixir because it stands out among those as being distinctly different. But there's, I mean, there are differences between those languages. What's something that surprised you or helped you progress from one of these languages, Ramses?

RAMSES: Mostly curiosity, I would say. That's the biggest driver for why even try to approach something different.

MIKE: Absolutely. Curiosity kind of drives the learning. What is something you've discovered in a language that made you think, oh, well, that's different?

RAMSES: Well, I don't know if this is the biggest one, but I thought the pipeline operator in Elixir was very interesting.

MIKE: I was talking with some people about that this morning [laughs], just this morning, comparing that with an attempt to do that in a language that didn't support it. That didn't work out so well. That pipeline idea of having a series of steps that you can break out on it's a great idea, right?

RAMSES: Yeah.

MIKE: Once you see it, you know, like, you can't unsee it [chuckles]. Like, wow, that's a good way to approach a problem. And, Tad, you've mentioned a couple of things that were enlightening to you [laughs], the epiphany. Are there any others that have really stood out to you?

TAD: I did a bit of Closure for a while. Ruby is Lispy, but it's not Lisp, right? Ruby has certainly stolen a ton of Lisp ideas, but it's not, like, that pure. I see a bunch of parenths on my screen. Everything is nested parenths Lisp. And they also have, like, a kind of a threading operator—I think that's what they call it—that kind of pipes things through. And I mean, with C, you get pretty functional. But Lisp is probably the grandpa. I'd say it's probably the purest, most influential functional language there is.

So, once you get into that mindset of, oh, everything is data, everything is streaming data and transforming data, it's interesting how you start to see every problem of, oh, how could I just make this as a series of pieces in my pipeline and my data is just going to flow through them all, right? And you realize, oh, this is very predictable. This is very easy to test. And it's really interesting to get put into that kind of functional programming mindset.

MIKE: I can say you're noticing a similar idea of these pipelines.

TAD: Yeah.

MIKE: There was a moment for me...I could talk about a different language, but, actually, it was, I think, a comment I read in a book I was reading that said, "Well, if you think about SQL and how it does things, that's basically the way that functional languages do things." Like, wait, what? I've thought deeply about that since. SQL or SQL, some people call it, sometimes it stands for some things, sometimes it doesn't [chuckles]. The language used for creating databases.

It's this widely used language that is completely declarative. There are, like, variants on it that allow you to do some procedural stuff where you can have loops and so on. But out of the box, you can declare the kind of transformations you can run on the data you start with to get a set of data out. And you might think, well, what good is that? What good does that do? All you can do is transform data. I mean, does it do things? And yet, it manages to be kind of the foundation of a lot of what the web is built on, right?

We have databases. We have data storage. And somehow, you need to present that to your users, and in between, you need to transform it. And I don't know if I want to say we overthink our value, but I don't think that's quite true. I think I would rephrase it differently that sometimes we don't recognize how valuable it is to be able to take some source data, run some transformations on it, and display it to somebody.

You think of even a social network, pick your social network. Somebody who's listening to this 20 years from now they'll go, "Huh, they were using those?" [laughs] But what's the biggest one today? It's probably Facebook. You know, they collect vast amounts of data on people, maybe scary amounts of data [chuckles] on people. And then, they compile that together and present it to you. And it's really data transformation. And they start with some source data, they mix it with some rules, and they show it to you. And they've managed to build this massive company. It's one of the top five most valuable companies on Earth. It's what they do.

Or you look at, say, Google, that has powered the, you know, web for four decades now. They store a bunch of information about their web crawls, and they show you that data [chuckles] after they've, you know, stored it and indexed it. The ability to efficiently store information and efficiently take that information and somehow transform it into a useful format to read because, you know, the whole web out there is not very useful to me because it's too much. I can't find anything in it.

But if you can save that in a way that's well indexed and can be returned to me in a sorted form with the most relevant things up front, well, that's exceptionally valuable to me, you know. It has made them vast sums of money because it was incredibly valuable. Advertisers have spent a huge amount of money on these platforms because people use it because it improves our lives.

So, this transformation of data, this idea that you start with some data, you run some transformations on it, and you get data out on the other side that's in a more useful form, I think is fundamental to most of what we do in software development. And once you think about that that way...and both Ramses and Tad talked about this kind of pipeline idea, that you start and you go through these series of transformations, and you get something out the other side. It's been transformative to me.

I think I mentioned I studied Haskell a few years ago, a functional language. Everything's built around that idea. And internalizing that idea, of course, not just from Haskell but from other resources, I think has been very influential on me as a developer, and some of the best code I write is rooted in those ideas.

TAD: What's a language that's on your radar right now?

RAMSES: I know Python is kind of the new hot [inaudible 17:49]. It's been the hottest for a while.

MIKE: Yeah, the old hotness [laughs].

RAMSES: The old stuff. I mean, there's --

TAD: Since the '90s.

RAMSES: Yeah, it's kind of a big one currently; probably would like to learn it more at some point. But, my current focus is Java.

MIKE: If you know Ruby, switching over to Python is almost trivial, not completely. They're slightly different, but they have very similar paradigms. My language, I would say, Julia.

TAD: Oooh. For data stuff, huh?

MIKE: Yeah, I've been interested in data for quite a while. And I am really interested in machine learning. And a lot of machine learning world is using Python. That's mostly what I've done with Python. But Python is not known for being efficient [laughs]. There's people working on that. There's people working on that, I'll say. I'll give them credit for that.

But there are, you know, lots of different tactics people have taken to try to deal with them; one of those is to create a new language, and Julia is one of those. And that's one that I've been interested in trying out. You know, I don't know that I'd use it on a day-to-day basis, but I'd like to see that approach to the world. What about you, Tad?

TAD: I remember when Swift came out, they gave you a free book like, Apple says, "Here's a book on Swift," when it first came out. And I've always thought that Swift looks really interesting. It's obviously a language that has drawn on a bunch of other languages and looked pretty clean.

And some of the interesting things that I liked about it that I'd like to see in other languages are optional typing because I don't love forced typing. But I think typing can be useful sometimes, right? And so, I'd like to steal the idea of optional typing from a language like Swift and then give it to maybe a language like Ruby, right? Because Ruby is all dynamically typed. But I'm like, uh, sometimes I'd like to have types.

I've had some Elixir books for a while. They do some really interesting things, especially with their matching, where it's basically make this side match that side. The destructuring that you see kind of popping up in other languages has largely been inspired by Elixir and its ability to just really nicely destructure things, right?

MIKE: Yep. That pattern matching has been a thing in functional languages for a while, and it's cool.

TAD: Yeah. I think Elixir really took it to the next level. I don't know of other languages that did it. Well, I'm sure Erlang does just because what's under the hood of Elixir [inaudible 20:27]. Elixir put a nice, approachable veneer over that whole beam, the whole ecosystem there.

What other languages are interesting? I like Lua. I learned a little bit of Lua with my kids. I think it's like a better JavaScript. I wish that they would have discovered Lua, and we would have had that instead. Rust has been on my radar for a while, but I just don't have any use for it in anything I do day to day.

You know, just speaking about how languages change your thinking, I did a ton of C in college. And then, when I got to some of the upper-level classes, we started doing Java and stuff like that. And I was like, oh wait, what? You don't have to do memory management? There's a garbage collector? Wait, what's going on? Like, the fact that I could basically run my Java programs cross-platform-ish, you know, on the JVM for whatever operating system I was on.

And Java, you can kind of fake it where you could put pointers to different references...I forgot. I haven't done Java in a while. But you could mix and match an array, and you could stick different objects in an array if you just made your array object references. I was like, wait, I'm getting tricky, right? But yeah, the fact that Java had different memory handling was really interesting to me. And Rust, I think even more so, the fact that you can get the performance of, like, a compiled language with memory safety, and you don't have to hand that off to a garbage collector, is really interesting, I think.

I've seen the argument or the joke: you're just moving all that stuff from the compiler into your head, where you just have to think real hard to do your memory management instead of letting your compiler or your language do it. But yeah, so there are still languages coming out that have interesting ideas that I'd like to explore.

MIKE: I think that provides a good pivot to what kind of our central theme was that we wanted to talk about in this podcast. We've talked about some value we've gotten from languages. What's the value in methodically going out and learning them? Is this something people should do, and if so, how often and why? And maybe a split question: what happens if you don't? [laughs]

I will say I have not specifically made a point of learning a new language every year. But if you add up all of the languages that I've learned, I'm probably not too far away from it because there are a lot of languages out there, especially if you count non-procedural languages, you'll get HTML, CSS, SQL, even, like, Regular Expressions. There's a lot of languages that we learn as developers, and if you start adding all the languages up, it can add up to quite a few. And I think I'm not too far from one a year.

I would say that if I hadn't done that, I would not be in a good spot. If I'd stuck with Perl, I'd be an aging guy still doing Perl [laughs]. And Perl's not a bad language, don't get me wrong. But professional opportunities are rather limited nowadays in that language [laughs]. And it has a lot of interesting ideas. Perl is actually a fascinating language where they've experimented with some things, kind of tried to push the boundaries. It's Larry Wall, right?

TAD: Yeah.

MIKE: That built the language. He studies languages professionally. He really thinks about interesting things you can do with language. So, great language. I'm not saying something bad about Perl. But if I was just doing Perl, or if I was just doing Logo that I learned in elementary school, again, it's a Lisp variant. Lisp is great. We've talked about that already and how it helps us think, but there are some constraints there.

If I had not moved into modern variants of Lisp, if I had just stuck with what I had, then it would have constrained the boundaries of my world. And I'd rather break down some of those walls and go explore places that I hadn't been, and maybe find places that I'd rather be. What do you all think?

TAD: It's interesting because I actually was at lunch one time during a conference, and, Matz, the creator of the Ruby language, was at lunch with us. And we were talking with him, and he learns all sorts of languages all the time. I guess that makes sense. If you're the creator and a maintainer of a programming language, you want to scan what's out there and see if anything's interesting to incorporate into your language.

But for him, he learned languages that he wouldn't even consider including in Ruby, right? Like, he told us, "I love every language. I just love learning languages. And I love every single programming language." And we kind of poked him on that a little bit. We're like, "Well, do you love PHP?" And he's like, "Yeah, I love PHP," or like, uhhh, or a groan, or whatever. And we threw a bunch of languages at him, and he's like, "Yeah, like, I just love to see what language designers are trying to do. I love to see what languages are about." And his take was every programming language offers something interesting for him. And so, that was a really interesting conversation.

I don't love every language. But he's probably right. If you stop and think, what does the designer try to do? What is a problem set that this language is trying to accomplish, right? Then maybe that gives you another tool for your toolbox. I don't know Fortran, but I imagine if you're a scientist, Fortran is, like, an amazing language, right? You're like, oh man, this maps really well to my whole world, you know, like everything I need to do. I think I probably should be learning more languages because there's still a lot of new ideas coming out, right? And every language that you've learned shapes your thinking a little bit.

You look at Ruby, and then you can see, like, oh, Matz uses Emacs. So, he did a bunch of Elisp, and Ruby is heavily influenced by Lisp. And he did Perl programming, so Ruby is influenced by Perl. He loves object-oriented stuff, so Ruby is very Smalltalk-influenced and stuff like that. And you can see how, for him, he wanted something that made him happy. And he's like, these are some parts of other languages that make me happy. I'm going to instill them all into a single language, and that will be my ideal language.

But other people have other ideal languages. I think every language designer the language that they design is probably their preferred or, I mean, Rich Hickey loves Closure, right? Like, he thinks it's the ultimate best language. He is just sitting in his hammock thinking about Closure [laughs]. Like, he has a lot of stories of him just working out new ideas about his language, just sitting in the backyard.

MIKE: You brought up a couple of interesting things. You said Matz loves PHP. The first time I used PHP, I loved it. Now, let me put some qualifications on this. I have actively avoided doing PHP professionally for a long time. But when I first used it, the very first time I used it, it fulfilled the need I had at that moment.

It provided me a template with some simple access to code so that I could put some control structures into the template; you know, I could loop a section, for example. And if you think about what it was good at and its purpose, you know, the reason it came into being, for people who are met with that need, that's an extremely useful language and has been widely used, you know, around the world for a long time.

TAD: Did you ever generate HTML pages with C?

MIKE: Oh.

TAD: Or did you do any of the cgi-bin kind of stuff?

MIKE: I have done it a little bit with C, and, boy, that's --

TAD: Yeah, I did it, and it was absolutely awful [laughs]. It was the worst. And PHP was a breath of fresh air.

MIKE: Exactly.

TAD: Like, it was, you know, ten times faster to make a webpage with PHP than with C.

MIKE: Absolutely. At least ten times, right?

TAD: Oh, absolutely, yeah.

MIKE: Maybe 100 or [laughs] more, depending on the specification of your page.

TAD: You're like, oh, the string manipulation, ugh [laughs].

MIKE: Yeah, and PHP maybe has a bad, you know, I said I've avoided it. Maybe it has a bad reputation for some of the security issues that it's had in the past. But, you know, I think they've mostly gotten around those. And they've got good modern frameworks, and you can get good work done in PHP. And understanding where it came from, you know, it's served that purpose well. And to your idea about building your own, a year or two ago, we built, as a group, during our Skills Clinic time when we were building our skills, we built some programming languages. And that was fun.

TAD: Yeah, one of the crazy things is we decided...one of our languages we created was basically a text adventure as a language [laughs]. And it's not super useful, right? But it's, like, can I build a language around the idea of text adventures? And the answer is yes.

MIKE: Yes, you can.

TAD: It's weird. It's probably not the most efficient way to code something, you know, grabbing equipment and putting it in your backpack and moving things around into different rooms. And [laughs] I forgot Dave and I had a bunch of plans for it. But it's that kind of thing. There's still novelty out there. There's still new ideas that you can incorporate.

MIKE: And we laugh about that language. You know, in early computing, you spoke computer language. You spoke, you know, machine language. You used to punch a card, and here's the zeros and ones. You know, you'd look things up in the processor and map. And you'd call those instructions directly, you know, you kind of mapped your mental model to those series of instructions. And that only scaled so far.

It wasn't very long before they came up with tools they wrote using machine language to be able to interpret something at a higher level, to take characters that looked more like English and map those to machine instructions. And they built Assembly language [laughs]. And in that many years writing in a language like that, they think, well, what if we could take that to its next level? What if we could take higher-level ideas and map them down to machine instructions? And so, you started getting compiled languages.

And in the last, you know, really for a long time, it didn't take very long to get from compiled languages to interpreted languages. We've talked a lot about Lisp. And there's a lot of interpreted languages, like, we talked about JavaScript, and PHP, and Ruby, and Python that power a lot of the modern world. And it's a higher level of abstraction. But if you think about what happens next, what if you have tools like the large language models that are coming out? ChatGPT being a prominent example.

What if we get to a situation where we're interacting with our computers in a little different way? And you can generate effectively, generate compiled, or interpreted programming languages. Well, what does the interface look like then? It's a lot different, right?

TAD: Yeah. Is it a conversation interface? [laughs]

MIKE: Exactly. But it's still an interface. And the ability to think methodically is going to be a valuable skill that I don't see going away, ever [chuckles], because being able to clearly communicate what you want to happen is valuable, whether you're using your punch cards or whether you're speaking to a conversational interface to build software that layers and layers and layers down. Those layers are just going to keep happening. Those layers are going to keep growing. And being able to think at a higher level, well, maybe I want to think in terms of [laughs] exploration of a text game. That might be really useful.

I remember interacting with those [chuckles] years ago and wishing that their interface was a little more useful. Having a more useful interface that made a lot of sense could be a lot of fun. And maybe it could be a great thing, even embedded in another game. And I think we should be thinking about those and shouldn't be too surprised when we have conversational languages that come up in the near future.

TAD: Well, another thing is, a lot of these languages answer, like, what-if questions, right? You're saying, what if my programming was backed by a large language model? But most of these languages are like, Lua is like, well, what if everything was tables [laughs], right? And Forth is like, what if everything was stacks? Or you got, like, you know, and Haskell is like, what if everything were functional? I'm curious: what are the what-ifs that you think are going to be questions for programming languages in the future?

MIKE: You're thinking about the large language models. There's a grounding problem that's long existed in machine learning, which is you can train something in a simulation, but your simulation doesn't really match reality. And it's really hard to take software that you've trained in a very sterile, controlled environment and make it work properly in the real world, which is messy. I think that a really interesting question is, what if the real world existed? How do you deal with that? And how can we build interfaces that interact with the real world in effective ways without destroying our hardware?

You know, you got a robot or robot defined broadly, you know, I've got a self-driving car, for example. And the self-driving cars today they are these bespoke software. Some of the most effective companies...well, I think all of the companies effectively doing self-driving cars software, there's certainly machine learning that goes in there because they learn to see and interpret their environment. But there's also a lot of heuristics that they have to use [laughs]. You know, where are you on the map? And so, you end up with this really kind of messy model.

And I don't know exactly what this programming language would look like. But thinking about the kinds of problems that we're getting to with some of these large language models, with a higher level interface, we might start thinking about and, you know, other things that have happened in computing that allow us to understand the world in better ways. I think that we're going to maybe think at a higher level of abstraction to say, well, I want to build web pages. What if I could tell a computer to do anything? What would I tell it to do? And what kind of constraints would I run into?

So, you're thinking about stacks. Well, you know, with some of the advances in computing, I might be able to say, "Hey, build me an app that will do such and such," and it can give it to you quickly. So, you have to think at a higher level, well, what kinds of apps do I want to build, right? [laughs] You get into that higher level of thinking, well, what is a business need that I need to solve?

Or, if you think about robotics, what is a real-world situation that I might need to deal with? You know, do I need to deal with a hazardous environment so I can do clean up? Or do I need to deal with sweeping minefields and removing mines after a war? You know, what are some of those constraints? And then we start thinking about, well, what are the real-world problems that I'd run into?

I'm kind of jumping out ahead. But thinking about this idea of having an interface that's more conversational, I think you start thinking about your problem domain more. You know, what if the world is made out of programs that are written for you? I think that you still have problem domains you have to deal with. That was my take.

TAD: One thing that I am curious about is we see so many languages out there with so many different attributes. I wonder if you could create domain-specific languages. You can just say like, "Okay, here is my industry; here's my domain; here's my needs. Generate a language with all the features that would work well in this domain." I mean, I alluded to it a little bit. Like, Fortran is, obviously, very specific to, like, you know, science and mathematics. And COBOL was specific to, like, business needs and things like that.

What if the language itself became a little more abstract? Where you're just saying, like, you generate a language. You give me a language that would be ideal for driving a car, right? And then, give me a standard library for that language for driving a car. And then, I will use that standard library as I develop the software. I mean --

MIKE: That's a fascinating idea.

TAD: Is there a reason why we couldn't get there soon? I don't know if that would be beneficial, but...

MIKE: Well, why not? Every profession has its lingo, right?

TAD: Oh yeah.

MIKE: It's things that they do. You know, why not? If we already have systems that can build software, and a programming language is just a kind of software, I mean, that's something that could be perfected, maybe not perfected, but, you know, but greatly improved. Build me a language that has these attributes for this business domain or even outside of business for this fun domain, right? [chuckles]

TAD: Yeah.

MIKE: I can describe the instructions, you know, build a language that will let my kids interact with their game of choice and do cool things in it. That sounds like a really valuable idea.

TAD: Yeah, I've got several Amazon Echos in my house, right? My daughter is like, "Hey, read me a book. And hey, do these things for me already." I don't even think to do this, but for her, it's part of her world. When she wakes up in the morning, she says, "What time is it? What's the weather today?" Like, those are the first two things she asks, my little eight-year-old kid. She's like, "Oh, cool." And then she picks her clothes based on what the weather is going to be like and whatever.

But what if it was like, hey, help me build controls for the TV or something like that? And give me a language that an eight-year-old could understand that could control some of the appliances in my house. And then, it would just say, like, "Okay, here. [laughs] Here you go." I don't know; that seems possible in the near future.

MIKE: Yeah. Ramses, where do you think the programming languages are going following our thoughts? Do you have anything you'd like to add to that?

RAMSES: Yeah, I think it is interesting, and it seems like there certainly is a kind of a culture shift with how we interface with just technology in general. I'm really interested to see how that sort of [inaudible 38:31] in the next few years

MIKE: Well, and to kind of tie this all together, it will be fascinating to see how it shakes out. But in all of this, we're going to have to interact still, right? We're going to have to interact with these machines if we want to use them. And to do that, you have to learn how to talk to them [chuckles]. It's a learned skill. Regardless of all of the layers that are underneath, there's still a learned skill in getting better at communicating with the machines, which means you have to keep learning. You have to actively seek out and be learning new ways of thinking about the problem and learning those languages.

In my mind, it is pretty definitive. It was maybe going into the conversation, but it's only reinforced my belief that learning languages improves your ability to think about the world and improves your ability to get things done, and that's not going to change. Even as we develop more powerful interfaces, that's still not going to change.

RAMSES: One thing I'm curious about is the cadence in which we might learn a new language. You know, you'd probably learn it just maybe once a year or once every couple of years, depending on how maybe complex a language is or your rate of absorption in the language. But sometimes, it seems like it might be out of necessity. You might work at a place that adopts a new tool, so you have to learn it if you don't already know it.

MIKE: It's interesting because early in my career, career and studies, there was probably a five-year period where I learned between 10 and 20 languages, to some degree, not perfectly all of them. But I remember doing an accounting, and I think it was somewhere between 10 and 20 over five years, which is generously more than one language a year. And I think it was closer to the 20 category. Again, not every language learned well because there was a lot of stuff being thrown at me at the time. I was working on a lot of different things, so I had to learn a lot of different languages. And I think that was really useful. It helped me see a lot of things in a different way.

But then I became more of a specialist, and I think that's a natural progression in a career is you specialize. Even in medicine, for example, you know, there's a lot of generalist learning you do. And then, in the end, you specialize and focus on a particular area. And I think that's a natural progression in software is that you kind of need to specialize if you want to get good at one thing. Because if you're a generalist in everything, you're not going to be as good in all of them.

So, learning a lot when you're starting and then focusing, I think, makes a lot of sense. But then, the cadence afterward, I would still argue that you should probably be...I'm thinking at a cadence of maybe once every few years, you know, between one and five, you should be learning something new because, eventually, that specialization might peter out. There's value in having a specialization, but some of those specializations lose their utility over time.

TAD: I've learned a ton of languages, but I don't know that all of them were useful.

MIKE: Would you say at this stage of your career...you've been doing this for decades.

TAD: Wow. I've probably been a developer for 20 years or so.

MIKE: Yeah. What cadence do you think makes sense for you to be learning now? I mean, would you just learn a new language if you had to switch jobs? Would you argue for continually learning new languages so that you're ready for the next thing?

TAD: Yeah, I think there's probably two different arguments there. Because you probably want to learn things that are relevant for the job market, right? Like, you don't want to be the guy that's still coding COBOL, or maybe you do. I mean, there's still a ton of old systems that still need COBOL programmers and stuff like that. So, there's, like, the financial, like, job thing.

But then there's just, like, the personal betterment, like, personal enrichment aspect to it, and, for me, it's a matter of time and a matter of novelty. Like, if I have the time and if I encounter a language that's different than anything I've seen before, I'd look into it. I'd probably learn it. But I see some new languages, but it pretty much covers all the same things I've seen in languages that I already know. I'm just kind of like, eh.

That's probably the biggest reason why I haven't learned Python is because Ruby kind of scratches that itch for me or fills that niche. It's an object-oriented, interpreted language that's multi-paradigm and has some cool features, right? And so, I'm like, uh, maybe I'd learn Python if I needed to do some data stuff or if I had some need. But I probably won't learn Python just because I wouldn't learn anything radically new from it.

MIKE: Sounds like a good checklist [laughs]. Does it help me learn something new? Does it provide utility?

TAD: Yeah. And so, that's why you probably learn a lot more when you're new and younger than when you're old like us when you're like, I got, like, 20 languages under my belt. 21? Eh, right? Maybe you're a little more discerning.

MIKE: Like we've been talking about, there may be some new things coming in computing that would mean that number 21 is going to be really valuable [laughs]. Well, I'm looking forward to seeing what that language 21 is. I'd like to see a language called 21 [laughs] that meets those needs. There's probably one out there [laughs] I haven't found.

But, you know, this has been a great discussion. I really like some of the thought-provoking questions that we haven't had answers to, recognizing there's a lot out there yet to learn, and that will still be happening in computing. I'm excited. With that, we'll catch you next time on the Acima Development Podcast.