Dijkstra's Tweetstorm
Alright. So, you wanted to I think we should kick off with your tweet, Adam, about Well writing pro for money.
Speaker 2:Yeah. Sure. So,
Speaker 1:Well, I I guess, shoot context first.
Speaker 3:So sorry. Go ahead.
Speaker 2:Yeah. Yeah. Yeah. No. No.
Speaker 2:Go well, you dug up this this, appropriately, you called it the Dykstra tweet storm. What what year was this tweet storm?
Speaker 1:1975, I believe, is when he wrote this whole, like, series of I mean and people were like, oh, yeah. Yeah. But there's whole there's more context around it. Did you read what the other things that he wrote? I mean, it's like there's there's really not more context around it.
Speaker 1:He's just basically lighting everybody on fire.
Speaker 2:Yeah. I read that for it was the, like, that 3, 4 page document that you posted as well.
Speaker 1:Yes. That's where he he he's just decided that he wants to light everybody up. Yeah. And, let's see. I and, yes.
Speaker 1:He's got, I I mean, like, he's just saying also things that are just, like it just seems mean. You know? P l one is the fatal disease. Belongs more to the problem set than the solution set. Okay.
Speaker 1:Next topic. You're like, that's come on. That's that's just you're just like an asshole.
Speaker 2:Yeah. Yeah. It did it did seem like he was I mean, again, per I I thought calling it a tweetstorm felt perfect, and it felt like maybe I was reading a displaced Paul Graham essay or something like that.
Speaker 1:The use of COBOL cripples the mind. Its teaching should therefore be regarded as a criminal offense. It's like, do you mean any of these words?
Speaker 2:It's like that's come on. That's a little much.
Speaker 1:Yeah. That's a little much. I mean, it's just like it just feels like, APL is a mistake carried through to perfection. It is the language of the future for the programming techniques of the past. It creates a new generation of coding bumps.
Speaker 1:Moving right along to the next language. It's like, what do you like, dude?
Speaker 2:But there there were there were both, pieces of his bigotry that I agreed with and and sort of feel bigoted about. Like, for example, that there are the implication that there are languages that sort of poison the mind. And I don't believe that, and yet I think that sometimes. Like, you know, my my son was learning Python in school, and I think Python's fine or whatever. But, but I worry about him.
Speaker 2:You know? That's right.
Speaker 1:That is got such a luxury to be worried about him because he's in, like, Python as opposed to, like, it's 2 in the morning, and I don't know where he is. Yeah.
Speaker 2:I hope he's not doing Python at the wrong time.
Speaker 1:That's right. It's like, well, I'm just really just gonna grow up to believe in significant white space. You know? I'm just That's right. Come on.
Speaker 2:I can't as a as a parent.
Speaker 1:It look, Adam, it is normal for teenagers to experiment with the significance of white space. That's a normal phase. A lot of young, so I don't think you have anything to fear. I think it'd be okay. But then
Speaker 2:but then the you know, I find myself, you know, there there was a piece in there saying, basically, that languages affect the way you think. And I've certainly found that to be true. You know, when I I think I I look at some of our colleagues, their Rust code, you know, it feels very much like, like functional programming languages. Yes. I feel like my Rust code, and I'm not proud of this, but, like, kinda feels like modern Java because that that's what I had been in more recently.
Speaker 2:And and I don't know. Like, I I I think that there some of it's, skin deep, but there there are some places where it really changes the way you think about things.
Speaker 1:Right. And I think and that gets us to kind of, like, the tweet that got us here, is the the the tweet that he has around basic. And now, of course, I can't where you know, I had it just in front of me. Oh, there we are. It is so the the tweet that got us here the tweet in this in this 1975 tweet storm is it is practically impossible to teach good programming to students that have had a prior exposure to basic.
Speaker 1:As potential programmers, they are mentally mutilated beyond hope of regeneration.
Speaker 2:It doesn't really give a lot of room. Not not a lot of wiggle room in there.
Speaker 1:Not a lot of wiggle room in there. And it's like like, also, the students that have had a prior exposure to basic, you don't even have to have written it. Like, if you were, like, in the room with a basic manual, we're gonna consider that to be exposure. Yeah. So maybe that
Speaker 2:is a good segue into my Pearl experience because I I actually sort of I I think people feel that way about Pearl, and I'm not sure that they're wrong, because I think Pearl is sort of tries to be everything to everyone, at least, you know, pearl 45 that I learned. So,
Speaker 1:So, well, Adam, first, take you said the pearl was the first code you wrote for money. So take us back
Speaker 2:to that. Yes. Okay. So, the year was, like, 1996.
Speaker 1:Oh, okay.
Speaker 2:And I went to high school, and I was graduating shortly. And I had I you know, my my pearl was self taught, and I was, like, on IRC channels with the the,
Speaker 1:the authors of, like, the the camel and the, and
Speaker 2:and, like, the llama books, and I'm very excited. I'm very excited for Pearl and and the kind of stuff I could do on my back end. The alumni, I I went to a a fancy high school.
Speaker 1:Oh, so, Adam, do you wanna pause just to explain the camel book? Because I feel this is camel with an e, by the way. Oh, yeah. Not camel. It's a no camel, but yeah.
Speaker 2:Yeah. Yeah. Yeah. Yeah. So, there used to be we used to kill trees and print words on them.
Speaker 2:No. So, like, O'Reilly, you know, has all these books with, like, carvings on the cover of different animals, and so the different animals would become kind of iconically associated with particular languages. And especially, like, in the in the sort of early and and pre Internet days, there were these this trove of information that felt otherwise, to me at least, completely, you know, inaccessible.
Speaker 1:Absolutely. I don't know if Yeah. No. No. I think it it absolutely the case.
Speaker 1:That you needed books to be able to learn how to do stuff. No question.
Speaker 2:And and and they were sort of, like, magical. I mean, almost like incantations that that could that again, there was no other way to sort of absorb this information, at least not as, like, you know, 11th grader or whatever that was accessible to me. So, yeah, I went to, like, a a a bougie high school that kept in touch with this alumni and wanted a, alumni database. And I made a alumni database that, like, served up web pages with, like, CGI bin, the the early serverless, if you'll if you'll allow it.
Speaker 1:So I don't know that I will. We
Speaker 2:I don't.
Speaker 1:I how do I disallow it?
Speaker 2:I'm not sure I allow it either. But, yeah, it would like it and it stored it in, like, the Berkeley database format or something, which is, you know, if you look towards the back of of the of the Campbell book, I'm sure that's where I learned about it. So, yeah, I wrote kind of slinging some pearl on an hourly basis, for for money, but way back when. And so and I had a real fondness and real affinity for Pearl as a language, although I'm not sure I do anymore. But So at this
Speaker 1:point so you're a teenager. You're you're on your your you're a high school junior or senior or something like that. Yeah.
Speaker 2:Yeah. I was I was a junior yeah. Junior and senior in in high school. And then in into, like, my freshman year of college because it needed a little, I don't know, tweaking from time to time.
Speaker 1:And do you know at this point that your career is software?
Speaker 2:No. Not at all, actually. You know, I I went to Brown University thinking that I was gonna be a math major and sort of took computer science because I was interested. I'd taken one computer science class in high school in Pascal, which was fine. I don't I I remember very little of it.
Speaker 2:It. That but my most my most distinct memory of that course was our teacher explaining that a finite state machine could be in a finite number of states. Like, for example, you could have a soda machine that was in a finite number of states. And I said, you mean, like, 50? And he left.
Speaker 2:He left? He left the room. He said he was like
Speaker 1:50 is too many.
Speaker 2:No. No. Like, meaning 50 states of the union. Like, that it could be in the 50 United States.
Speaker 1:I you know, a little slow over here. I got it. Okay.
Speaker 2:Well, well
Speaker 1:So 55 United States plus the District of Columbia. That's right. Okay.
Speaker 2:And so he he walked out at that point. So yeah. I did definitely did not know that, like, I had a future, you know, writing code for money.
Speaker 1:But you're writing Perl and you're enjoying it. Yeah. Yeah. Exactly. It was,
Speaker 2:like, solving a problem, and it was, like, it's, like, you know, code generating web pages. It was neat.
Speaker 1:And then, are we gonna get to a Larry Wasser end of this? Yeah. Yeah.
Speaker 2:Yeah. So, so then fast forward probably to, like, 2005, I was in Amsterdam at the first ever, European OSCON. And OSCON is great. Great conference. Really enjoyed, OSCON that I went to in Portland.
Speaker 2:OSCON in Europe was like, you know, but but there are kind of two elements of OSCON that that worked really well together. There was, like, the practitioners who are, like, using open source software, and folks deep in the community, and it was, like, good listening and hearing. And OSCON Europe, that first, and it was, like, good listening and hearing. And Oscar Europe, that 1st year, was only the latter. Like, all it was, like, this big self congratulatory, circle something, where folks in the open source community could could congratulate themselves without, any of the pesky, like, folks in industry, you know, humbling them in any way.
Speaker 2:So it was a tough conference. And then I I will, in full disclosure, also note that I gave a talk on DTrace at that time attended by a single person Oh. Who asked no who asked no questions and left.
Speaker 1:So you I I do not know that you and I have both given a talk to a single person. I you know, I thought that I had always I thought I was the only one.
Speaker 2:Nope. Nope. And and and the thing that and it was up against a Pearl 6 talk. Like, so everyone in the conference was at the Pearl 6 talk or, like, a poetry jam or something
Speaker 1:like that. 6, now Raku. Am I remembering that quickly? Yes.
Speaker 4:I want I wanna say
Speaker 1:my whole brain wants to say Roku every time I think of Pearl 6.
Speaker 2:Oh, that's right. Call back to a to a previous so, but I but I you know, Larry Wall was there, and I grew up really idolizing Larry Wall in a lot of ways. And then, you know, sort of weird coincidence. My my girlfriend at the time was a was a high school teacher, who, who was teaching Larry's son. And in this in this high school that was very small, sort of like this magnet program, there were only about 20 kids.
Speaker 2:And so I sat down next to Larry Wall, and I I introduced myself. And I said, oh, I you know, I I know, you know, I I know this person is your son's teacher. And and and Larry said, well, oh, like, where does she teach? And I thought that was a very strange question because, I basically just said that she was in I said where where she taught, and and he said, oh, my son goes there. And we went around in that circle 2 or 3 times before I excused myself and went to,
Speaker 5:I think it's Alan. It it was
Speaker 2:it was, the the guy from Sun who maintained our Pearl port. And I said, was Larry Wald just fucking with me? Like, what happened there? And he said, no. That's just what he's like.
Speaker 2:And so then I sat at lunch by myself and and thought that maybe I had the wrong heroes growing up.
Speaker 1:And this is coming only a year after we met Dennis Ritchie at a Yeah. We gotta tell Dennis Ritchie story.
Speaker 2:Yeah. Yeah.
Speaker 1:The the the late Dennis Ritchie. So we met Dennis Ritchie in 2004 at, when we originally presented defray. And we were very excited, too excited, some would say, to demo I mean, we did I did I accost him? Is that did I I'm worried I mean, I feel like I can
Speaker 2:So I I think we all approached him with great enthusiasm. And in retrospect, it may have been mistaken for a mugging.
Speaker 1:Because I think we definitely got a fight or flight reaction out of him in that Oh, for sure. And I think as I recall, I was very I mean, I don't wanna use the word aggressive. I I I would like to say enthusiastically, but I think in hindsight, I really have to say aggressively trying to. Do. Because I just want I was trying to thank him.
Speaker 1:Yeah. Yeah. I mean,
Speaker 2:we here I mean, just to paint that scene, we've got 3 20 something kernel engineers at Sun. I mean, not not I mean, you know, hoodlums. But we you know, very, very excited to, like, to meet Dennis Ritchie in the flesh. At least I mean, I assume you'd never met him before. No.
Speaker 1:I never met him. Recognize you. No. No. I don't.
Speaker 1:Poor
Speaker 6:poor Dennis. You know, he was really painfully shy in general.
Speaker 1:Yes. I
Speaker 6:I was I was amazed at how many conferences he actually went to.
Speaker 2:So, yeah, we we we, you know, we brought a a kind of a laptop, almost like sort of presenting of a laptop saying, we wanted to show you DTrace because it's so inspired by your work. And he said something about needed to catch a train and, like, sprinted into the bathroom.
Speaker 1:Yeah. He he Yeah. And, Adam, I don't know if it actually is the case or if it is only in our own retelling that he went into the wrong bathroom. I feel he went into the right bathroom, but he definitely went into the bathroom. He said, like, I need to like, I have to catch a train, and he went into the bathroom.
Speaker 1:And I we we had this idea of, like, should we, like, wait them out? Should we? They I mean, there's no other exit from here. It's like that just and and I we I remember thinking, like, should we go maybe we could we should should we follow him into the bathroom? Maybe he should continue this demo in the bathroom.
Speaker 1:That seems that seems inappropriate. And then we kinda were joking, like, maybe we would go in there. He'd be, like, standing on the toilet, like, waiting for us to be it was pretty clear that, like, yeah. So I think sorry to the late Dennis, Richie. I'm so sorry that we didn't we we had a poor notion of social boundaries.
Speaker 1:We were just in we were enthusiastic.
Speaker 2:We're just excited.
Speaker 1:We're excited. But so with Larry, you feel that that you were getting,
Speaker 2:No. I think I was just getting the earnest reaction, and I think that, like, I don't I don't think he was messing with me. But I I do think I did felt like at at the conference where there was, like, literally poetry about Pearl, and then this very odd encounter, I just, you know, it it made me feel like, again, that I maybe had the wrong hero as a high schooler.
Speaker 1:Okay. So in terms of, like, it's kinda turning to our subject at hand. Do you feel that what is the role? Because I mean, Dykes right here is implying, implying, and I obviously disagree with him, that that you are, if you had any exposure to basic, that your mind has been mutilated. But on the other hand, there is probably some truth to learning those early languages do probably inform the way you think.
Speaker 1:And I would actually, you know, Roger Huey died yesterday. And he's a it was a giant in APL. And I interviewed Arthur Whitney years years ago, and he knew Roger well and described how, the growing up as a Cantonese speaker, Roger would do math in Cantonese in his head because it was tighter, which I thought was really interesting. And I mean, getting to a more positive way of saying the same thing that I guess the Dykes were saying. That these early languages do inform our thinking and the way we think about things.
Speaker 4:So what what was your first language, Brian?
Speaker 7:So you went pretty far down JavaScript and then came back. How did that change the way you think about writing code?
Speaker 1:Oh, well, that's a good question. So that was a relatively later in life thing. Right? So I, my first programming language was basic. I mean, I am of the of of the mutilated minds that Dykes was referring to.
Speaker 1:I had I mean, I can still remember, and I I don't think that I am, like, unique at all generationally in this. I can remember, seminal line numbers in my own programs. So, I mean, good old GoSub 1,001, man. I had a lot of I wrote a some very complicated basic programs, and I do feel that this is where, like, Dijkstra is not totally wrong. I don't feel that my mind was mutilated, but I do feel that it was a cognitive lift to get to structured programming because I didn't really basic does, I mean, fortunately, we've outgrown line numbers.
Speaker 1:Line numbers are really are kind written much basic, Adam? No. I mean, just just Just just the way you're talking about your scope, go to 10. Yeah.
Speaker 2:It's a
Speaker 1:complicated programs get really hard. This is not a deep thought. And to the point that I didn't really but it is extremely
Speaker 7:You doesn't appreciate that Go to could be considered harmful.
Speaker 1:Can I can I say Go to well, but I I also feel that, like, it is very much a consequence of the extremely limited resources on a TRS 80 or on these on these these dot and Apple 2e or an Apple 1? You had so few resources. I do think would the world have been better if that's all 4th instead of basic? You know, I don't know because basic does have that accessibility. It was great to be able to sit down and, like, type in a program from a magazine and watch it do something.
Speaker 1:And there is value to that. That's that's the thing that I don't like about Dykes' statement is that, like, you're dude, you're kinda missing the fact that actually this was the introduction for computing for an entire generation. And that accessibility is important. Just like, you know, Adam with, you know, with your son's exposure to Python, it's like, I'm a mixed mind.
Speaker 2:And you get and you get this this feedback. Right? That you you don't need to know that much to be productive in basic or some of some of these simple languages, and it gets gets you hooked. It gets you into it. And and and Dexter's statement also, implies that one only derives sort of positive lessons from these nascent experiences rather than kind of being able to inform more complicated thoughts.
Speaker 2:Like, basic was useful for this, but it's flawed in all these other ways.
Speaker 8:Didn't he, advocate for Pascal as a better programming language? I I mean, Adam mentioned Pascal in high school. You know, that was my thing. I'm I'm probably a generation ahead of that. Brian, did you did you was was Pascal just not a thing?
Speaker 1:Pascal was no. I mean, I'm no. Pascal was, barely a thing. And I, did Pascal is my second programming language on the Microsoft Pascal compiler. Pass 1, pass 2, pass 3, pass 4, and pass 5, which were the programs you'd run till you would manually run the different passes of the compiler.
Speaker 1:But it was, you know, it was much heavier weight, Pascal was, until Turbo Pascal came out. Pascal was Yeah.
Speaker 8:So that that was maybe the difference for us is it's kind of like if you put your yourself in the shoes of a, like, a comp sci high school teacher, that Pascal just had that that like, you know, it had the amazing IDE. It had the tooling. It I guess it just made teaching easier.
Speaker 9:Hang on. Why are there 5 separate passes to the compiler that you have to run manually?
Speaker 1:That's a great question. That's a great question that we should Wait.
Speaker 7:How would you automate doing 5 things in a row on a computer?
Speaker 6:Oh, it's probably because each pass should fit on a floppy.
Speaker 1:Yeah. That is close. I think that Tom, that's a great guess. I mean, it is it's hard to express how resource constrained you are. I mean, we had a because my my father had this idea that he was gonna start a business with this computer, we had an outlandishly outsized computer with 256 k, at a time that most computers had, like, 32 k or 64 k.
Speaker 1:So it's in terms of I think, Tom, you might be right about having to replace floppies to run different passes of the compiler. And so basic had the advantage of not needing any of that. That. I mean, we did need a certain amount of Moore's Law to come along before we could actually, like, get out of the primordial muck, which I think is what basic was kind of stuck in. And it Aaron, you asked about, why we talk about JavaScript in a bit because I I think that the the tension for me is I I think it's really important that a programming language, a first programming language is very accessible.
Speaker 1:The danger is when someone doesn't realize what a miracle it is that what's in front of them works at all, how much complexity is there. And that's what I I I feel like we certainly for myself, I had I had a delusion that I understood how things worked when I, in fact, didn't because I was given this abstraction that was a much, much lower abstraction. And I like, how do you feel about, like, visual programming, Adam? Like, do you like scratch?
Speaker 2:Oh, yeah. It it a very interesting I mean, I used to think that it was, I don't know. I used to think that it was a real great tool, and and my son spent time on that as well. And maybe it's useful when the obstacle is really the lithography of it, when you're, like, balancing braces is hard or or getting the white space raised is hard. So so maybe it's pretty useful in that respect.
Speaker 2:But I see that, like, it it, you know, it it it doesn't teach any more of the structured or or algorithmic thinking. I don't know.
Speaker 9:Well, I have implemented Asteroids in LabVIEW before.
Speaker 1:Oh, wow.
Speaker 9:Okay. That you know, you can definitely get structured and algorithmic as you darn well want to. Now the amount of pain that comes with that given that LabVIEW is not really or hijinks you have to
Speaker 2:get into, can
Speaker 9:make this a rather hijinks you have to get into, can make this a rather serious feat of engineering just to compile the darn thing.
Speaker 1:Why? So, like, look, you're curious about multiple passes of a Pascal compiler. Why are you doing Asteroids in Labview? Just to do just to show that you could? Or
Speaker 9:I I mean, pretty much.
Speaker 1:Okay. Yeah. Interesting.
Speaker 9:Somebody put me up to it. So, you know, the the language that, in my experience, has changed people's minds the most is MATLAB. Because it is it is probably an entirely different way of going about things, which also makes it, if you intend to learn another language, not necessarily a great first one. Like, for example, if you're using a loop in MATLAB, something has gone terribly, terribly wrong.
Speaker 1:Interesting.
Speaker 7:It is in a kind of weird place of, like, kind of APL and kind of a TI 83.
Speaker 9:But it's also incredibly, phenomenally good at just about anything you want to do with matrices and tensors for engineering.
Speaker 1:And so do you feel that that as a first programming language is, I mean, clearly, someone who's for whom MATLAB is the first programming language is coming in. I I mean, I wonder that's even, like, could be possible today because of if
Speaker 7:MATLAB Georgia Tech uses MATLAB for their engineering computer science 101 course.
Speaker 1:But don't you think by the time a an 18 year old arrives, they have it's certainly a technically a client 18 year old. They have been exposed to certainly scratch, if not Python, if not Java.
Speaker 7:At least in my class, most people, their previous programming language was Excel.
Speaker 1:Interesting. And what year did you graduate from high school, Aaron?
Speaker 7:2000.
Speaker 1:2000. So I I think I mean, our community is unusual in that there's a required computing course, but I think it is very hard to get out of high school today in general, I think, without having any exposure to a programming language. I think I don't know. Maybe that's not right.
Speaker 4:I think Matlab is a better
Speaker 7:choice than say Java. I knew a lot of people who their introduction to computer was. In the beginning, the programmer said public static void main, and it was syntactically correct.
Speaker 4:I'd I'd like to speak up in support of that. I also I also graduated 99 or winter semester 2000. I began life as a mechanical engineer. And part of how I came this direction was I realized how bad other smart people were at interacting with computers. And I just I took it for granted.
Speaker 4:I thought that was I thought that all smart people were good at dealing with computers because that was just no. But, no, there's lots of other ways to be smart. And a a thought that I had while you guys are talking that ties together some of the things you've been saying is that all of these languages have different audiences
Speaker 1:Yeah.
Speaker 4:That we make assumptions that everybody is going to interact with a computer like we do. Like, I my drive to interact with a computer had always been, if you don't know how this machine works, it's in charge of you or someone else is using it to be in charge of you. I wanna be in charge of the compute, period. And, really, like, all the way down. My you know, I took apart every computer I ever had.
Speaker 7:Tell that to your baseboard management controller.
Speaker 1:Exactly. I was
Speaker 4:gonna say Oh, I know. I I believe me, some of Brian's talks are my favorite for that reason too. But, yeah, as far as I could physically see without a, you know, electron, you know, microscope, and all of these different communities. Because as a mechanical engineer, I've used Labview. I've used MATLAB.
Speaker 4:I've used I've used crazy things in Excel Macros, and and also did a comp sci minor in school and did, you know, c and c plus plus and Lisp and everything else. And my my handle is Perlhack for god's sake. I've also met Larry Wall and had a similar experience as Adam, so
Speaker 1:I was That's good.
Speaker 9:And and my first inclination oh, my
Speaker 4:first inclination was that he was doing a bit, and but it was not. But the my my analogy that I wanted to make was that I also study human languages. I'm I'm fairly passable in Spanish and French when I travel, and my whole purpose for that is to just to be able to communicate with other people who speak those better. And each of those languages has a different mindset to it. You know, all these things have a a philosophy behind them that drives their design choices, and it helps you get into the mind of other people.
Speaker 4:In this case, we're all talking to the same computer. So the thing that the real label of fact here is is is machine language. So if you've got some exposure to machine language, and I think c is the closest thing to just above that, then you're best equipped that's like knowing Latin and Greek, you know, for for a certain family of languages and and it helps you see those other things. But, yeah, it can be bad to learn basic first if you go too far with it without getting exposed to other things. But just like it you know, English is English is a good language because a lot of people know it.
Speaker 4:You know? So it's like knowing Java, you know, because you can get a lot of jobs. You know, there's a lot of jobs out there with Java. But if you only know Java, you're going to be bigoted towards it just like an American who never travels.
Speaker 8:There's an interesting analog to this in in natural languages. I mean, I think that's that's super interesting is, I don't know if folks know about Esperanto. Esperanto is this, sort of invented spoken language which is the interesting property that it's it's a context free grammar, so you know that might be interesting from a sort of machine natural language processing point of view, but there's all these research papers that look into if we teach our children Esperanto, which is I guess kind of a weird thing to do, do they acquire a second language easier than somebody that for instance learned English or Spanish first? Then there's there's a fair I don't know, Brian, I think you mentioned at some point that that your wife is into linguistics. Have have you encountered this this idea of of, natural languages and context free ones and, you know, how that affects the development of the mind?
Speaker 1:Well, yeah. And I think that I mean, we'll and this is what I got into this with conversation with Arthur about people that, for whom their first language is a tonal language. And it is really, really hard for for me to do to, learn a tonal language as someone who grew up. And in particular, one of the things that I learned about myself when I we we went to when, my oldest was very young, we went to this, like, a Mandarin circle time, which I we thought this would be a good idea to, like, get them exposed to different this is kind of a goofy idea we had. And so they're doing, like, colors in Mandarin.
Speaker 1:I'm like, alright. This is good. I'm gonna, like, learn to speak. I'm gonna learn to say the colors in Mandarin. And a friend of mine is a native Mandarin speaker, so I was very excited to boast that I had learned how to say purple in Mandarin.
Speaker 1:So I, you know, bounce it off her. She's like, I have got, like, absolutely no clue what you're trying to say. And I, like, probably she's like, are you like, you're saying sister-in-law? I'm like, no. No.
Speaker 1:I'm not saying sister-in-law. I'm saying, you know, like, I gotta I have to repeat this again and again and again. And I'm like, alright. I I'm trying to say purple. And she's like, oh, you're trying to say and, like, to my ear, repeated back exactly what I was saying, but it obviously was not.
Speaker 1:And I'm like, I don't have I can't hear the difference here. I I like, this is just like these languages are just gonna be off the menu for me. And it is hard not to think, like, surely this and, you know, I think that that, you know, in terms of music and so on, you gotta think that, like, this does change the way Mhmm. You you you think to a certain degree. And so it's it's hard not to think that it has some impact.
Speaker 1:But I think it's also a big difference between natural language and a and a computer language. Clearly parallels, but, there are, I mean, our our computer programming languages are much, much, much smaller than natural languages. And they're they've got very different problems they're trying to solve.
Speaker 9:But tangentially, I wonder if you grew up with a bunch of people who were speaking Chinese non tonally, would you get the gist of it eventually?
Speaker 1:I don't even well, I so you mean, like, maybe
Speaker 9:So, like, if if if speaking Chinese the way someone who does not speak Chinese attempts to speak Chinese
Speaker 1:Well, I so with Well
Speaker 9:And if everyone around you was speaking that whatever that language is
Speaker 1:Well, so remember you know the word
Speaker 9:has, like, 6 different meanings.
Speaker 1:Yeah. So you're talking, like, Mandarin or Cantonese. You're not talking I mean, you're not that there's not spoken Chinese. Right? You're speaking a Right.
Speaker 1:Yes. And these are languages that are not like, you can't there's no such thing as this is part of the reason why these languages are really tough if you are coming from a non tonal language. You can't there's there's there's no such thing as non tonal because the tone changes. Like, in particular, for someone like me or at least one thing about myself, I use inflection a lot. And you cannot use inflection because you are changing what you're saying.
Speaker 9:Right. But there are, like, somewhat similar things in other languages like Buffalo Buffalo Buffalo Buffalo Buffalo. Right? Where it's the same word used, you know, 6 different ways.
Speaker 4:Well, that's that's inferring from from position and and experience. But the the thing with tonal languages is that there's there's a specific region in your brain for language and it's different for, you know, it's different from everything else. Like, it's different from singing. Like, singing is different from speaking. There are people who have brain damage and they can't speak.
Speaker 4:They've got an injury, but they can sing what they're thinking. It's it's totally it's that totally separate. And related to that is the part of that part of the brain that processes the auditory information coming in. And it, you know, those those neural paths get strengthened. And if by, like, age 12, you haven't been exposed to a tonal language speaker that you're really trying to understand, then the other pathways that you're using get strengthened so much that, yes, you can develop that ability, but it takes a lot of immersion and a lot of it takes a lot a lot a lot a lot of effort, for comparatively little success.
Speaker 7:But do we think there's something analogous in a computer programming environment? If you Right. Started programming when you were 12 and you
Speaker 4:were 30 the first time
Speaker 7:you ran across a non garbage collected language.
Speaker 9:I think that it depends on how far you've gone.
Speaker 10:Absolutely, there is. Absolutely, there is.
Speaker 6:Yeah. And I think the big gap is between the imperative languages and the functional. That is good. Basic and Fortran kinda look alike, but throw MATLAB or
Speaker 7:So if you raised your kid on closure, they would suddenly be seeing all these mutable state bugs and be like, wait. What happened here? How did it it I just looked at it. It can't be something
Speaker 1:different now. I mean, everybody everybody likes.
Speaker 10:But, like, when I started learning Rust, it was amazing how that
Speaker 9:you understand monads, you become completely incapable of explaining them to anyone who does not.
Speaker 10:Hey. A monad is just a burrito.
Speaker 6:Yeah. I I I think I'm totally ruined for functional programming from my childhood Fortran.
Speaker 4:Yeah. And I think that can
Speaker 10:be said that the idea that you learn a language and you learn it well, that really does influence how you think about things. I you know, like like, the big shift in my mind was when I really truly learned how to how to program in Lisp. That was a totally different paradigm than programming in c, and it really changed the way that I thought about computation.
Speaker 1:So yeah. The it it I'm sorry. Go ahead.
Speaker 4:I was just gonna say I had a similar experience where I learned c and c plus plus before scheme as a dialect of lisp. And and then learning Lisp was like, oh god, this is like freedom. It's like once you write something, you know, I don't ever have to touch that thing again. I can I can wrap something around it if I want to modify it? But once I get that one idea right, it's it's done.
Speaker 4:You know, like, the idea of changing that again is crazy because now I've got 15 other things depending on it.
Speaker 1:Well, yeah. And, Andrew, you'd asked about JavaScript. And that actually learning JavaScript. JavaScript was the first time I'd used a closure. So Dan, to your kind of point about, you know, having this kind of light go on, I just I did have to light up a new area of my brain, to and I I then felt that JavaScript and I do I still feel that JavaScript is mistaught to those for whom it is their second program language, where I I really think that JavaScript should start with closures.
Speaker 1:And I think TypeScript has made us a lot better. But I remember, like, discovering like, I just had no idea there was a real programming language there. We were using JavaScript because we had to because we had that's what we had to do in the browser.
Speaker 7:And Yeah. JavaScript is scheme for the browser.
Speaker 1:It really is. Well, it's
Speaker 4:plus plus some other pitfalls. But the I think everybody's first JavaScript book should be JavaScript the Good Parts. It's the only JavaScript book on my desk.
Speaker 1:A book written several years after we were doing this. Right? So this this is in we and again, I feel like, I mean, Adam, I feel like you and I were part of a, like, wildebeest migration of computer science grads, going into JavaScript for the first time in 2,000 6. I mean, I think a lot of people did this. I mean, I saw Matt Rainey here.
Speaker 1:I know Matt was doing the same kind of thing at the same kind of time where we were discovering this actual real programming language. What year would you be
Speaker 2:said speaking of JavaScript and speaking of early languages, I just wanna note as a footnote, I did say that Perl was basically my first language. In fact, I wrote some JavaScript. I think it's unrecognizable, basically. And someone will have to call
Speaker 1:me on the year, but, like, in
Speaker 2:1994 because I wanted to make, like, a counterspin. The code is miraculously somehow still
Speaker 1:on the Internet. What?
Speaker 2:But, you know, I I did I did have a long history of, of JavaScript before we did it, you know, years later.
Speaker 1:Hold on. The code that you wrote in 1994 is still on
Speaker 2:the Internet?
Speaker 1:How? You know what? I posted it to some, like, Usenet
Speaker 2:forum, and I can always find it because I misspelled language and somehow, like, you know, language equals JavaScript, and somehow the browser was still fine with that. So it makes it easier to search for.
Speaker 1:And are you I mean, like, I can't imagine some of my first basic programs being on the Internet. I think I would be mortified, but I don't know.
Speaker 2:Okay. Okay. While we're talking, I'll see if I can dredge it up.
Speaker 1:And, I mean, so 1994, that is, like, super early. That's, I mean, that's that's Live Script era. Right? That is, like, super, super early JavaScript.
Speaker 2:Because I was a kid, I put a copyright date on it because I don't want anyone stealing my Right. Proprietary JavaScript, you know. So,
Speaker 6:that that that's before Java was named, so it couldn't have been JavaScript then. Right?
Speaker 2:Okay. Well, then then let me go I'll I'll find the code, and it'll it'll, you know, have the year on it, I'm sure.
Speaker 1:Yeah. I mean, it's it when it's obviously, it's it's well before 2000. So it's gotta be in that that nineties era of, but I and I do think that, you know, Erin, you were asking, like, is there an analog? I do feel that that we can adapt. Certainly, I think that, like, we can learn new computing languages early easier, much easier than we can learn new spoken languages.
Speaker 1:I just don't think that we our circuitry hardens so much around computer languages as it does around spoken languages. And, I mean, Nate, you raised a really good point earlier about, like, that we've got a bunch there are there are obviously many different languages, and it's easy to be judgmental as Dijkstra obviously is about those those early languages. To me, the most important attribute of those early languages is breeding and enthusiasm for, for computing. I mean, that that that's actually the most important role of an early programming language is that you get excited without getting arrogant, I feel.
Speaker 4:Oh, yeah. And that's that's really one of my cringiest memories that I still, you know, those things that you, like, wake up at 3 in the morning and you're like, oh, you remember that time? Where we were using, we were using Labview in a class, in one of my mechanical engineering classes. And me being, like, steeped in computer science stuff and being, like, in the mechanical engineering building, I was the resident, you know, computer expert, and and just being, like, oh, what is this garbage? You know, and just being totally elitist about it, like a 19 year old and and just completely made them feel bad about it.
Speaker 4:And they were like, what's wrong with it? I don't understand. I was like, oh, this is just horrible. You know? And and I had no good reason for it, really.
Speaker 4:And it was it it was like they're like, but but look at what you can do with it. Like, it's it's so easy to wire up what I need to do, and I don't have to write any code. I don't have to maintain where my files live. I you know, all these things. And I I wouldn't have any of it, and and now I just cringe thinking about it.
Speaker 1:Well yeah. And and the Dijkstra's screed is loaded with that kind of cringe. And I think that it is Nate, I think you're right in terms of, like, the, that you'd never want to stomp on that enthusiasm for computational programmable logic, wherever it's coming from. If people are excited about, you know, Excel is is one of the most important programming languages. Right?
Speaker 1:And that's the there are a lot of people who for whom they don't think of themselves as technologists, and then they're doing actually very complicated spreadsheets. It's like you're programming.
Speaker 4:And and creating real value. And there's businesses and, you know, huge businesses and, you know, financials that run on Excel spreadsheets that have been maintained for 20 years. And and you can't underestimate the value of the real computer science underneath of that that's Microsoft maintaining ridiculous levels of binary level compatibility for that long that enable those businesses to live that way. You know, that's that's where we should be talking about. It's like, look at the wizardry that goes into that.
Speaker 4:Don't don't worry about the the normals, you know, actually using the computers. You know, we live in between that.
Speaker 11:So Yeah.
Speaker 3:So you mentioned the, cringe moments that you know, a couple of people here have mentioned moments using, spoken languages that were a little cringey, maybe just a little uncomfortable. And I think the reason that we retain the ability to learn programming languages, better than spoken languages later in life has a lot to do with the purpose. The cost of getting something wrong in spoken language are pretty high because they're generally social costs, but there could be others. The cost of getting something wrong in a computer language is super low. You just try, try, try again, and you don't tell anybody about the embarrassing moments.
Speaker 3:I think that that's the the real thing that I think separates people in terms of how they, go about their programming career based on their first programming experiences isn't so much language. It's about whether they did it socially or not. If they did it in a classroom and they heard at somebody say Etsy in, like, you know, an intro to Linux class, if you heard Etsy, you'll say that because it's a lot cheaper to say Etsy. In my mind, I did, like you know, I played with, like, BSDs, Linux all throughout the mid nineties, solo, lived rural area, didn't have anybody other than people on the Internet to talk to about it. And I said etcetera in my head for years, and it took me until about 2003 or 4 before I finally gave up correcting people because I was it was just so wrong to me.
Speaker 3:But throughout my career, I've noticed that there's other people who basically learned solo all through reading. I will have, like, sort of a shorthand in, say, pull requests where I can much more easily understand what other people who learned solo are trying to communicate in their code versus somebody who's learned in a classroom who was told how to do things another human, and had the ability to interact more.
Speaker 6:Yeah. I think you're nailing it. There there's a huge cultural component that goes along with the language. And if you're if you're not a member of that culture, then the language is very different.
Speaker 12:Because, also, I
Speaker 6:And I I I think a lot of us old timers had to learn language computer language from a book. But these days, people can dive into GitHub and see a huge corpus of code, and it's it's a whole different experience.
Speaker 1:Okay. So actually Yeah.
Speaker 3:And, you know, the line numbers started out as a way to communicate, to the computer, I think in basic. But, thankfully when I got to quick basic line numbers weren't there anymore, but I still use them to talk to people, you know, to refer to a line in an article in Byte Magazine, for instance. They were still useful for that.
Speaker 1:So interesting, Drew. And I think, Tom, you are bringing up an important point that if you if there's if there's a modern analog to Dijkstra's concern, I do get concerned about people who because, Tom, you're right. You know, back in the day, you bought you had to buy a book to own a programming language, and just like your camel book, Adam. And that is people want to dive in and be instantly kind of successful with a language. And to me, that's a real contrast that Rust has with other programming languages.
Speaker 1:That Rust doesn't Rust will punish you if you try to cut and paste your way to success. That you actually want to sit down. And I done with Rust. I am with with the the Rust programming language book. The, with the programming Rust book.
Speaker 1:Excuse me. With the the O'Reilly book. I did something that I had not done since my days of basic. I sat down and typed in someone else's program. And, boy, did I appreciate the pedagogical value of doing that.
Speaker 1:Like, I end I hadn't needed to have done that for many, many years, but I would really recommend it for anyone learning Rust because it it it allows you to because typing in programs, someone else's program, actually has value. You you begin to learn, like, the tool chain. You learn how it's broken. I don't know I don't know if you did you ever did you ever do that? Do you ever type in?
Speaker 2:Yeah. I mean, definitely as a kid, like, I would I, and this must have been basic, but, like, on our Commodore 64, I was type like, that's how you played games. Like, you either put in the audio cassette that could, like, have the game already on it or this spiral bound book of magical codes you would type in meticulously. Pedagogical experience, but, like, certainly, like, later on, you know, with these pro books or whatever, yeah, you'd you'd try it at home. You know, I tried on my back, and it was amazing to be able to reproduce what they were showing us.
Speaker 1:And I don't know what I do about that. You I know that you controversial figure in his own right, but Zed Shaw is very big on this idea that that you learn languages with repetition and that you should learn to program a language the way you learn to, like, play the guitar. Well, I Not all languages. Well
Speaker 10:I totally disagree with that. I'm sorry. That that is that is just ridiculous. You do not this is that that goes back to these people who have these, like, code kata things. You know, this is not a martial art.
Speaker 10:Alright? You do not gain the muscle memory of writing a for loop by typing it in 10,000 times. And it like like the way that you learn say a punch or a kick or a strike in the martial arts. That's just absurd. Like and
Speaker 9:yeah. I I really I don't know if that's true.
Speaker 7:I used to make a lot of all by 1 errors and 4 loops.
Speaker 9:Right. I mean, like, in all languages, a 4 loop is the same. Right? Like, pretty much give or take, the syntax changes a little bit here, a little bit there. The important thing is understanding what it does.
Speaker 9:Right? And, like, there is this strange thing about software where, like, if there's not a physical artifact, people seem to feel this need to add a ton of religion on top of it, which is, like, one of the things that's really off putting to a lot of people who try to learn Rust is that, like, you must accept this, you know, this religious text to begin with. And, you know, like, the more you can avoid, at at least for some people, the more you can avoid the the books and the culture and the surroundings of it, the better it is to actually accomplish things with the machine. Right? Especially when that doesn't necessarily align with accomplishing things.
Speaker 9:It aligns with, you know, proving that you're you're Dijkstra and you're more arrogant than everyone else or whatever.
Speaker 10:Something to bear in mind about Dijkstra's thing and and I I feel like this comes up in these discussions kind of frequently. There was a context to when he was writing that. And, you know, like, I I don't recall exactly when he wrote the thing, sometime in late seventies, but, you know, he's he's looking at it from a very specific context. Right? You know, it's just the emergence of structured programming.
Speaker 10:That was still a very controversial idea at the time. You know, you have this completely unstructured programming language, and you have a lot of people who have basically learned by not having a body of expertise to which they could go to sort of vet their own ideas about things. I I think this is something this discussion has kind of danced around but not really confronted but Well, so it bears on what you just mentioned. There there is, like, expertise in the form of books was highly useful 30 years ago. It it it wasn't a religious thing.
Speaker 10:And and I would go so far as to say that the opposite is kinda true these days. These days, the religious places that you go to are Stack Overflow, so you can cargo call somebody else's snippet of code to open a file or something like that because that's weird these days for some reason. Reason. Or, you know, you go to, like, the uncle Bobs of the world who are gonna say, well, you you must genuflect in this way and write your test before you write your code. And then and only then will you be pure enough to be blessed by the compiler.
Speaker 1:Yeah. I mean, I I I think that the well, actually, just a bit of broader context of Dijkstra's I mean, we actually he throws a bunch of other languages under the bus, including a couple that are structured. So I think that he was just just wanting to kind of sound off in this in this piece. I do
Speaker 6:Well, the Dyke Dykester was, by then, a a well known flamer anyway. So it's it's all in keeping up with his personality. And and probably the only reason he got published was because he was already well known.
Speaker 10:So and and there were also a lot of languages that were highly deserving
Speaker 7:of being
Speaker 10:thrown under the bus back then. Cough p l 1, cough ADA, cough Algo 68. I mean, like, you know, the, like, the the languages of the day
Speaker 7:Algo 68 changed the world.
Speaker 10:Yeah. Sure. It's report sure did. I don't know if that's the language itself.
Speaker 1:I think I think Alco is part what but a lot of those those languages were important. Right? I mean, I think that they all and
Speaker 10:Algol 60 was certainly I mean, the the the languages were enormously important. The thing about Algol 68 was it was so complex that there were very few, like, real implementations of it. Right.
Speaker 1:Yeah. But the PIN p o one obviously had the same issue. And p o one was Yep. I mean, there there again, there's there there are there are nuggets of truth to to everything that's kind of being said. One question I have is because I definitely had this about, like, Rust in particular.
Speaker 1:Where does Rust belong in kind of the progression of languages? Because I don't think that Rust should be a first programming language. I don't think, I mean, I I I don't know. Adam, what do you
Speaker 4:I think I think the progression is nonlinear. That's the answer. Well It's got it's got a very, very important place.
Speaker 10:Rust is what happens when you when you got 25 years of experience with c plus plus and you say, what would this language look like if we remove most of the rough edges and made it safer? You would end up with something that looked an awful lot like us.
Speaker 7:When you say where it belongs, you mean the family tree or, like, which languages should you learn in which order?
Speaker 1:The the the latter. I mean, if if if a if we want to and I I first of all, I wanna I just wanna restate my agreement with what Nate said earlier that I think that whatever any I I'm actually, even for out of even for your kids, even for my own kids, I am nonjudgmental about the path people take to computing as long as they are enjoying computational logic and program programmatic logic. That's the most important thing. And I think, like, my daughter programs in Scratch and Minecraft are the kind of her the things that she gets very excited about. And the the, you know, the redstone engineering stuff on Minecraft, I think, has got a very programmatic kinda element to it.
Speaker 1:I think that's great. The kind of the question is where do if you kind of envision a progression that you for someone who wants to get kind of deeper and deeper into computing. Where, you know, does a I I personally think that a language that c still has an important role. I think that you'd need I think you called it the Latin or Greek. I I think that's a good analogy.
Speaker 1:I think that you you'd need at some point to learn enough c to appreciate what it is and what it isn't. I don't know that like, I don't think anyone should ever learn c plus plus I think c plus plus is just a mistake. But, obviously, that's I'm beginning to sound like Dykstra. I I said to me, you wish that brain damage?
Speaker 8:I I wish that it, that I had been taught Rust instead of c plus plus. Like, I got thrown into c plus plus, like, it was really weird. Like, our 1st first programming language, 1st year of college was Java, and then and then 2nd year you get thrown into this, data structures and algorithms course, which actually Edwin was on the call. He will he actually taught me that. He
Speaker 1:didn't remember that which is kind of
Speaker 8:which is kind of kind of funny. But it was like it's like you know Java, so here's c plus plus. And most people hadn't seen c at that point, which is like okay. So like, all of this memory management stuff is like it's like you had a garbage collector, now you don't. And by the way, we don't care about the language.
Speaker 8:We we care about, you know, hash tables and and trees and things like that. At that point, if somebody gave me a rest,
Speaker 6:I would have preferred that.
Speaker 1:Well and so that's that's why I'm saying, because, Adam, you were a part of a real revolution of so the I Adam and I share an alma mater, but Adam was 5 years. Alma mater, but Adam was 5 years, 5 years later than I was. And you were because you were in they they basically redid the intro curriculum, to get Scheme much earlier, which I thought was really interesting.
Speaker 2:That's right. So so for many years, they had taught a object oriented, intro class for 1st and second semester freshman year that was all in Java, you know, as a but as a means to teaching object oriented programming. And these 2 professors who are kind of one from a more AI background and one from a, algorithms background, but kind of iconoclastically wanted, and this was taught by, you know, this intro class was taught by Andy Van Damme, who just got the computer history aboard. This is all kind of a legend in the field of graphics. But they wanted to kind of break with that tradition a little bit.
Speaker 2:And so, yeah, we we started in Scheme, and then the it was a full year course and then went to ML and then went to Java at the end, in part to prepare people from subsequent classes that was had been assuming this object oriented background. And just amusingly, at the time, we the version of o m of ML we were using, and this was in, OCaml. And as I recall, the error
Speaker 1:messages were in French or, like, many of
Speaker 2:them were when we got to, like, really deep, like Yeah.
Speaker 4:That sounds
Speaker 2:right. So that that was that was, you know, good to good to learn some other languages at the time.
Speaker 1:That's right. And, Adam, did
Speaker 6:you did
Speaker 1:you take the new sequence? Or
Speaker 2:no. So I I took the old sequence.
Speaker 1:That's what I thought. Yeah. Yeah.
Speaker 2:And then I and then I helped create the subsequent sequence, the the new sequence. So I I I think I was of a rare breed that got kind of both of those things to be able to compare. And and to your question about rust, like that, that was my first reaction when when trying Rust. And it and it was my my attempts for the Rust were painful because I approached it. I think, Brian, the way that you advocate, no one approaches it, which was sort of, like, head on, don't learn anything.
Speaker 1:Okay. Well, so I I I mean, we gotta go to a little birdie because So my first exposure to Rust was your first exposure to Rust. Right. So my first exposure to Rust was reading your blog entry about Rust. And as you are reading and this is, in 20 I wanna say, like, 15?
Speaker 1:2016? Something like that.
Speaker 2:Yeah. Like, yeah. 14, 15? Yeah.
Speaker 1:So it's early. And Right. As, like, this blog entry, you're just watching Adam punch himself in the face over and over again. And I'm thinking to myself, I as I'm reading this blog entry, I'm really glad Adam is doing this so I never have to learn this programming language. This is a disaster.
Speaker 1:It's because
Speaker 5:he has to unlearn all the Perl first. I mean, I
Speaker 2:I personally don't. I don't
Speaker 5:I don't think Rust would be a bad first language because it's it's really
Speaker 1:Hold on, Edwin. You see, you should go read the blog entry because this is in 2015, and this is early Rust, and it is brutal. It is all blade, no handle. And the the the thing that was so interesting to me that Adam referred to this since then is the last line that I I get to the end of your blog entry, and I am thinking to myself, thank god that Adam has thrown himself in the traffic so I never have to learn this programming language. And the closing sentence y of that blog entry is like, in conclusion, I'm kinda looking forward to doing some more Rust in the future.
Speaker 1:Yeah. Yeah. Yeah. And and it was brutal. And I think the thing that
Speaker 2:that that experience taught me was that there was there was actually something different there. That experience taught me was that there was there was actually something different there. And the mistake I had made was thinking, you know, I'd I'd done a bunch of different programming object oriented, procedural, declarative. Like, I thought I had all of the tools, and I didn't. And that was the thing that was so interesting about Rust.
Speaker 2:And I think the the interesting, part about it to to think about how it would be included in a curriculum is because it actually does introduce a different concept. Yeah. And so I think I I can't remember who said it just now, but, you know, Rust as a first programming language, I think, is a terrible idea with with respect just because I I it builds on some of these other concepts that are much easier to learn in isolation.
Speaker 1:So my fantasy,
Speaker 2:you know, for for, like, if I ever got to teach a, like like, a junior level or senior level class would would be this kind of comparative literature of different programming languages and techniques and models. Because it it's not you know, one of the things we've touched on in this conversation is there's no right programming language. Right? You you don't say, like, which is the best, and it depends all on what you're doing. Doing.
Speaker 2:Like, even Pearl probably, possibly, like, has its place, maybe even basic. I don't know. But it it it's dependent on the task
Speaker 1:that you're you're doing.
Speaker 2:And I think the important part or a thing that a computer science education, a formal computer science education, where in particular in modern times where it can you know, earn its value is by giving people a bunch of tools, like filling up that tool belt. So when they come to new problems,
Speaker 1:they can know, you
Speaker 2:know, this might best be solved with, you know, object oriented programming or functional programming or something like Rust.
Speaker 6:There there's a a tension too in learning between the people who hate magic and wanna know how everything works in great detail versus the people who just wanna see something useful done. So it's kinda top down versus bottoms up.
Speaker 4:I think that both of those people
Speaker 6:It's really hard to satisfy both.
Speaker 1:Yeah.
Speaker 4:I think there are people who actually might
Speaker 2:There are people who think, you know, you can't do object oriented programming in c, and, of course, you can. And so, but you but if you've only done c, it would it would never occur to you. So I think having this comparative approach, you know, as Dan was saying, you know, learning Rust informs the way that he wrote c, and I and I think that, you you can see that blending, but only as you've been exposed to these different concepts in different
Speaker 1:Yeah. I think it's interesting that, like, actually, to be most effective, you need to learn a couple of different languages, which, of course, like, I mean, many software engineers have. And, Edwin, I'm sorry. You were getting in here. I didn't mean to to step on you there in terms of the, first of all, do you remember teaching semi in algorithms or not?
Speaker 5:It was a big class.
Speaker 1:Okay. That's a no. But he So I
Speaker 4:Sorry. Go ahead. I was gonna say I have an earnest question that I don't have a loaded answer for. It's that if you hadn't cut your fingers and shot yourself in the face with c plus plus of enough, would you have the same appreciation for, and and motivation for the rigor for for learning Rust?
Speaker 1:Well, so I remember coming to, I I broke up with c plus plus in college. I I there was no way I was gonna write another one in c plus plus after 1996. That was out of self preservation. So I am not coming to Rust from c plus plus. I'm coming to Rust from c.
Speaker 1:And what I which gives me a different set of challenges and biases, but also different set of strengths. I mean, one of the things that I definitely did, because I didn't exactly learn from Adam's log entry, is I wanted to implement a doubly linked list in Rust to solve a particular problem that I had. And, that is not a good thing to go do in Rust. In fact, there's even a great blog series called, so you really want to write a doubly linked list in Rust? That spends the first, like, 5 entries trying to talk you out of doing this.
Speaker 7:Which I a linked list in Rust, step 1, consider using a b tree instead?
Speaker 1:Well, that's it. And and, it when especially a doubly linked list, because the and I do think, Adam, this goes to your earlier point about there is a big new concept in Rust around ownership, and a doubly linked list is a multiply owned data structure. And it, therefore, is a very, very, very bad match for Rust. It's possible, but it's gonna really hurt, and you've really gotta ask yourself why you're doing it.
Speaker 5:You don't have to teach that in our first course in Rust. I mean, you don't build doubly linkless and Python easily either. You try to find things done in Python. Right? So so you can expose only the bits that that teach you what you need to teach.
Speaker 5:I I don't think you need to get into all of the the complexity right away if you if you were doing Rust as a first course. Some part of it is fundamentally just a subset of all the bad things. Right? Like, rather, the the subset is left after you've taken away all the bad things.
Speaker 11:So I was surprised in this group,
Speaker 7:no one mentioned Erlang as a language that really changes the way you think.
Speaker 9:That's because we haven't found a group in in this discussion to break it in. But it is it is honestly what I would consider the closest thing to a Rust ancestor in that it acknowledges the laws of physics exist on multicore systems.
Speaker 2:Well, I I think it had a
Speaker 6:huge influence on Go, which is rather more popular now.
Speaker 10:No. I I can tell you for sure that's not the case.
Speaker 2:Go
Speaker 7:tried to go straight all the way back to CSP.
Speaker 10:Yeah. No. CSP. So, I mean, like, Rob Pike did a series of 5 languages. Go is the latest one of which that were all centered around using CSP as a concurrency primitive.
Speaker 10:But Erlang, I don't think had a significant influence.
Speaker 1:Yeah. Erlang, I I am too colored by the systems that I had to deal with that were written in Erlang and their pathologies. So I feel that I cannot speak without bias on their language. I am too biased by, by RabbitMQ and by by React, RabbitMQ especially, which was a real struggle, that there are things that are really interesting about Airline, but I found that when it misbehaved, it was very, very difficult to determine what was going on. And that, Brian can get in here to correct yeah.
Speaker 1:Brian. Yeah. Brian Zeske is a did a lot he's done a lot of Erlang, a lot of c, and a lot of Rust. So maybe you can find some perspective here. Well, I I was
Speaker 12:just gonna say that your problems were not with necessarily Erlang language, but certainly Erlang the runtime system, which certainly has had its share share of issues. Yeah.
Speaker 1:That's an interesting distinction, actually, Ryan. So do you wanna elaborate a little bit? Because I think you're right. I think that it's like and it was also my problems are also with Rabbit itself. But the with I think Beam as a runtime versus Airline a language, I think, are 2 pretty different things.
Speaker 12:Yeah. And that just that just goes back to its history. I mean, it started from Prolog. Joe, Armstrong, the creator, or the primary creator, had a love for an affinity for Prolog, and he kinda tried to combine Prolog and c plus plus and all kinds of other ideas and put it all together, and that was Beam. And then you can imagine coming out of that when it got rewritten in c.
Speaker 12:You know? It it it's in trying to do many to 1, or many to many thread mapping in user space and stuff like that. Just it has issues.
Speaker 1:Yeah. That's interesting. And I mean, I think that that is honestly, that's part of the tremendous appeal of Rust, is that you oh, that run time time component is a big challenge when languages go into production. The the run time, whether it's the JVM, whether it's v eight, whether it's the Go run time, whether it's Beam. Like, the I I find that I spend a lot of time with the run time.
Speaker 1:And then not necessarily observing the language as it was kind of designed to be implemented, but rather having to deal with it operationally and not having a runtime has got a real appeal to it.
Speaker 10:That's one nice thing about Rust. That's why we chose it for our last project at Google. I mean, it you know, I I was looking around and I we were gonna do a new kernel and I was like, I don't wanna do this in C. And, you know, what are your design criteria? It's like, well, I I don't wanna run time.
Speaker 10:I mean, sort of the obvious. So the choice was go because, you know, the Go team sat in the next office, and I could go ask them questions and things like that. But it was like, well, I don't I don't wanna, like, I don't wanna transport the entire go run time into ring 0 and kernel contacts. That's gonna be a disaster. And also that's gonna force a particular shape on the design of my system that, you know, may or may not be a good fit for the system.
Speaker 10:And so the only other choice that seemed reasonable at the time was Rust. And I remember looking at it and being like, this is a big ugly language, and I don't like it. But as a small run time and it's easy to get into from assembly language, that's that has real value to me. And so we, we started using it and we were kind of skeptical. And we basically said, well, if we, you know, if this thing will do a quarter of what they promise it will, that'll be useful.
Speaker 10:And it really did exceed our expectations. We grew to like it. It was an interesting experience.
Speaker 1:Well, and I think that there's another element of Rust that I am that I don't I think if I I've I, you know, I wrote a couple of blog entries on, like, as I learn more and more about the language, but I do feel that the ability Rust is its own build system that in that between not just proc macros, but the ability to actually, dynamically change what what is compiled, puts the dynamism out of the run time and into the compile system into the compiler, which is a pretty interesting but it's a big cognitive shift, you know. It's it's one that is doesn't really have a lot of parallel, I don't think.
Speaker 10:Oh, Lisp macros have been doing that for for decades.
Speaker 1:You know, I should But
Speaker 4:you find out about them at runtime.
Speaker 1:You know, I should know better than to actually, I know it all goes back to list. And also clean, I guess, is a big, the there's a clean is a language that apparently is had an outsized influence on on Rust. But the It
Speaker 10:really is interesting to look at the DNA of all the languages that are in discussion here. I mean, like, Scratch has come up a few times. And if you really look at that, it's basically logo just, you know, transported into the pseudo visual environment. And if you look at logo, logo was, again, heavily influenced by list.
Speaker 1:So okay. I feel Dan, did you learn logo? Because actually you actually basic is my first like. I did. Like, logo was actually the first like.
Speaker 1:And I logo did not light a fuse for me at all. I think it's like I just remember, like, it be like, the turtle not knowing how to box. Like, I don't care if you know how to draw a box or not, turtle. I I for me, it was not a good fit, but I think there were others that I don't know. Did you really get lit up by logo?
Speaker 1:No.
Speaker 10:I have so so I I think logo so I I got confused when I was in high school, because people people that I knew that were into computers, and I didn't start getting into computers until I was, like, 15 or something. And people who I knew who seemed like they really knew what they were talking about, they programmed them in basic for the most part, but, like, quick basic under DOS. And people are like, you know, somebody told me, well, you should look at logo. And because I was like a long haired skater kid. They were like, this guy can't possibly understand anything about computers.
Speaker 10:You should go play with logo. And the irony of that is that logo itself is actually a much more capable programming language than basic is, and it never could be. Yeah. And, you know, they had lexical scope. They had all these kind of nifty things that we think of as being part of, like, real programming languages.
Speaker 10:But the only thing that, you know, people ever really were exposed to was the the turtle. Turtle. And what what I think happened there was I I I think that, you know, the 19 eighties, early 19 eighties, microcomputer explosion happens. People are like, oh my god, this is big. We need to teach kids how to use computers.
Speaker 10:All of a sudden, computers are flooding public schools, and public school teachers, most of whom at the time had gone to college in, like, the fifties sixties
Speaker 1:Yep.
Speaker 10:Were basically being told go teach computer programming to, like, 8 year olds. And, like like, these people had no idea what they were doing. They were not computer scientists. They were, like, you know, I teach basic reading, writing, and arithmetic. I mean, that was very much the model in public schools at the time.
Speaker 10:And so I suspect that what happened with logo was that, you know, it was overpromised and underdelivered because of the introduction of the thing was not managed well, and the people who were teaching it were not themselves experts at it. This is why American kids hate mathematics so much. They think math is hard. Not because math is hard. I mean, parts of it, of course, are difficult, But rather because it's not taught well because the people who are teaching it themselves don't understand it necessarily.
Speaker 1:Yeah. That's interesting. And it looks I think that I mean, to contrast and maybe this is what you're saying that, like because Scratch, I actually feel is, I think Scratch is a good first programming language for Scratch, I think, is a good introduction for young kids to learn how to program. I think it's it's very visual, but to me is better than much better than logo. And I think actually better than basic too because it requires you to think in terms of blocks of computation.
Speaker 1:And I I mean, I certainly don't think that, I that we are having mutilated minds because of Scratch. That that would seem, but
Speaker 7:Tetra would be satisfied with how structured it is.
Speaker 1:Yeah. I think Tetra would be satisfied. Well, I mean, I don't think that yeah. Exactly. I wouldn't to be satisfied with anything.
Speaker 1:Although, somebody replied to my tweet being like, man, what would that dude have done with YAML? I mean, it's like, you think I I just don't think Dijkstra could have could have survived. I I think he it it it's best that he passed on because I don't think he could have made it in the in the modern era.
Speaker 10:Wow. Damn, Brian.
Speaker 1:And maybe on that note, maybe on that on that on that I I apologize to the the those still mourning the loss of the of the great Dykes. Although, actually, you know what? I'm gonna end on one other complaint. He's got it there. He said that that anthropomorphizing machines is a sign of professional immaturity or whatever.
Speaker 1:And I'm like
Speaker 2:Oh, I love that line. You're like, we're still immature.
Speaker 1:Well, and also it's like, hey, asshole. How many times have I had to explain what p and V mean to people because of you? You anthropomorphized the system with a fucking railroad and left the rest of us to explain it, that these are, like, terms in Dutch. That look. You you left us with one of our strangest anthropomorphizations in in system software as far as I'm concerned.
Speaker 1:And it's, like, oh, anyway. Maybe maybe that was a maybe that was a sign of regret. I don't know. I I And
Speaker 9:and, Brian, on the note of machine, I know you guys were doing bring up last week. How's it going?
Speaker 1:Yeah. Well, yeah. It's, it's exciting. We, we didn't we blow anything up, which is good. I mean, bring up can go very poorly.
Speaker 1:It's gone well. We've got a we we're making good progress. And while I would say that, I squared c level translators are the devil's own handiwork. I think that the the strangest problem we had was due to a, a level translator that wasn't powered up and was behaving extremely strangely as a result. But, yeah, things have gone things have gone pretty well.
Speaker 1:I will have a lot more to talk about. I would at some point, it would be the thing about bring up is that there are kind of these, these, you know, moments where you're kind of moving on to the next stage where it's kind of like gripped with terror. And then there's a long period of time where you're verifying and backfilling and trying to figure out, you know, reworking and so on. So it's and I but at some point in Oxide's life, we've gotta do, like, a I think it'd be fun to do, like, a live stream of a bring up. So yeah.
Speaker 1:No. It's fine. We're we're having a good time, learning a lot, and not blowing I think we had we we had one power stage that we learned. It was being pushed beyond its its rating. So that thing did blow up, and we we did rework that board, but that board can't quite fly right as a result.
Speaker 1:So that one is never gonna take a socket. That one is oh, it will will forever. The the w in charge of that actually puts superglue on the socket, so that one is never gonna take a socket. I never get to take a c Yeah.
Speaker 9:That'll that that'll do it.
Speaker 1:Yeah. Exactly.
Speaker 9:Do do I squared c level translators ever work even in, like, even when you power them
Speaker 1:properly? Yeah. I yeah. I try to be I I I squared c is really, it it it embodies both, the power and the peril of laxity in engineering. There is a great, it's the ability to to hook up systems that have never spoken to one another and share only 2 wires and have them have a meaningful conversation is kind of amazing at some level.
Speaker 1:And then the fact that it goes horribly wrong is perhaps not as surprising.
Speaker 9:I mean, I squared c is the well defined one of the 2. Then Between yes. I, spy
Speaker 1:for those the the the the serial peripheral interconnect, and, I squared c is the inter, IC, and, I squared c is the inter, IC interconnect. Right? The, inter IC Yes.
Speaker 9:Inter inter inter integrated circuit.
Speaker 1:Inter integrated circuit. You you realize it, like, as you're, like, thinking what the acronym stands for, like, aren't I missing a letter somewhere in there? But the,
Speaker 9:Well, and then then there's then there's I three c, which is the transfer one Right. Which they just incremented that doesn't actually have another I. And
Speaker 1:and one wire, which is, like I actually I'm kind of, like, perversely attracted to, which is just a single wire. But the, I attracted to, which is just a single wire. But the, I ended up writing a bunch of code for it. We're not using that anywhere. But, it was a lot more sorry.
Speaker 1:I didn't mean to This is like, we got to our first language, then you got, like, first bus protocols.
Speaker 4:Oh, actually,
Speaker 1:I do think, like, teaching I squared c. I would teach I squared c I scores, actually, at this point.
Speaker 9:I I did teach I squared c c to probably a 1000 college freshmen.
Speaker 1:Did you how did it go? Because I think it's like I I think it's like pretty neat actually at some level, but it's not terrible.
Speaker 9:Yeah. I mean, you you gotta pick the chips you teach on. Right? You don't start off with, like, you know, some of the really awful ones. But, yeah, it it generally went pretty well, you know, getting people to understand bidirectional buses that are driven and are floating and pulled up and, hey, guys.
Speaker 9:Put the pull ups on your breadboard, and, no, don't put them on both ends and, you know, things like that. It's like on a hardware level that's fairly simple once you get the hang of it. Like, in the context of microcontroller programming where you have, like, a 128 bytes of RAM and everyone's just losing their minds if they took c s one first anyway, it's, you know, it it's appropriate for the context.
Speaker 1:Yeah. I think that would be neat, actually. I I I kinda wanna, I I would like to I think it'd be fun to teach because I think it would be fun to, because you with with the I squared c and spy too. But, like, you are getting much closer to kind of the atomic particles of computing. Of course, it's all analog, which is the other thing that's really terrible.
Speaker 1:It's that, like, just when you think it's, like, you're really getting to, like, the foundation. You realize the foundation is not there at all and you fall through the floor. But
Speaker 9:Well and, like, I squared c is also slow enough that, like, you can put a really cheap oscilloscope on it
Speaker 1:Yes. To
Speaker 9:figure out what you've messed up. And doing that on, like, 100 megahertz QSPY as you're booting an FPGA is not, not not exactly the most human interfaceable, although certainly, something that we've had to do over the years.
Speaker 1:It sounds like you were with us in breakout last week,
Speaker 2:but we are one of the
Speaker 1:first things we do is drop down a bitstream to an FPGA and over spy. And, yeah, that was definitely more of an adventure than Iceberg c for sure.
Speaker 9:Hopefully, that worked well for you.
Speaker 1:I did, actually.
Speaker 4:And you made it. Yeah.
Speaker 1:So, honestly, honestly, god bless the ice 40 and Claire Wolf, who reverse engineered the ice 40. The open FPGA ecosystem is great. So, yeah, we're we've got a Oh,
Speaker 9:so so so you guys are all open FPGA, ICE 40?
Speaker 1:Yep. The We are I even though Lattice is a little bit like I don't think we try to explain to Lattice why this is so important. They kinda don't get it. But, yes,
Speaker 9:we are. I have I have also tried to explain to Lattice why this is so important, and they've maybe listened a little bit more, Perks of Not Being Such an Open Company. But, like, yeah, I'm not sure they're gonna do anything about it.
Speaker 1:Yeah. And just to tease that a little bit. So we actually did we the open source from our conference, Tom, you remember that that we were that was like one of the Tom, that is the last conference I was physically at, was the Open Source Firmware Conference with you in 2019. 2019. I mean, 19?
Speaker 1:The Open Source Firmware Conference is coming up at the end of November and we will be open sourcing our operating system before we're gonna have a talk on that at the open source firmware conference, and we'll be open sourcing through this before then. So you get a chance to see everything we're doing, including the the blue spec and everything else that we're actually, dropping down onto that FPGA. What is I think
Speaker 9:using that as what? Your BMC, I assume?
Speaker 1:Yeah. That's so we don't have a BMC. We've got a service processor. But, yeah, that's our for we're running Hubris on our our service processor, and that FPGA is the actual the sequencer, the actual, the the power sequencer. Because you can't just turn things on.
Speaker 1:I mean, I know that for those of you who are who have who have not had to deal with the innards of hardware, stuff that's powered off is actually in in in a somewhat undefined state if you've got power on the board. So, it's actually, it's actually very challenging to power things on. Anyway, you know so, yes, we're gonna be up What do you do?
Speaker 11:My first one of my first embedded projects was soldering a transistor across the power button for my laptop and turned it into a server that I could remotely turn on because I had a There
Speaker 1:you go. Bring it in. So we'll have a lot more to say about that. And, yeah, maybe we should do we we should maybe do a a Twitter space on What is the i40? What is the ICE 40?
Speaker 9:Yes.
Speaker 1:The ICE 40 is an FPGA, that is now, made by by Lattice. And the ICE 40 is interesting because it was reverse engineered by Claire Wolf, and she figured out the bitstream format. And then there are, a bunch of open source tools that can generate bitstreams for it. So the bitstream is what you download onto the FPGA that tells it what to do. And most for Xilinx and for the for the other, for Alterra and so on, they are generally proprietary.
Speaker 1:So you have to use their tooling. And there are I am both I on the one hand, I I disagree with proprietary software for lots of reasons, but I also really don't like bad software. The software generally has, lots of challenges associated with it. So, FPGA, open FPGAs, like, the the ice forties, have been have been huge for us.
Speaker 9:Yeah. I was I was wondering for a while going? Right. I was wondering for a while how you guys were gonna manage to intersect openness with FPGA and
Speaker 1:There you go. You know?
Speaker 9:There you go. Yep.
Speaker 11:Can you deploy bit streams from Hubris to
Speaker 1:Yeah. We yeah. That's exactly what we're doing. So we've got the the bit stream is effectively the bit stream for the sequencer is in the image. So when that thing, it's a bit of an open question.
Speaker 1:What is the actual first instruction to be executed? Because there are even in our system, there are still instructions that we can't see on some of these individual components. Like the the IBC for sure has instructions that we can't see. But the SP is the first thing that executes instructions that we can see. It downloads a, a bit stream that contains the, the the sequencer to the FPGA, and then it begins to talk to the FPGA.
Speaker 1:And the, the bug that we had that I'm alluding to is that when that FPGA was tri stated, the SP could see its I squared c buses. And then when the FPGA powered on, all of a sudden, the SP could not see 2 of its s squared c buses because what had actually happened is that we were now not giving power to a level translator that was giving us absolute bonkers stuff to the SP. So it was it did and and then we were with the, you know, tales of bring up, The we were, that that was made much more difficult to debug because we only saw that on one board. Two boards didn't see that. And when you're in a bring up lab where every board is unfortunately a little bit different, every board has got a different level of rework associated with it.
Speaker 1:When one board sees something that the other 2 boards don't see, your first thought is no. Oh, I'm seeing parasitic capacitance and, you know, I've got a level translator that's misbehaving or what have you. You your first thought is, like, one of the the rework has done some somehow the rework has damaged this board in such such a way that this FPGA is interfering with I squared c bus and it's not on. And, yeah. That was that was, felt like 20 hours, but was only about 2 and a half hours of total confusion about what was going on.
Speaker 1:So, Matt, how's that for a, a summary from the Bring Up Lab?
Speaker 9:Yeah. Sounds good.
Speaker 1:We're,
Speaker 9:Glad to know that you guys are, you know, go everything's going well, and, you know, best of luck for all your rest that you bring up.
Speaker 1:Yeah. Thanks. Yeah. We're we're we're getting there. We're having fun.
Speaker 1:And the good news is that all the components, everything at this point has has powered up. We've got power. We've got we've we've used the the tooling to verify that the rails are up properly. So we're getting there.
Speaker 9:And and you guys you guys have sockets now?
Speaker 1:Or
Speaker 9:we have nobody's quite brave enough put
Speaker 1:that in. The the the that's next. So that's where we're the time to actually, the, AMD makes actually a great tool, that allows you to do a lot of, you can do all of your power verification before actually the reason you wanna be hesitant on a socket is because you actually blow apart. And so we are that's basically where we are right now is is advancing to that stage because we believe throwing out dead CPUs, which is important.
Speaker 9:Can can I just say how jealous I am of, like, $1,000 chip and cost you Like, $1,000 chip and cost you
Speaker 1:a possession. Like Okay. So if you we should do I I I know we're we've we've run way long now, so we should wrap it up. But I we should do Matt, we should I I think we need to do a Twitter space on tales from the bring up lab because I would love to hear some of those stories. I'm sure you've got some stories of, and there was a moment where I thought the engineer next to me had just blown the board.
Speaker 1:And he thought it everyone around him thought we just blown the board. But also, and just he was so calm about just, like, just reaching over for his meter and beginning to check his, As it turns out, like, the thing had he had not blown it at all. It had just, it had done what it should do, and we were, we were able to the board was fine. But I was crapping my pants, and the, you know, because you can you can actually, like, damage stuff, which, you know, I I I definitely if there's something to damage, I damage it. So, this is why I don't touch these links.
Speaker 1:Yeah. I know. The the, Adam is laughing at the many mishaps that he is, I'm sure, thinking of over the years that I've
Speaker 2:That's that could be an episode.
Speaker 1:That could be. Alright. Alright. We got a we got a bunch for the future then. Alright.
Speaker 1:But on that note, Adam, any any final thoughts? Yeah? What are your opinions about Haskell? About what? Haskell, the programming language.
Speaker 1:Haskell. Oh, Haskell. You that's funny. You the, yeah, Haskell hasn't really come up. I, honor a language for me personally, but I think a lot of what I like about Rust has some orgs to Haskell.
Speaker 1:So I'm pro Haskell in that regard. Adam, you've you've done Haskell?
Speaker 2:Never. But, it's it's, on the list. And I and I just wanted to get in here before we wrap it up that I really like your approach to finding these topics, Brian, which is to tweet a bunch of stuff for the work week and whatever whatever hits. That's the thing we talk about, I think it's kind of genius.
Speaker 1:Yeah. You're assuming there's a method to the madness, but yeah. At least there's some madness. There's some there's some madness. Alright.
Speaker 1:On that note, thanks, everybody. See you next time.
Speaker 2:Thanks, everyone.
Creators and Guests
