Hey, Ben
Hey Matt How you doing?
Good. Glad to hear it. Well, I've been thinking a lot about the various programming languages that are available to us.
So many!
There are so many, and sometimes I stare at the compiler Explorer, dropdown of languages that the compiler Explorer supports. And I don't even recognize a third of them because people add them in and apparently there's, there are languages like, um, I forgot now. There's things we can even Zed that I've never heard of before Zig cause that's the one I'm thinking of Zig and other things, and there's just, there are so many out there and it made me think, why do we have so many programming languages? And why did we took causes people to choose a particular programming language over another
In the future everyone will have their own programming language, made just for them.
Yes. It feels that way. He feels like, you know, yeah. And in the world of, you know, domain specific languages of some of which are subsets of other languages, you know, we have got a little taste of the everyone's got their own language, but why is that?
I mean, that's a good, that's a good question. I, I was, uh, there was a period of time in my career. I've stopped doing this recently, but there was a period of time where I would try to learn a new programming language every year. Um, and I would always look for things that kind of would stretch the way that I think about problems. Um, you know, you can only use so many, you know, C derivative programming languages, uh, before you start, you know, recognizing the same patterns over and over again, it gets boring.
I mean, that's, that's uh, so that's 0.1 is the programming languages differ more than just syntax. It's not just like, Hey, this thing is a squiggly brackets. This one doesn't, this uses white space. There are some actual, real deep, deep differences in the way you think about programming and how that maps to the primitives that those languages make it, make it easy for you to do.
Absolutely. Absolutely. Yeah. I mean, languages like Lisp and then all the Lisp derivatives are sort of a very different way of thinking about programming. Although you can model a lot of those same ideas and other languages that are not even close to Lisp. Um, and you know, that was one of the reasons that I started doing that is because I would find that I would, uh, be forced to use ideas if I wanted to, you know, be in Rome and do what the Romans do when learning a new language. And then I could take those ideas back to the languages that I was using my day job, uh, in some form or fashion most of the time. And I feel like that maybe trailed off a little bit, the more languages I learned, but, um, the more certainly when I was doing it the early days, it was, it was very, um, inspiring,
Right? And in that way that learning a foreign spoken language or written language opens your mind to a different culture and the ideas that go with it. And there will be the some of those words that obviously the everyone's got a word for dog and cat and things like that. But there may be some subtle things in a spoken language, which you can't convey that don't translate. You have to think about things in a different way, and you get the same in programming languages too, as you said, like Lisp. Um, I remember like one of the first things I did when I moved into the world of trading was pair with a, of somebody who was writing a ton of Clojure. And it was like a massive brain explosion for me because I'm such an imperative, you know, one instruction after another literally kind of a person.
And then to see it done in a Lisp like language was, was mind blowing for me. And at first I disliked it greatly. If I, if it would be much easier to do it, if we just, you know, write a normal program like normal people do, but then I realized, no, there's a lot to learn from this. And as I've, as I've developed as a programmer, I've realized that some of the more core ideas like immutability and things like that have come from languages like Lisp. I mean, honestly they're not unique to Lisp, but that way of thinking of like very, very functional, um, mutability, that lack of mutability, um, pure functions and things like that. Now I use a lot in my day job as a C programmer, right.
I had that same experience doing a project in Haskell, uh, which the project itself did not go great, but, um, just being forced to use that language to do something, and this was actually at my actual real job.
In your real job not just a toy project
Now this was, this was for real. Um, and so being sort of thrown into that environment and forced to learn it was good. It, it sort of made me think about a lot of different ideas that I hadn't been exposed to before. So, um, Yeah. Yeah.
And that's without even going in, I mean, so, so far we've said Haskell and Lisps, which definitely are very different from like your C5 family or, um, I'm trying to think what was the progenitor of C, uh, can't think now. But you know, like the, that suite of families that came together, um, that are very imperative and, you know, you can pretty much read the code line by line and go, this is what's going to happen. And then you've got Lisps which are still have that flavor to them, but then there are other languages which are very much like, and maybe if Haskell falls into this, I'm not as sure about it. But you know, like there's a lot of pattern matching and Haskell I'm aware of. And you know, like if you think it seems like Prolog or even which is in a completely different way of, you know, make a make file is essentially a programming language of a sort, which makes you think about things the other way around.
You're like, how do I achieve this? I don't know. I have rules that match and then rules get me to my destination. And as long as there's a path from what I want and all the, all the transformations that can be applied, then a solution is found and my program runs. And that's a very different way of thinking about it and literally writing the code to do it yourself. You know, so, but you know, when one sits down and you know when you're about, one's going to start a new project. It seems like, I mean, you said it yourself, like the way that you've learned these languages or other languages like myself actually is, you know, you spend a bit of time once a year or every other year or something and go like, Hey, this is the hot new programming language. Why shouldn't I try this out? And you try it and you learn, that's great. Sometimes maybe you can then use that in your day job. But when you're sitting down to say, like write a little program at work, how do you make a choice about which language to pick? What are the criteria, you know, w what do you think of when you're sitting down to write something? Yeah.
Yeah. That's, that's, um, that can be a hugely impactful decision for any company, uh, getting that wrong can be, can be very, very painful. Um, the main thing that I think about is the community behind the language, and there isn't always a true sort of singular community, you know, languages have tighter knit communities, and some of them have much broader committees, uh, that govern them. And, and, and, and, you know, it's sort of, you can run the gamut just like you can with, with language features and other things with like, what is, what, who are the people behind this language. Um, but I think that one of the most important things to look at beyond syntax, beyond standard libraries, um, beyond even the user library community behind it is, um, the, the community behind the, the language itself. And who's sort of driving it forward because whatever they value you will be forced to value, right? If they value, uh, strict algebraic types, you will be forced to value strict algebraic types. If they value testing, you'll be forced to value testing and so on and so on. And so on,
Like, what do you pick a framework? You know, if you find yourself not fitting in with the thought processes of that framework, you find you're going to be swimming upstream the whole time, even more so with the language is like, well, I want to do, you know, I've picked a language which is a functional, and I'm trying to do imperative style programming. You know, you're not going to get very far. Right. You've made your life harder for no good reason.
Yep. Yep. And, and, and as the languages, as the language evolves, and some languages evolve faster than others, but as the language evolves, it will tend to evolve in a direction that meets the values of that community. Right. So, you know, you can sort of look to the future a little bit to see, like, okay, what are the new features of this language going to be, well, let me go see, you know, who are the people that are very active in this? What do they value? You know, look at the conferences, look at the talks, look at the papers that are written, um, and try to figure out like, you know, what, what is important to them, right? Not necessarily what's in the language today, but like, what do they think is what are the, what are the values?
Yeah. The drive, so that you're taking a very long-term view there, which is commendable, right. Especially as I gave you the question of like, hey if you feel sitting down at work.
Right. Exactly.
You'd be doing so that's, that's obviously couched in that kind of, um, uh, the background that shouldn't necessarily apply. If you were writing your own project, if you're just going to sit down and write, like bang out a command line tool, right. I mean, this is a perfect example of something that you would then use to learn a language like every year or so, as you, as you say, and of course that takes time and spare time and not everyone has the time to spend learning a whole other language. So we should definitely, um, note that, but it is a fun thing to do, but then do you have an instinct as to what, like, what would be the next language you learned? I've got my answer. What would be the next language you would sit down and write something out. And if you were to start from scratch apropos of nothing for yourself,
I'm assuming. So I would, for, for those kinds of projects, I would definitely lean more toward like, what are the libraries available to me and what can I get done quickly if I'm learning a language, just to learn something new, I would actually go back to a language that I had already tried to learn and sort of used a decent amount already, which is Rust. Um, I think Rust has come along a bit since I've used it last. And I think that it is a very interesting language and I would want to use it again. Um, I don't have a project in mind that Rust would be a good fit for right now. There was a period of time where I was following a guy on Twitter that was really heavily involved in, um, embedded Rust.
Uh, oh, interesting. Yeah.
I want to say his name was Julian something, but I don't, I don't remember. But anyway, it was, that was, I was kind of like trying to figure out like, you know, could I use Rust, um, for embedded programming because, you know, as we talked about with, uh, James and one of our very, very early episodes, sometimes, uh, testing for embedded systems can be kind of tricky. And I wondered if the type system in Rust would help, um, remove the need for some of the testing that I would be normally inclined to do. And you just sort of rely on the compiler and the type system to sort of solve those problems for me.
That's definitely. So, yeah, I would also pick Rust as the next language. I would sit down and learn, and I've, again, I've touched it probably six, seven years ago last, um, and I'd be interested to see how it goes, but for different reasons, because I want a language which is performant, but also has all the things you just talked about, you know, static typing, very strong typing. And I think that's, that is also another sort of axis that one can slice languages down. We talked about, you know, like Lisps and Haskell and Prolog and C like languages. Um, there are various different shapes of different parts of the, on the, on the multidimensional space of languages, but some of the big axes are compiled versus interpreted. We haven't yet talked about, um, statically typed versus dynamically typed, which sometimes goes hand in hand with that compiled versus interpreted.
Um, and you know, then how, how statically typed you are, right. You know, in terms of, can you have full algebraic data types and things like that. And, um, it is definitely like my, I spend most of my time these days writing C++. And, um, it's not as strongly typed to save Rust in terms of the things that Rust is tracking in it's type system, which is why I'm interested in seeing, you know, Hey, what would be, what would C++ look like if I could encode this information and the compiler can check it for me so that I just know is correct by construction, right? If these things, if it compiles, then I haven't got any memory errors. That's really exciting to me. But then I spend most of my non-work time writing in JavaScript or Python, both of which are very, very much on the other end of things.
And it's a really interesting trade-off because there's no question if you're going to write a little tool, that's just, you know, uh, you know, little of shell script replacement tool, I'm going to reach for Python every time because I can just get stuff done really, really quickly with it. And I don't need the rigor of the type systems, but, um, and in fact that would, that's probably not, um, uh, it wouldn't matter if it broke anyway, I would get there and I'll be like, that's fine. That's okay. I'll have to rename a couple of files at the end of whatever I was trying to achieve. And so there's definitely that sort of axis as well, where, you know, like banging something out quickly. I hear good things about Go in that respect because Go, Go has another third, fourth axis. However many axes we're talking about now is how easy is it to deploy the result of what you've done? And that's, that's I think Go brought that to the foreground for me, when you start to see all the Hashicorp toys. Toys? They're not toys. Tools coming out.
Some people think they're toys.
All the HashiCorp stuff, and it was all written in Go, and you got used to the idea of you download a binary and you chmod it. And you run it. And that is the application. It's like, whoa, my mind's been blown. Where's the installer. Oh, there's no installer it's just a well made binary.
It's just a binary. Yeah. Yeah. Whoa. Yeah. Yeah. And Go is a language that I actually intentionally wouldn't put on a list of things to go and like, learn on my own because I'm expecting any day now that I'm just going to need it in my day job. And I was like, oh, okay. I'll learn it then. Right. Like it's and you know, maybe
You'll, you'll learn that on the company's dime as opposed to your own.
I mean, you know, maybe I should warm up that cache a little bit, but I Go, doesn't also strike me as a language that's particularly difficult to learn one person, um, that I know that has written a fair amount of Go, uh, told me once that the way that you increase your productivity in Go is you type faster, there's no, there's not a lot of like magic tricks
The keyboard level of typing, not the...type system typing
Not type system typing.
And then you type the literal word faster.
Right. Um, but yeah, it doesn't strike me as a language that's particularly difficult to learn. I think any language, you know, it's, it's, there's always going to be a learning curve with the standard library and the library community and stuff like that. Um,
Sort of the ethos behind it and the way that that is driven, like might not be against your, you know, your personal, like slices I know are a big thing in Go, and I always stare at them and go what, but, uh, yeah, right, fine. There's definitely that thing. And you've, once you, once that penny drops, you can usually make a lot of progress. Yeah. Sorry. I cut you off. You were saying something far more interesting.
Oh, just that, um, it, it, it doesn't seem like the, the learning curve of Go is mostly in the language. I would expect it to be mostly in the libraries and that's the kind of thing that's going to be, uh, domain specific anyway. Right? Like it's, it's not like I'm going to go and survey the entire world of Go libraries and predict which one I'm going to need at my job to be able to do X and Y and Z, that I don't even know what it is yet. Right. Whereas another language like Haskell falls in his category Rust would fall in this category, the language itself, and the environment itself has a lot of complexity to it. And independent of any particular problem that you would want to solve with it from, you know, a half mile away sort of staring at it. I think, you know, there might be a lot of complexity there that just is just to get the hello world, you know, or to do any, any sort of non-trivial problem, no matter what it is.
Yeah. Yeah. That makes sense. I mean, yeah. Again, things like Haskell, I know, you know, there's things that involve monads and things that nobody can explain or understand, and I don't.
It's like a burrito.
stop
Except a burrito. You can't explain to anyone else without invoking other words, an endofunctor in the category of monoids or something is what their definition of that's. Thank you. Now there's three more words I need to go and look up, but yeah. So some of those things do definitely fundamentally change the way you think about stuff. And so I'm talking of something and maybe this isn't a Haskell thing, particularly, but in some of the other languages, we've talked about the idea of currying functions and partially applying functions and passing functions as first class things. That's that to me is like that, that functional thing that has really changed the way you think about problem solving, because you're like, Hey, I can do that. That I can compose these apparently arbitrary, distinct things and put them together in a way that can make some new thing without either of them having to change all that solid open closed stuff. You know, when the, when the function is itself is something that you can manipulate and apply things to and make a new function in the language itself. That's a powerful construct, but it does require a lot of thinking, especially for, uh, an old assembly programmer, like me, I'm really used to that kind of kind of ability to change things, but yeah.
Yeah. But I mean, you know, the crazy thing about that, and I think a reason why it's cool to learn new languages is like, you can do that in JavaScript too. Right? So like, you know, talk about something you use for your day job. It's like, you know, you start thinking of designing programs that way cause you have to, and then you start seeing places where you can, and then it's a question of whether you should, but, but at least, you know, that you can. Right.
Right. Yeah. Yeah. So these things are applicable to most, but I would not, I don't think out of the gate, I would have ever considered writing. I mean, I guess newer JavaScript would make some lambdas easier to write, but you know, writing currying and composing other functions seems a little bit harder. I mean, although I think I've done some fairly disgusting things with it and eval and strings that on the way, I think we will have crimes crimes against the, uh, the interpreter.
Yeah. Yeah. I question that I would love to get your take on is that there's obviously a whole bunch of different forces that feed into language popularity. What do you think it is that makes languages popular?
Yeah, that was that. That's a really difficult question. Um, I mean, solving a need. And so actually I was listening to another podcast the other day, uh, the ADSP podcast, which is algorithms plus data structures equals programs. Um, we'll try and remember to put the link somewhere in our, uh, our, uh, transcripts, but, um, in that they were talking about this and saying, this seems to be like sweet spots where certain languages that had very specific domains have been very popular in that domain. And by catering to a particular domain, they become successful and have had the longevity. And so they were talking about things like, Erlang, which he knows another whole different way. You know, it's, it's a huge in the telecoms industry because it solves a very real need that they have for certain full tolerance. Um, and then one of the things that's brought up is what about Python? You know, the data science community has basically adopted Python as the, as, as the, uh, I'm going to hate mail from people who want us to talk about, R, but Python is the defacto in my mind solution. But the thing is Python a general purpose language, it just happens to have a couple of really popular libraries, numpy and pandas that do a whole bunch of useful things. It's almost like a sub community that have grabbed onto that more so than people using it more generally.
I don't think Guido had scientific computing in mind when he made the language. Yeah.
No, that's a kind of accident of how it turned out. Yeah. And then, you know, things like, C, I think a very, they were, they, they found a sweet spot above assembly code and below anything too complicated so that, you know, he got a foothold in the early days of Unix machines and we became like the, essentially the way you talk to the computer in a reasonable way. So maybe that was it now C++ on the other hand, I don't know why it's been so successful. Everyone complains about it, but Barne is on record as saying there are two types of programming languages, the ones people complain about and the ones that people don't use. And I think that's a fairly good and reasonable thing to say. So, yes.
Well, we were talking about this the other day, I think is maybe a kind of an interview question when you're talking to somebody that says that they're an expert in one language or another, and it's like, oh, okay, well give me the top five things you hate about it. Right. Because if you don't, if you can't list that, then you haven't been using it for long enough to really call yourself an expert.
Wow. That's a good question. Uh, well, it's a, it's a question. I don't know what I would say about that. I mean, if you ask me what are the five things I hate about C++, I'll be like only five and it would, I wouldn't have enough time to winnow it down, but yeah, yeah, no, that's an interesting one. So yeah. In terms of longevity, I don't know. I mean, one language, I'm just thinking out loud here, which is what I was thinking of, like, you know, languages that have been successful and still doing well now, Java, we haven't spoken about that at all. And that's a very interesting one that sort of perceived to be very enterprisey. Certainly it was it's sort of first forte, although my understanding is it was originally so that like small ish embedded devices could like, you know, toaster, you know, Java on your toaster and then you'd have to retarget it for some other, you know,
One of the, one of my first side projects out of school was building J2ME Java two mobile edition, apps for a Nokia stick phone.
I'm well aware.
Uh, and the, and that was, that was a fun little project right there. Did you ever do anything like that with J2ME?
I did. Oh, my golly. J2ME. Yeah. I, the, the original OG YouTube app was a J2ME for some of the devices that only supported it. And that was, you can imagine the perfect confluence of not really Java, also not really powerful CPU and certainly not very standardized MJPEG decoding hardware, and, you know, that's a holy Trinity of pain and suffering. And so, yeah, you'd be like, I got to work, except that the red is green and the green is blue. And I can't change that because it's just the one and only thing I can do. So maybe we should just, transcode all of the, all of the videos on YouTube and switch red and green around.
Yeah. And somehow that turned into, uh, enterprise serverlet something, something, something, something, something,
Right. I mean, we, yeah, we, we all their favorite way of taking the Mickey out of a language, but Java is one is that you put get factory setter interface something something which is not strictly fair. And especially, you know, I like to point out to a lot of people, especially from the, let's say the C++ community who like to hate on that kind of thing, or like hate is too strong, but like take the Mickey out of is that unlike our compilers in C++ world, although Java is compiled, it is also JIT compiled as a second time. So like, we know that it works, we've got bytecode and then we're like, Hey, you know, all those layers of software indirection, you know, in the factory, you getter and all that kind of stuff, Hey, we compiled that out dynamically at run time. We were able to determine that none of these things mattered and it's just like, get 12 C++ can't do that yet. So we shouldn't be, you know, to, to writing off of.
Yeah. The JVM is one of the most amazing pieces of technology ever. It just, I, and you know, I've used, I use Java a lot. I used a lot of Clojure, a lot of use, a lot of other JVM languages.
Of course. I've forgotten that Clojure actually backed on to Java
And underneath the covers, it's all the same thing. And the cool part about that is it, you know, if you spent, you know, a good chunk of your career, uh, understanding how the Java garbage collector works, that translates pretty well. And to pretty much any other J2ME language, like, you know, you pull up, use the same set of tools,
Not J2ME hopefully.
What did I say? J2ME.
You said J2ME again, I'm like gosh, it's stuck in your head.
Oh, JVM!, Uh, post traumatic stress disorder from the early days? Uh, no. Yeah. You know, use the same set of tools, the same sort of foundational principles of like what kind of problems you run into and how you troubleshoot and what you're looking for. Are there, obviously the ways that you deal with them might vary from language to language, but, um, but it's kind of a cool ecosystem to live in really.
Yeah. Yeah. There's a lot of fungible knowledge, which is a good thing to have. Right.
Yeah. Plus being able to reuse the libraries across them all is an amazing thing. Right. Like, you
Know, some interoperability
Stories. Right, right. It's like, oh, I only, if we had an amazing text processing library, oh, you have. Lucene. It's been here for 15 years. You can use it in any of these languages. That's great. Yeah. So whatever it is, it's kind of cool.
And of course it also spawned, um, the, the Android apps are all Java through some crazy transcode-y, something, something Dalvik something, something lawsuit. I don't really understand how that ended up, but, you know, that was the thing at the time. So obviously that was seen as being like the best, a good solution for it. And so it's done very well. And C#, while we're here talking about languages that broadly, I see it so much for any kind of plan that we had about this. And as much as we ever have plans for these chats, but we're meandering all over the place and hopefully our listeners
Well just like programming languages do right.
Well, that's true. But C# I really enjoyed working in C#. In fact, um, I rediscovered, uh, some C# code I'd written a long, long time ago for a, for a game for X-Box. What was it called? There was some kind of like community driven X-Box thing you could make games for your X-Box way back when it was an experiment that Microsoft canned fairly soon after, unfortunately. But, but that was, that was pretty great. It wasn't perfect. Um, something, something garbage collector couldn't do anything with it, but that's, that's more to do with the runtime than it was the language. I really liked the language. And one thing that it had over Java, which I think has been rectified now, although I'm sure someone will tell us if it's not the case, but is it like allowed you to have actual value types? Like structure types, their values, like, Hey, this is an X and a Y and I want you to pass it around as a copy of the X and the Y, which had just four bites each, as opposed to, everything's an object where Java, Java will hand you that. Yeah, sure. You want a new one of those? Here's a new one of those. And like, no, no, no. Don't put it on the heap and give me a pointed to it. I don't reference like semantics. That's actually not performant. And also it doesn't have the semantics that I want. So maybe there's another axis of our, of our world is, you know, value types or value or the ability to have value types or references.
I mean, all of these things are just kind of like language features, like as much as we think of typing as this like really definitional thing, it's kind of just like a language feature. Now. It is a pretty significant one. But, um, at the end of the day, you know, any of these, any of these things just comes down to the way the languages are designed. I, I may have mentioned this before, but I do have this theory that a lot of problems that get held up as really important problems actually just come from language design. Because when you think about like, oh, what should we put in the standard library? It's like, well, I have these problems as the designer of the language. So maybe other people do, I'll put them in there too. Um, and like, you know, sometimes those are problems that other people have, but a lot of that's a lot of times I feel like things kind of sneak into the language itself or sneak into the standard library or the things that are much more narrow in scope than the people who create them think they are.
I mean, to some extent, sometimes the syntax of, you know, if we're going to get to the sort of like the nuts and bolts of languages, like the actual things you type can force you to in one way or another. So, you know, for the longest time in JavaScript, you could write anonymous functions and then you could pass them as callbacks and everything and whatever. And it was a pain because you'd write function open paren close paren and then, you know, the Lambda syntax came along and it's exactly the same thing. But now I don't think twice about writing a little Lambda that lives inside something, and we pass it in the things that are easy to do. I mean, we all know how lazy programmers are, which is a good thing, right? Like if we haven't already said to the three
One of the three virtues from Larry Wall
Yeah. Right. There you go. It's the
Laziness, laziness hubris and I don't know memory probably.
Right. Um, but yeah. Um, the, yeah, the syntax, if something's easy to type and it's everywhere, then you will use it more. I mean, it goes without saying really in C++ similarly for the longest time, you could define that all static functions and then pass them into other functions as like the address of the other function over there. But the, when they came up with the Lambda syntax for that, that was, you know, I opened it suddenly. You're like, Hey, I want to make a callback. Oh, I can just give you a call back and make it in line. And suddenly that opens the door. And now you're thinking this design doesn't suck now because it's easy to do. I'm handing people, things that don't feel like it's difficult now because it's C++ there's a hundred reasons why it's pretty difficult to do that well, but, um, I wonder what else falls into that category?
Um, I know that, um, again from ADSP that was listening to APL, which is like a very old programming language, um, has, uh, uses symbols exclusively for all of the things. And then like, you know, there's thousands of different ways you can have infix and outfix operators and stuff. And that means that you can have a very rich if terse language that sort of combines things together in a way that, like, I don't think I would necessarily like, but maybe, maybe that I'm missing something here. I mean, there was, uh, things like, you know, having the, the pictograms that mean different things, or actually, um, help you understand what the algorithm does better than maybe the, the name does, it's like a pictoral representative, like rotation or, um, you know, extraction, you know, so like, um, you know, in pandas you do, what is the thing that you call you, you should, um, stacking and unstacking, and they're like these little things that mean that. And I'm like, oh, I think I could see that. So that's another thing. And again, without wishing to completely sideline us, well, that's what this podcast is like everyone's podcast, um, in, in human language, there's a theory called the Sapir-Warf hypothesis. I don't know if you've ever heard of this.
Yeah, yeah, yeah.
Uh, my, my memory of this is that your, um, the way that you think the way that you think about the world is limited by your language, right? So if you don't have words in the language that you speak, then you have a much more difficult time thinking about concepts that don't fit that language.
Right. And I think to an extent that my understanding, and again, we're armchair folks just discussing things you remember from reading a book sometime, but the, certainly the first language that you learned, like your mother tongue fundamentally changes the way that you think about the world is what that hypothesis was, which is a very difficult hypothesis to test. Um, and, um, because you're like, oh, um, but you know, there are languages. Um, so some of the sort of theories behind the languages that are languages for which there are essentially tenses on words that describe whether or not you know this is fact, whether you heard it from someone or it is generally known. So if you imagine every time I talk to you, there's a different ending on the word. If I absolutely it happened to me and I'm telling you it's truth, or a friend of mine told me, or they say, you know, you can't help, but feel that that would fundamentally change the way you process information.
If you are essentially in your own head, having to tag all information as being from one of these three categories.
That sounds super useful, actually.
Doesn't it? I mean, especially in today's misinformation soup that we live in, but.
I would love to have that.
So it seems plausible, right? And certainly the hypothesis seems plausible. Um, and I wonder if the same is true or a sort of a more generalized version of it is true about programming languages too, I mean to the extent that we just said, Hey, learn a new programming language. And it expands your mind then you'll think of new concepts that you can apply back into it. Obviously that's us trying to take our intuitive, understanding that that's true and reversing and go, well, how can I make my, how can I become better as a programmer? I know I'll take advantage of this and I learn another language and I'll expand my mind. But I wonder if the actual root thing is also true, you know, like the fact that the first thing you learn shapes the way you think about computers, because while it's not the exact first thing I learned, the very second thing I learned very shortly off, the first thing was 6502, or z80 assembly. And now I think of everything through the lens of an 8-bit computer and I can't help, but feel that, that still happens to me at some level.
It seems like that, you know, and obviously the folks who are coming in now who haven't been exposed to, that kind of stuff are coming in at a different level. Maybe they, their first language was Java, right. And a lot of people that were graduating certainly 10 years ago when I was actively involved in recruitment more where they were Java, they were like, th their universities were only teaching Java. And that taught them to think about the world a certain way. That's not bad or otherwise it's just different. And, um, yeah, I, I wonder what people learn these days, um, whether it's still Java or whether, you know, and I know that, you know, some, some universities do target C++,
Yeah, there are still some.
Specifically targeted those, but I wonder what else there is, is Rust being taught anywhere or any of these languages being taught well, which is the other thing, right?
I have spent my last week doing nothing but reading resumes because it's August and it's, you know, campus recruiting time. And most of the things that I see are Java or C++ there's some Python.
Interesting.
Um, and what I have seen, I think a lot is, is it's not one language for the entire degree, right. You'll have classes that are taught in particular. And that was true when I was in school too. Right. Like, you know, um, the selection of languages is a little smaller, but like, you know, most of my core programming classes were in C++, but, you know, we had, um, we had classes that were in COBOL. We had classes that were in, um, uh, it was at least one class. It was still in Pascal, even though they had switched over to the core program to C++
But, COBOL?
Yeah. The databases class was in, was in COBOL.
Tell me how old you are without telling me how old you are.
Yeah, no, that's true. But yeah, I think that's definitely thing. And you know, there's also, there's also a kind of an interesting intersection of these two points, which is that almost all, maybe all, I actually don't know, um, programming languages, the keywords are in English. And so if you're a native English speaker, you have a particular meaning in your head for those words that, you know, maybe is close to what their intention is in the language itself. But if you're not a native speaker, then this is just a word, right? Like you, you have your own concept of that. That's maybe separate from the language, right?
Yeah. That's a very good point. Um, definitely the case that most, most languages, if not all languages, that I'm certainly all language I'm aware of most programming languages that I've heard of. And again, I've heard folks discuss about various programming languages, but this question I've said, no, they all end up being mostly Anglocentric of some description, which is initially, and that, that was actually where the, and then the APL being all symbol based was an interesting counterpoint. So yeah, maybe, maybe the, the names, I mean, naming is that we could do a whole other episode on naming, probably do a whole podcast on naming because naming is really difficult, really, really difficult. And, but getting it right is so satisfying, right. That's like, what do you, when you find that word and you're like, yeah, this is, this is what I mean. So let me give you an example.
I'm going to tangent on the tangent on the tangent. So we're probably back where we started, or one more, one more tangent and we're back where we started, I think, um, we, we would try to deal with a piece of code that had sort of two timelines. There was the wall clock time of the computer itself. And then there was a time that essentially simulation time. And we were very excited that we found the word juncture to. And we gave it the meaning of, that's the simulation time, right at this juncture, we were doing this thing right. It's a very posh sort of... Barking right here in the background. It's a very, um, uh, sort of posh way of saying time, but we, so we gave it new meaning. So I guess that sounds like not a great thing, but it was something we all understood was like, if you see a juncture time, then that is not a wall clock time.
That is a time that you think that sometimes they coincide. But more often not. And it was, yeah, it was an interesting thing. And then go back to typing, you know, making your juncture type, essentially it's still a 64 bit number. That's how many nanoseconds since 1970 or whatever, but having a very different static type from the wall clock time type, you could never mix them up. And that's a super important thing in, I don't know, trading systems, just picking a random example out of my, my, uh, posterior. So, so, um, yeah, I know we didn't ask about why one might want one versus the other, but that was that there we are. So, yeah.
And it's, it's funny how different different languages will inform the way that you pick names, uh, in different ways. And like, you know, a lot of times it's the community behind the languages that is doing that. Obviously, as we already talked about earlier, the pattern in Java for a very long time has generally been to be extremely verbose and throw all of the whole like soup of nouns into the names of your classes and functions. Um, and I think that was maybe a reaction to some of the earlier stuff where you would have variable names like C and R and C underscore R uh,
Because it goes faster when you use shorter names, because computers don't have to look up as many characters,
Right. The compiler goes so much faster when you, when you do it that way.
Yeah. That's why should use tabs and not spaces as well to indent, because it's fewer...fewer bytes to get through
Fewer bytes to get through the parser. Right? Yeah. Um, so yeah, I it's, it's all this, all this, it's amazing. All of the different effects that all of these things have. I'm probably sure that most of them were not intentional, but they...some of them were
Yeah. Some things are sat down intentionally and said, no, this is how we're going to do things. You know, like all the getters and setters in Java are almost like forced to be that because of sort of like things like Java,
Java beans
Sort of said that. And, you know, that's, that's a, um, that's a powerful thing for, to say, okay, that's how we're just going to set and retrieve things and now tooling can come in and use that to its advantage. So there's definitely something to be said for that, but yeah. Do, do you need to put, get in front of things? I don't think you necessarily do maybe, maybe setting, sorry. My dog is making all the noise again to the background we've done so well recently with noise from dog. Um, but he's discovered plastic. Uh, his favorite toy in the world is a plastic bucket such as a child would to make sand castles with, and he has chewed that to death. And now he's knocking it around in the background. So apologies for the background noise.
So I guess where does that leave us? Um, what w what, what choices does one make? So I personally, I do like the, usually the performance of languages is important to me, unless it's a script thing like I discussed. And, and to be honest, actually, if you're going to write something in JavaScript, it's amazing how fast things can go in JavaScript these days. So that's an impressive, impressive achievement there. And you've got TypeScript, which kind of can give you a certain amount of types on top of JavaScript. So you can kind of recover some of the other things that I like, which is as much as possible, make it so that if I've got bad code that won't work, the compiler tells me before I have to run my tests, even. So that's, that's my own choice there. And obviously there's, there's a huge continuum between a fully dynamic and test all the things and fully static check all the things. And, you know, you don't need to write tests because your code, if it compiles, it works, you know, that's a nice property to have. Right,
Right, right. Yeah. No, I, I, I definitely fall very much on a spectrum when it comes to those kinds of things. The main thing for me is just making sure that it's easy to get, to get to a point where I'm confident that my code works and I'm perfectly happy to write fast, focused unit tests to get there. Uh, I'm happy to let the type system do, if it'll do it. The thing that drives me nuts is when the type system tells me that I need to do a thing that doesn't actually give me any confidence and I have to write the test anyway, and then the tests are hard because the type system gets in the way.
Um, are you referring to Python for example, and this is sort of not,
I'm not referring to any particular language. I have felt that pain in many, many, many different languages. Um, and yeah,
I know recently we've been, some of the stuff that we've seen at work is Python, and, you know, there's people like me who are like, I really, really, really wish Python was statically typed. So I'm going to put every single type hint known to mankind everywhere and try and try and pretend like that's actually doing anything for those who don't know Python very well. It is literally a hint. It's possible to like read the hints off nothing. It's a comment, but in principle, it's a comment that can be checked by a checker, but for various reasons, we're not checking as much as we ought to be checking. So we're not getting the benefit of it being all nicely typed. Um, so you've kind of got the worst of all worlds. You've got IDs that are giving you red squigglies because you type hinted it and someone else's passing in something, which is basically the same, but not the actual same type.
And you know, it kind of, you squint, and it comes out in the wash. It's like, yeah, it's fine. It's got to getter and a setter. That's all I needed. It doesn't derive from get settable or whatever you've decided your type is called. And you're like AH! Which actually comes back to Go. And my grief, sorry, we should definitely stop soon because I'm just going all over the place here. But the thing I found interesting about Go is that it has structural typing rather than nominative typing. I think I'm getting that the right way round. So you can say, um, my class needs to be passed something which has this interface and the interface is, you know, set foo and get foo. Those are my two things that, that interfaces. And at no point do you need to, in your thing that implements that say that that's what you're doing.
As long as you have those two functions get foo and set foo, then you, you honor the contract of a foo settable.
Interesting.
And that's interesting if you have to me, that's really interesting because it allows you to post hoc layer on interfaces where none existed before. Like I can take someone else's code and you sort of, again, open-closed principle say, Hey, look, you've got this thing. I now can retrospectively put an interface over you. As long as that interface that has your, as long as you implement the methods that are in your interface. And now I can pass you around as this interface to other people without having to shim anything myself, right? Because you implicitly, oh, one of these.
So you don't, you're not declaring something. It's just looking at the usage of it from within like the function and saying like, oh, this variable must have these...methods on it?
What it's doing is when you pass an object as, um, like a concrete type as an interface, it just looks at the methods that you have in your, in your, um, objects, in your concrete class and compares them to the interface. And if they match, it's like, great, that's cool.
Oh, I get it. Yeah, yeah, yeah. So there's no, there's no inheritance mixed up in that.
Exactly. Right. Yeah. And there's no implements that you have to write, which is to say that you can layer them on afterwards, which is cool. But I don't like it. I don't like it. Cause I think it should be very intentional if you are choosing I'm an implementer of a class and I am choosing to be Loggable because I have a log method and my log method does a logging. Right. Does right. And now if someone comes on and right, and this is extremely, I'm just being silly to prove a point. What if you now have math Loggable, which means, you know, like, Hey, this is the logarithm, the natural logarithm of a number. Hey, I can pass in my logger into my fricking log. You know, my math function because it implements log. And you're like, I mean, obviously that's just the name and obviously the parameters would be different, whatever, but like, there's a very big difference between that. And I had a much better example at one stage where, you know, like the intention of something is very different depending on what the interface is, as opposed to the name of the methods and methods are ambiguous without the context of, well, is this, you know, what, what is this doing here? You know, is this, uh, yeah. I, I, yeah, if I had it at the top of my tongue, now I would tell it and now I just sound silly, but nevermind. When has that ever stopped us? Thankfully, never.
Never before, never have we stopped once before.
Well, this is obviously a gigantic topic and I know we've got some cursory notes and we've barely scratched any of these things. Um, but we could definitely go over some other things and other time I'd be interested in knowing what our listener thinks of various languages and what, what makes, uh, what goes into the choices of folks use for both the home projects such if they have them or, you know, like little throwaway projects versus like big, this is going to be supported for two or three years in a company kind of context, whether there's something we're missing because, um, I'd love to hear. So, you know, tweet at us.
Absolutely. Yeah. This is, this has been a good talk. I think this is a good place to stop. I'm a little disappointed that we didn't get to talk about the most popular programming, the most proper language that's used in programming through.
Oh?
Profanity.
Oh, profanity. Right when I was close to there. Yeah. Yeah. It's always fun to get grep and find out how many times someone has checked something in. Right. Well until next time, my friend.
Until next time.