Two's Complement - The Language Menagerie

Episode Date: November 1, 2021

Ben and Matt explore the world of programming languages. So many! Why are there so many? Wait, there's a Java Mobile Edition? Who would use such a thing? The hosts of the #1 top ranked programming podcast that my mom listens to, that's who.

I'm Matt Godbolt. And I'm Ben Rady. And this is Two's Compliment, a programming podcast. Hey, Ben. Hey, Matt. How are 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 are languages like um i forgot now there's things beginning with zed that i've never heard of before zig 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 do we why do what causes people to choose a particular programming language over another in the future everyone will have their own programming language made it feels that way yes it feels that way it 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. Right. 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's boring

i guess i mean that's that's a so that's like point one is the programming languages differ more in just syntax it's not just like hey this thing uses squiggly brackets this one doesn't this is white space there are some actual deep, deep differences in the way you think about programming and how that maps to the primitives of those languages make it easy for you to do. Absolutely. Absolutely. Yeah, I mean, languages like Lisp and 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 in other languages that are not even

close to Lisp. And, you know, that was one of the reasons that I started doing that is because I would find that I would 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. Right. 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 in the early days it

was it was very um inspiring right in that way that learning a foreign spoken language or written language yeah opens your mind to a different culture and the ideas that go with it. And there will be some of those words that, you know, obviously 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. They 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 uh when i moved into the world of trading was pair with uh of

somebody who was writing a time of closure and it was like a massive brain explosion for me because i'm like i'm such an imperative you know one instruction after another literally kind of a person and then to see it done in uh a lisp like language was was mind-blowing for me. And at first, I disliked it greatly. It's like, well, 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 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, obviously, 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 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, right? Yeah. Not just a toy project. No, this was for real. And so being sort of thrown into that environment and forced to learn it was good.

It sort of made me think about a lot of different ideas 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 c c family or um i don't even think what was the progenitor of c uh beginning with a i can't think now but you know like the that 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 lists 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 not as sure about it but you know like there's a lot of pattern matching in haskell i'm aware of

yeah and you know like if you think of things like prologue 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. Or that's a very different way of thinking about it than literally writing the code to do it yourself. So, but when one sits down and we'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 spend a bit of time once a year or every other year or something you 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 criterion you know what do you think of when you're sitting down to write something? Yeah, yeah. That can be a hugely impactful decision for any company. Getting that wrong can be very, very painful. The main thing that I think about is the community behind the language. And there isn't always a true sort of singular community. Some languages have tighter-knit communities, and some of them have much broader committees that govern them.

And you can run the gamut just like you can with language teachers and other things of like, who are the people behind this language? But I think that one of the most important things to look at beyond syntax, beyond standard libraries, beyond even the user library community behind it is the community behind the language itself and who's sort of driving it forward. Because whatever they value 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 will be forced to value testing and so on and so on and so on this is like when 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 a language it's like well i want to do you know i've picked a language which is uh functional and i'm trying to do imperative style programming you're not going to get very far right you've made your life harder for no good reason so yep yep and and and as the language is as the language evolves and some languages evolve faster than others but as the language evolves it 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, and try to figure out, like, you know, what is important to them, right?

Not necessarily what's in the language today, but, like, what do they think is important? What are the values of the drive? So 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're sitting down at work, what should you be doing?

So that's obviously couched in that kind of background. That shouldn't necessarily apply if you're 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 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 note that. But it is a fun thing to do. But then do you have an instinct as to what would be the next language you learn? 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? Assuming, so I would, 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. 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. 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 embedded Rust. Oh, interesting. Yeah, yeah. I want to say his name was Julian something, but I don't

remember. But anyway, I was kind of trying to figure out could I use Rust for embedded programming because as we talked about with James in one of our very, very early episodes, sometimes testing for embedded systems can be kind of tricky.

And I wondered if the type system in Rust would help remove the need for some of the testing that I would be normally inclined to do and just sort of rely on the compiler and the type system to sort of solve those problems for me. That's definitely so yeah the i would also pick rusters like 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 typing. And I think that is also another sort of axis that one can slice languages down. We talked about, you know, like Liszt and Haskell and Prologue and C-like languages. They're all various different shapes of different parts on the multidimensional space of languages. But some of the big axes are compiled versus interpreted,

which 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 it's not as strongly typed as, say, Rust in terms of the things that Rust is tracking in its type system, which is why I'm interested in seeing,

you know, hey, what would C++ look like if I could encode this information and the compiler can check it for me so that I just know it's 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.

Right. 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 a little 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. And in fact, that's probably not...

It wouldn't matter if it broke anyway. I would get an error and I'd 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. And I hear good things about Go in that respect because Go has another sort of 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? Yeah, yeah, yeah.

And that's, I think, Go brought that to the foreground for me when you start to see all the HashiCorp toys, they're not toys, tools coming out. Some people think they're toys. Yeah, 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 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 4MAKE binary.

It's just a binary, yeah. Whoa. Yeah, and Go is a language that I actually intentionally wouldn't put on a list of things to go and 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'm like, oh, okay, I'll learn it then, right?

You'll learn that on the company's die as opposed to your own personal die. Maybe I should warm up that cache a little bit, but Go doesn't also strike me as a language that's particularly difficult to learn. One person that I know that has written a fair amount of Go told me once that the way that you increase your productivity and go is you type faster there's no there's not a lot of like

magic tricks keyboard level of typing yes the type system typing type system faster and what do you type the literal word faster so you know it's resolving ambiguities here right um but yeah it doesn't strike me as a language that's 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 some like you said also the ethos behind it and the way that it's driven might not be against your you know your personal flow like slices i know are a big thing and go and i always stare at them and go,

what, yeah, right, fine. There's definitely that thing. And once that penny drops, you can usually make a lot of progress. Mm-hmm, mm-hmm, yeah. Sorry, I cut you off. You were saying something far more interesting. Oh, I just, yeah, just that it doesn't seem like

the learning curve with Go is mostly in the language. I would expect it to 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 domain-specific anyway, right? Like, 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's category, Rustle's 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 a half mile away sort of staring at it, I think there might be a lot of complexity there that is just to get the hello world, or to do 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 you know things that involve monads and things that nobody can explain or understand and i own things it's like don't start except a burrito you can't explain to anyone else without invoking other words an endo functor in the category of monoids or something is what the definition of it is like

that's thank you now and 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 um 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 to me is like that functional thing that really changes the way you think about problem solving. Because you're like, hey, I can do that.

I can compose these apparently arbitrary distinct things and put them together in a way that makes a new thing without either of them having to change, you know, all that solid open close stuff, you know, when, when a function is itself is something 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 an old assembly programmer like me. I'm not used to that kind of, kind of ability to change things. Yeah, yeah. But I mean, you know, the crazy thing about that, and I think a reason why it's cool to learn the language is like, you knew that in JavaScript

too, right? Yeah. So like, you know, talk about something you use for your day job. It's like you start thinking of designing programs that way because 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 us but i don't think out of

the gate i would have ever considered writing i mean i guess newer javascript makes 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 eval and strings along the way. I think we all have crimes against the interpreter. Yeah. Yeah. A 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's a really difficult question. I mean, solving a need... And so actually, I was listening to another podcast the other day, the ADSP podcast, which is Algorithms Plus Data Structures Equals Programs. We'll try and remember to put a link somewhere in our the other day, the ADSP podcast, which is algorithms plus data structures equals programs.

We'll try and remember to put a link somewhere in our transcripts. But in that they were talking about this and saying there 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've become successful and have had a longevity. And so they were talking about things like Erlang, which is another whole different way. It's huge in the telecoms industry because it solves a very real need that they have for certain fault tolerance. And then one of the things that was brought up

was what about Python? The data science community has basically adopted Python as the, and we're going to get hate mail from people who want us to talk about R, you know python is the de facto in my mind solution but the thing is python is 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 and 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. No, that's a kind of accident of how it turned out. And then things like C, I think they found a sweet spot above assembly code and below anything too complicated.

He got a foothold in the early days of unix machines and we became like the essentially the way you talked to the computer in in a reasonable way so maybe that was it now c++ on the other hand i don't know uh why it's been so successful everyone complains about it but bianna is on record of saying there are two types of programming languages the ones people complain about and the ones people don't use and i think you know 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. Well, 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'd be like, only five, and I wouldn't have enough time to winnow it down. But, yeah, 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 of still doing well now java we haven't spoken about that at all and that's a very interesting one that's sort of perceived to be very enterprisey certainly it was its uh sort of first forte although my understanding is it was originally written so that like small ish embedded devices oh yeah absolutely like you know toaster you know java on your toaster and then you'd have to retarget it for some other and you know one of my first side projects out of school was building uh J2ME, Java 2 Mobile Edition apps for a Nokia stick phone.

And that was a fun little project right there. Did you ever do anything like that with J2ME? Oh my golly, J2ME, yeah. The original OG YouTube app at Google was J2ME for some of the devices that only

supported it. And that that was you can imagine the perfect confluence of not really java yeah yeah also yes not really powerful cpu and certainly not very um standardized mjpeg decoding hardware and you know like that's a holy trinity of pain and suffering and so yeah you'd be like i've got it 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 you know oh man maybe we should just transcoze all of the all of the videos on youtube and switch red and green around yeah and somehow that turned into uh enterprise server lit something something something something something right. I mean, we all

like, everyone's got their favorite way of taking the Mickey out of a language, but Java's 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, like, say, the C++ community who like to hate on that kind of thing, or hate is too

strong, but like, take the Mickey out of is that unlike our compilers uh in c++ world although java is compiled it is also jit compiled as a second time so like we know that it works we got bytecode and then we're like hey you know all those layers of software indirection you know and the factory getter and all that kind of stuff hey we compiled out dynamically at runtime we were able to determine that none of these things mattered and it's just like Git 12. C++ can't do that yet, so we shouldn't be too writing off of Java. Yeah, the JVM is one of the most amazing pieces of technology ever.

I use Java a lot. I use a lot of Clojure. I use a lot of other JVM languages. I forgot that Clojure actually backed onto Java. Right, right. Underneath the covers, it's all the same thing. And the cool part about that is that if you spent

a good chunk of your career understanding how the Java garbage collector works, that translates pretty well into pretty much any other J2ME language. You pull up, use the same set of tools. Not J2ME, hopefully. What did I say? J2ME. You said J2ME again. I'm stuck in your head. Any other JVM jvm language jvm uh oh ben yeah it's post-traumatic stress disorder from

right in the early days uh no yeah i you know use the same set of tools you're the same you know sort of foundational principles of like what kind of problems you run into and how you troubleshoot them 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 yeah plus being able to reuse the libraries across them all is an amazing thing right like of course you know yeah the interoperability story is also right right right it's like oh only if we had an amazing thing, right? Of course. Yeah, the interoperability story is also there. Right, right, right. It's like, oh, 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. It's great. Yeah. So whatever it is, it's kind of cool. And, of course, it also spawned the Android apps

or 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 so it's done really well and C Sharp while we're here talking about languages that broadly fit I see it so much for any kind of plan

that we had about this as much as we ever have plans for these chats but we're meandering all over the place and hopefully our listeners just like programming languages do right well that's true but c-sharp i really enjoyed working in c-sharp in fact um i i rediscovered uh uh some c-sharp code that i'd written a long long time ago for for a game for for xbox what was it called there was some kind of like community driven xbox thing you could make games for your xbox way back when it was an experiment that microsoft can fairly soon after unfortunately unfortunately, but,

but that was, that was pretty great. It wasn't perfect. Something, something garbage collector. I 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, not the case, but is it like allowed you to have actual value types, like structure types that are 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 are just four bytes each, as opposed to everything's an object where Java will hand you that. Yeah, sure, you want a new one of those? Here's a new one of those. I'm like, no, no, no, don't put it on the heap and give me a pointer to it. I don't reference like semantics. That's actually not performant, and also it doesn't have like semantics that's actually right not performant and also doesn't have the semantics that i want and 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 reference i mean all 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 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 yeah that's interesting and like you know sometimes those are problems that other people have but a lot of a lot of times i feel like things kind of sneak into the language itself or sneak into the standard library are 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 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 write function, open, print, close, print, everything. 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. You know, and the things that are easy to do,

I mean, we all know how lazy programmers are, which is a good thing. One of the three virtues from Larry Wall, right? Yeah, right. There you go. Laziness. Laziness. Hubris and I don't know.

Memory, probably. Yeah, right. 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 yeah in c++ similarly for the longest time you could define little 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 another eye opener suddenly you're like hey i want to make a callback oh i can just give it a callback and make it in line and suddenly that opens the door 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 I wonder what else falls into that category. I know that, again, from ADSP that I was listening to, APL, which is like a very old programming language, uses symbols exclusively for all of the things. And 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 a things like you know having the the pictograms that mean different things are actually um help you understand what the algorithm does better than maybe the the name does it's like a pictorial representative like rotation or yeah 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 but that's what this podcast is like everyone's podcast is sorry um in in human language there's a theory called the sapir-wharf hypothesis i don't know if you've ever heard of this i think i have heard of this right yeah yeah do you yeah you're doing what yeah you uh my my memory of this is that you're 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 right i think to an extent that my understanding and again i you know we're armchair folks just discussing things we remember from reading a book sometime but the certainly the first language that you learn 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 that 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 that describe whether or not you know this is fact whether you heard it from

someone or it is generally no 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 yeah yeah right it is now you can't help but feel that that would fundamentally change the way you process information if you're essentially in your own head having to tag all information as being from one of these three categories useful actually doesn't it i mean especially in today's misinformation soup that we live in i would love to have that so it seems plausible right certainly the hypothesis seems plausible um and i wonder if the same is true or a sort of more generalized version of it is true about programming languages too right to the extent that

we just said hey learn a new programming language it expands your mind maybe 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'll learn another language and may i'll expand my mind further but i wonder if the actual root thing is also true, 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 after 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. And so it seems like that 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 their first language was Java, right? A lot of people that were graduating certainly 10 years ago when I was actively involved in recruitment more, they were Java. They were like 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 wonder what i want people learn these days

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. So I know that we specifically targeted those. But I wonder what else there is. Is Rust being taught anywhere? Are 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 campus recruiting time. Of course.

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 was 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 cobalt we had classes that were in um uh there's at least one class that was still in pascal even though they had switched over the core program to C++. But COBOL. Yeah, the databases class was in COBOL. Tell me how old

you are without telling me how old you are. Yeah, yeah, yeah. No, that's true. But yeah, I think that's the other thing. And you know, there's also kind of an interesting intersection of these two points, which is that almost all, maybe all, I actually don't know, 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 have your own concept of that that's maybe separate from 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 with most most languages if not all languages that i'm well certainly all languages i'm aware of but i don't know most programming languages

that i've heard of and again i've heard folks discuss about various program languages with this question, have said, no, they all end up being mostly Anglo-centric of some description, which is an interesting... And that was actually where the APL being all symbol-based was an interesting counterpoint. Yeah. So, yeah, maybe the names... I mean, naming is... We could do a whole other episode on naming. Oh, yeah. We could probably do a whole podcast on naming because naming is really difficult.

Yeah. Really, really difficult. But getting it right is so satisfying, right? That's like when you find that word and you're like, yeah, this is what I mean. So let me give you an example. So I'm going to tangent on the tangent on the tangent. So we're probably back where we started. Well, one more.

One more tangent and we're back where we started i think um we we were trying 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 the time that essentially simulation time and we were very excited that we found the word juncture to and we gave it the meaning of, this is the simulation time, right? At this juncture, we were doing this thing, right? It's a very posh sort of – oh, barking, right? You're in the background. It's a very, yeah, sort of posh way of saying time.

But we – so we gave it new meaning. So I guess that's also 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, right? But often not. Yeah. And it was an interesting thing. And then to 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 it a very different static type from the wall clock time type means that you can never mix them up yeah 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 of us as the other but that was that there we are so yeah no i 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's doing that obviously as i already talked about earlier the the pattern in java for a very long time has generally been

to be extremely verbose and throw all of the whole soup of nouns into the names of your classes and functions. 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. Right, because it goes faster if you use shorter names because the computer doesn't have to look up

as many characters, obviously. That's right. The compiler goes so much faster when you do it that way. Yeah, that's why you should use tabs and not spaces as well to indent, because there's fewer bytes to go through. Fewer bytes to get through the parser, right. Yeah.

So, yeah, it's amazing all of the different effects that all these things have. I'm probably sure that most of them were not intentional but they absolutely yeah they yeah i mean well some things have sat down intentionally and said no this is how we're going to do things you know like all the getters and setters in in java are almost like forced to be that because of sort of like things like java java beans java beans yep that sort of said that and you know that's that's a um that's a powerful thing 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 you need to put get in front of things? I don't think you necessarily do. Maybe setting... Sorry, my dog is making all the noise again in the background. We've done so well recently with noise from dog. But he's discovered plastic... His favourite toy in the world is a plastic bucket,

such as a child would use to make sandcastles 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 what what choices does one make so i personally i do like this usually the performance of a language is important to me unless it's a script thing that's 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 crazy. So that's an 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 my own choice there and i'm obviously there is there's a huge continuum between uh 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 a point where I'm confident that my code works. And I'm perfectly happy to write fast-focused unit tests to get there.

I'm happy to let the type system do it 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 tests anyway. And then the tests are hard because the type system gets in the way got it um are you referring to python for example in this instance or not i'm not referring to any particular language i have felt that pain in many many many different languages got it um and i know recently we've been some of the stuff that we we've seen at work is Python. And 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 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 read the hints off, but nothing. It's a comment. But in principle, it's a comment but it's a you know it's a 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 ide's that

are giving you red squigglies because you type hinted it and someone else is passing something which is basically the same but not the actual same type and you know it kind of you squint it comes out in the wash it's like yeah it's fine it's got a getter and a setter that's all i needed right but it's not it doesn't derive from get settable or whatever you've decided your type is called you're like nah which actually comes back to go and my grief sorry we 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 around so you can say um my class needs a need to be past something which has this interface and the interface is you know set foo and get foo those are my two things that that

interface has 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 sort of again open close principles and say hey look you've got this thing I now can retrospectively

put an interface over you as long as that interface has your 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 are one of these. So you're not declaring

something, it's just looking at the usage of it from within the function and saying, oh, this variable must have these methods on it. What it's doing is when you pass an object as a concrete type as an interface,

it just looks at the methods that you have in your concrete class and compares them to the interface. And if they match, it's like, hey, that's cool. Yeah, yeah, yeah. So there's no inheritance mixed up in that at all. Exactly right. And there's no implements that you have to write, which as I say means that you can layer them on afterwards, which is cool.

But I don't like it. I don't like it because i think it should be very intentional if you are choosing yeah i'm an implementer of a class and i'm choosing to be loggable right because i have a log method and my log method does a logging right does does right and now if someone comes along and write and this is extremely i'm just being silly to prove a point. What if you now have math logable, which means, you know, like, hey, this is the logarithm, the natural logarithm of a number. And you're like, hey, I can pass in my logger into my freaking 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. 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 the methods are ambiguous without the context of well is this you know what is this doing here you know is this a yeah i know yeah if i had it at the top of my tongue now i would tell it and now I just sound silly. But never mind. When has that ever stopped us? Never once before. Never have we stopped. Never 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. But we could definitely go over some other things another time. I'd be interested in knowing what our listener thinks of various languages and what goes into the choices folks use for both their home projects, such as if they have them, or little throwaway projects, versus big, this is going to be supported for two or three years, in a company kind of context,

and whether there's something we're missing, because I'd love to hear. So tweet at us. Absolutely. Yeah, this has been a good talk. I think, because I'd love to hear. So, you know, tweet at us. Absolutely. Yeah, 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 popular language that's used in programming, though.

Oh. Profanity. Oh, profanity. All right, yeah, well, I was close there. Yeah. Yeah, it's always fun to get grep and find out how many times someone has checked something in yeah right well uh until next time my friend until next time you've been listening to two's compliment a programming podcast by ben rady and matt godbolt

find the show transcript and notes at twoscompliment.org contact us on twitter at two cp that's at t w o s c p at T-W-O-S-C-P.