Hey, welcome back to Programmer Story Hour with Uncle Bob or JavaScript Jabber as we call it every week.
This week on our panel, we have a j O'Neal.
Yo yah yoh, come that you live.
From the now with plywood paneling shed or like I said, a drywall. I got someplywood from a friend who is dumping it nice.
We also have Dan Shapere.
Hello from Tel Aviv.
I'm Charles max Wood from Top End Devs. And this week we have a special guest. As I said before, we got Uncle Bob here. So Bob, welcome back.
Thank you so much. Good to be back.
So I was going to ask you what's new, but I have to say Pearson reached out to me about reviewing Clean Code, a new edition of Clean Code, So it looks like that's going to be a thing.
Yeah. I'm in the midst of the final reviews of that now, so it should be going into production within another month. And then you know that that process takes about three or four months. So even cleaner Code end of the year, what's that?
Even cleaner Code, we can only pray.
Clean Code second Edition. I tried to play with other titles, but the publisher was very adamant be Clean Code second edition.
I think it's easier to sell if you keep the title.
It's you know, yeah, we're not supposed to. That's that's not the topic of our conversation. But I've got to ask. I mean, the Clean Code principles seem pretty kind of universal, almost, so why do we need a second edition?
Oh heavens, I did say, story our go for it, Bob.
For the longest time, I thought, you know, I'm done. I don't. I've never done a second edition of anything. Usually when I write something, I think, Okay, I said it, I don't need to say it again. And for the longest time I thought that would be the case with
Clean Code. But the Clean Code became so controversial. There were so many misinterpretations and misrepresentations and you know, errors on my part where I said things that could be taken in the wrong way that I thought, you know, maybe it's time to dust that thing off and see if there isn't something I would say differently. And then as I was doing that, I thought, you know, there's all this new stuff, there's all this AI stuff. There's always you know, co Pilot and rock and all that stuff.
How does that play in. And besides that, there's languages.
That I should probably explore, like go and and I thought, okay, fine, let's let's do a top to bottom rewrite, incorporating some of the original chapters with a lot of change and just a whole new bunch of new chapters.
The overall message is, of course the same, but the way I say it in the examples that I pose and some of the nuances have shifted a rather significant amount, so I'm happy with it. I also decided to add a whole bunch of other stuff, like design principles and design patterns. It's kind of like, Okay, everything I've learned over the last ten years, let's kind of funnel it into this book and see what happens. So that's why
there is a second edition. Not least of all of that is that my publisher said, you know, you should write a second edition. I thought, okay, probably a good idea.
You mentioned the fact that you cover new program additional programming languages in the new edition. I'm curious in that context, how to what extent does the choice of the programming language impact the meaning, I guess or the consequence of the code being clean, Like would you apply the same principles in order to achieve clean code in different programming languages.
And that is one of the points of the second edition, which is that the programming language doesn't matter much at all. I'm going to show you an example in Python. I'm going to show you an example in Ruby. I'll do an enclosure. I'll do one in Java. An NC doesn't seem to make an awful lot of difference. There are little quibbles that you can make. Some languages want the order of the functions inverted. You know, if you're working
in Python or if you're working in closure. They want low level things stated before high level things I whereas in Java you can turn it around in a way that makes more sense. But o are all the message of the book applies to all of those languages, and and in the second edition I tried to demonstrate that by just changing language from chapter to chapter to chapter.
Yeah, I remember, with the help of co.
Pilot, by the way, because I'm not a Python programmer, so I fire up co pilot and I get a lot of help. It was, it was It was pretty interesting to watch these ais throw a code at me that I could review and then think you know that's maybe not so bad or in more cases like I think I could do better.
Very cool. We're looking forward to that coming out.
One thing that I hear is like the number one criticism that I hear, and I think this is not accurate, but I want to know. People say, oh, or you could do it Uncle Bob style and only have three or four lines in a function. Is that is that true? Or is that just like a misquote or a a perversion of something you said? Like I know that a
lot of demo code examples to do apps whatever. Yeah, like you end up you know, if you were going to enterprise it, and yeah, then you're gonna end up with a bunch of things that are three or four lines long, don't do anything meaningful. But what what is your actual advice on function size or grouping of logic?
Actual? My actual advice there is to keep it very small. I like small functions, and you know how small, well, three four or five, six, seven lines something in that range. I don't like to see twenty lines. I don't like to see thirty. The the controversy is, you know, two to three lines. So bun Kebob says, everything's got to be two to three or three to four or whatever number they quote. And that's an example of people who did not read the book.
In that context. Though some programming languages are more condensed than others. Yes, you know, I know that you like closure. Closure is pretty dense. So three lines of Closure could probably achieve a lot more than three lines of Java. Three lines of Java. Two of those lines are open, open curlies, and close curlies, so you're basically left with one line that is Java.
Certainly true, It is certainly true that that Closure is much denser than Java, and yet it is much harder in closure to make small functions. And that's just because of the functional style and the fact that you need to set a bunch of variables up front and then and then operate them at a lower place, and it's
very hard to separate those things out as independent functions. So, just just a quirk of the language, you end up with larger functions inclosure, even though those even though the language is denser.
So do you have like a general rule of how to determine what belongs together? Because I think line limit to me, to me personally, I don't think line limit makes a lot of sense because the line limit is arbitrary. Like for me, I don't like to use comments. I
put everything in a variable. So if I'm going to do a mathematical operation where I'm gonna, you know, add days of the week and multiply by hours or whatever, I'll actually write that out line by line, so that instead of commenting this is taking this to make that because this number is special, I'll just var special number equals you know, and and that way that the variables
declare themselves. So a function that somebody else would have that would be or a operation like I break statements down right, so don't I don't necessarily find line numbers in of themselves to be meaningful. Other than that, you've got to be able to see it on a page, Like when you're looking at a block of code, generally you should be able to see the whole block of code.
If it extends beyond what you can easily see, or you have to make your font size really small, then you know it's too much context in the brain.
I've got these I don't make my font size too small.
Yeah.
But on the other hand, and I think that there's the general case versus the exceptional case and this might be the exceptional case. But if it's like a parser, I often find that my functions are way longer, longer than I like them to be, because it's like, well, one unit of logic for parsing, this thing is just this much logic or transforming if it's like a parser or a transformer.
Yeah, yeah, So the line limit is always the way to look at it. It's because it's not a line limit that you're really going for. And in the book, and in the new book especially, I write a whole chapter about this in the new book. But in the old book, the rule was a function should do one thing, and how do you know that it's doing one thing?
How do you remove the.
Objective or the subjective idea of what one thing is? And my answer to that is is that if you can use the extract method refactoring inside a function to pull another function out of it, you probably should, and then give that function a nice name, and those two functions will then do one thing. If you can take one function and split it in two with extract method, then you then that then probably you should, and those two functions will be smaller. Of course, they'll both have nice names.
That's that's if you don't know what to name your function. If your function name is dou stuff, you definitely need to break your function down.
I literally want had to refactor code that had in it one through in it ten oh jee.
Yeah, but that's useful. But they kept the line rule.
The thing that we're kind of circling around here, at least the way that I approach it is I like everything at the same abstraction level.
For one.
Yeah, so that's one rule that I follow, right, And so if I can say this takes these steps A, D, C, D E, F right, and I can you know, I can name the steps, then then that's usually what my function looks like, right, or my method or whatever. And then and then I have those somewhere else, right, And so then and then those break down the same way.
They're just the next layer of abstraction.
But then the other thing is is that if typically if I have some big long function like AJ's talking about with like a parser, usually there are different stages or steps or functionalities in there that I need to go through, and so I can break all that out too. And so in a lot of cases, I don't typically find very many cases in any language that I've written, where I don't wind up with just some somewhat shorter method. The only time it gets particularly long is if you
have a case statement. And I hate case statements because it adds the line every other time. If if the case case, then do this case, then do this case, than do this or if els if elsif else if elsif which is also gross.
But beyond that. Yeah, typically you can break it out into.
Multiple I prefer and direction over ifs and and switches. By the way, we have a question from the audience closure from Venicius. I think I'm pronouncing his name correctly. I hope closure developers value recursion more than any other How does recursion impact clean code? Well, I think that closure developers don't have a choice except to use recursion if they want to have to make to create loops.
You know, one of the people you didn't talk about in your book, or a few people were Church And also I forget the name of the two guys that created lisp.
Oh, yeah, we're here to talk about we programmers.
Go go ahead and answer this question, Bob, and then we'll move on and move on to story hour.
Well, I mean, I mean Dan is right. If you're going to use the functional language, you have no choice but to use recursion. Recursion is a the only way you can do loops in a in a functional language. How does it impact clean code? It doesn't. Good. Good expressive code can be expressed either with iterative loops or with recursion, so there's no real impact there at all.
The impact that closure brings to the rules of clean code is that the act of creating intermediate variables is very difficult to extract out into other functions because in closure, when you create an intermediate variable, it is in the scope of your function, and there's no way to get it out without doing some nasty trick like creating an atom or something. And okay, probably don't want to do that too.
Often because you don't want side effects, all right right now.
I mean, you can manage those side effects by creating an atom and then making sure you don't overwrite the data that you stick in there. So in that sense, you probably could pull out those functions. And I've played with that technique a few times, but it's always ugly. So then I wind up with functions that are fifteen lines long, and I look at them and go boy, I wish I could pull lice things apart, but there's no real good way so far, enclosure that I have accepted.
Also, at the end of the day, it's not about achieving, like you said, it's not about achieving some magic number. It's trying to make your I guess it would be try to make your functions as short as possible, but no shorter.
Well, yeah, given the constraints of the language.
And it's not easy either.
Any people kind of conflate length and complexity or length and difficulty, and you know it can and can't sometimes. But was it Mark Twain that said I didn't have time to write you a short letter, so I wrote you a long one.
It was Voltaire, it was somebody important.
But the point is is that it takes a lot of time to get right, to really get things that they're in the right place, so that you have something like that that's easy to put together in your head. Anyway, let's get into we program I think we did this last time when we were talking about your your other project, where we went off on we programmers for about twenty minutes and then it's like, we're here to talk about this other thing. So which is great because it makes
it fun to talk about. But yeah, so I'm kind of curious as we get in, what's your favorite part or story or whatever of the book, and can you kind of give us a little bit of the story there.
My favorite story in there, well, there's a lot of a lot of stories that I really like, but my favorite story in there might be the story of John Bacchus, because here's a guy who was a complete and air did well. It didn't have a great family life growing up, kind of dumped on school, didn't care about school because he's too damn smart, right, and you know, everybody knows that kid. It was so damn smart that they didn't even he didn't even try, right. School was just so
damn boring. The hell with it, and he got drafted towards the end of World War two. Fortunately right at the right time. He got drafted, and the army saw this, this ne'er do well kid, and ran him through an aptitude test and it blew their socks off, and so they said, you need to become an engineer, and they put him into engineering school. Well that was too boring for him. He did extremely well, of course, but it was too boring for him, and he just spent his
time at nightclubs and stuff like that. And the army goes this right at the end of World War Two, right, so the army says, you know, this guy's so damn smart. They put him into medical school. He could become a doctor. And that was a bit more challenging, and Bacchus kind of enjoyed it, but kind of didn't. And then all of a sudden, the world was over and he had he was out of the army and he just dropped out of the school and said, yeah, the hell with that.
And he he built himself a nice little Wi Fi system.
Oh, by the way, that's not Wi Fi Hi Fi back in the you know, in the fifties, nice sound system for his record player. Still only half of the people in the world know what I'm talking about. He built that, and he dabbled around a little bit and really didn't get any jobs. And then a friend of his said, you know, you should see this really cool thing that's down in one of the streets of New York City at the IBM building. And he goes wandering over there and he looks in the window and and
the at the IBM building. Thomas J. Watson, the guy who founded IBM, had put in the display window the world's second computer, big computer, right, the selective I can't remember the name of it. This gigantic machine, mostly electro mechanical, couple of vacuum tubes, paper tape everywhere. This massive machine fills the room. It's got this really cool front panel, you know, a Star Trek front panel. Lights are blinking. If you go inside, it's clicking away like crazy. And
Bacchus goes, oh, yeah, that's kind of cool. And he asks for a tour, and the person giving him a tour I think must have smelled something. I mean, Bacchus was in a very informal garb shall we say, but must have smelled something about Bacchus's intelligence, because the tour guide brought him up to the department head, and the department head gave him an aptitude test and hired him on the spot, and he became the project leader of the Fortran project that gave us the Fortran language way
back in the fifties. That's that is one of the most interesting intellectual rags to intellectual riches stories in the book. It's a guy that you would never expect to do well at anything and winds up delivering this wonderful thing to the world at that time.
So I have to ask, I mean, it's the book. I've not read it, but I've read excerpts. I've not read it yet. That's put it this way, but I've read excerpts. And I also saw some of the stuff that you put out, and there are a huge no, there's a large number of amazing characters and crazy stories about them. How did you decide who to put in and leave out? And how did you get all the information about the ones that I decided to put in.
It's how did I decide who to leave in and who to leave out? Old Bob Seeger song right. There were a few that were obvious that I had to put in. I had to put Babbage in because the book wouldn't even start properly without Babbage. And you have to put Grace Hopper because she was kind of like the first And if you're not talking about touring, you're not writing a book about software history. So you've got to have touring. And if you bring in touring, you
have to talk about the math. Dave the Hilbert Albert. Thank you. I knew it starting with an H. You have to talk about David Hilbert, and you have to talk about John von Neuman. So those were kind of obvious. That's an obvious progression. And then you know, why wouldn't you talk about the three authors of C Why wouldn't you talk about Dennis Ritchie and Ken Thompson and Brian Kernahan. In fact, you're gonna want to end with that one
because that's kind of where modern history begins. Yeah, and then in the midst of all that, there are these milestones, and most of those milestones I just uncovered by accident, like the whole story of John Kemeny, the father of Basic. What an interesting story that was. No, everybody knows Basic, hardly anybody knows the.
You're making a You're making an assumption that's based on our age. Well, I have to tell you that I speak with the developers that I work with these days, and you know, sometimes the topic of the first what's your first programming language? Comes up and I say Basic and they say, what ye like people today? People today don't know about Basic. I mean, you know, maybe they do because of Microsoft. You know, stuff like VBA. But other than that, they probably don't know what basic is.
And you know what, that's not such a bad thing. Basic almost spoiled me as a programmer.
Oh well, you know you didn't write Cobaal then, because that would have spoiled you as a programmer. Spoiled me as a programmer for a day or two.
Well, you know the story about Ellen Kay and Grace Hopper.
Please please tell me the story.
Well, I recall reading it somewhere that he was walking around the university. I guess it would be Stanford. I think I may be wrong. Maybe it was Berkeley. I don't recall where he taught, But anyway, he sees a group of people and he walks over and it's because Grace Hopper was there and they were like showing her around. And the story is that they introduced them and they said, this is Grace Hopper. She created Cobal, And he said, oh, I'm sorry.
Yeah, I am not kind to Cobal in my book. I'm very kind to Grace Hopper because I think I think she was a remarkable person. But oh yeah, for sure, God, I hated Cobol. I spent about three months writing Cobal when I was nineteen years old. It was not a fun time for me. So I've walked away from that language and never looked back.
Remember what happened when COVID hit?
I thought you were going to go for y two K. So know what happened when COVID hit?
I still remember. I think it was the governor of New Jersey or something saying that our systems can keep up and we were in dire need of cobalt programmers.
Yeah, I've actually heard that, since there's a lot of people talking about these things are all rich and in cobalt.
Okay, Well, it's like any other project that I've worked on. We don't actually update it until it's breaking.
I think some of these are long past that point.
Well look, yeah, but they can patch it over and yeah.
Yeah, Well she also invented the term bug, as I recall.
Yeah, well, I don't know if that she invented it, but in her notebook there is a desiccated moth that she pulled out of the relays in the Harvard Mark one, and in the notebook it says, this is the bug we found in the machine. So I believe the term actually came from telephony, maybe even fifty years before that, but she put it in a software notebook, so we can credit her with that. She was, however, responsible for creating the glossary of terms, one of the earliest glossary
of terms in our industry. So she coined things like register and bit and breakpoint and a bunch of other words like that that we all know and love today.
So again, how did you go about the research?
I have got like a zillion books, and so it's all secondary research, you know, I didn't do any primary research. In some sense, you could look at we Programmers bring a book out We Programmers, you can look at that book as a literature review. Because I read really significant books about Babbage and about Grace Hopper and about all these guys, right, and then I tried to condense them
down and pull out two things. I wanted to pull out the human side of the story, so that programmers who read this could I identify the character flaws that they see in themselves, and these people are replete with character flaws. And then I also wanted to pull out the deep technology. That's something that most of these books do not go into. So I had to do that research myself. So when they're talking about when they're talking about the Univak one, they don't really go into much detail.
So I've got to pull all that information out and then describe, Okay, programmers, this is what a Univak one was like, this is how you programmed it. I actually put some Univac one code in there, and I talk about the kind of code that Grace Hopper had to write in the late forties and early fifties to get the Harvard Mark one to works. I wanted the programmers who read this book not only to identify with the human side of these guys, but also to identify with
the deep technical problems that they were solving. So there's this really interesting juxtaposition. I think it's interesting anyway, interesting juxtaposition of these these frail human people dealing with really difficult technical problems.
I'd like you to go into more depth on one of these. You know, you mentioned like maybe the Univac or something else where. You know, it's just something that we don't even fathom that they had to just figure out.
Well, start with, start with the Harvard Mark one. This was a machine that was built by Harold. Harold Aken kind of conceived of it in the name he was a Navy guy, sort of popcorn. He talked to the Navy into building the thing. He actually talked to IBM into building the thing, and then didn't give them any credit for it, which was a real problem for him later on. But his idea was to create this calculator that could add some subtract, multiplan divide numbers that had
twenty three digits. I think that was the numbers. These numbers had twenty three digits decimal. Nope, no, this wasn't binary.
And the digits were all held in these counter registers, and the counter registers could be addressed and moved into arithmetic units that could add I think it could add three numbers per second if I remember correctly, and it could multiply, and it could multiply in something under ten seconds, so fast by the day, fast by the standards of the day, but impossibly slow from our point of view.
This machine was programmed by punching holes in a twenty four channel paper tape, and the twenty four channels were broken up into eight zones, and the zones were the register. You want to take the data from the register, You're going to put the data in, and the operation you're going to perform on it. And those eight channels were
all binary, sort of sort of binary. The programmers programmed this by identifying what holes should have to be punched in that paper tape, and they did that numerically, so they would write their code as four three, six, I think I got that right, and four men punched the fourth hole in zone one, punched the three hole in
zone two, punched the sixth hole in zone three. That's how they would write their code, and if more than one hole had to be punched, they would write two numbers in that zone area and then they would come up with this program that was line by line by line, just these numbers, these three component numbers and graces. Looking at this, she was like the third programmer in there and was immediately turned into the lead. She took over the whole thing. Had never seen a computer before in
her life, had no idea what these machines were. Aiken threw her into the task and said, okay, for your first job, you have to compute the arctangent coefficients to twenty three decimal places, the interpolation coefficients for doing arc tangents in twenty three decimal places, which took her a week, and she had to figure out how the machine worked and how to bunch the holes, and of course she couldn't.
She didn't have dedicated time on the machine, so she had to steal the time when the other guys weren't as busy as they usually are, and she managed to get that all done. And she worked all this out, and she realized, and by the way, this is where the word code came from, because they were writing codes. It was these numbers, so they called it codes, the computer codes. And she was one of the first person people to say, well, each line, want to have a
comment on it. So on the coding sheets that they had produced mimeograph machine and they would, you know, crank out and produce these coding sheets. She put in a column for comments. First person to ever do anything like that. They began to learn as they were writing the programs for this thing, and the kinds of programs they were writing were ballistic trajectories for artillery shells and the timings
of tides in various places, very deep mathematical problems. And as they did one after the next after the next, they started realizing that they were writing some of the same codes over and over again. And so they would take these little snippets that would do something, some task, some small mathematical task, and they would write them into their notebooks. And they called these transcriptions in their notebooks subroutines. That was their name for them. And then they would
share this back and forth. They would share their notebooks back and forth, and eventually created a library of subroutines, which were just these handwritten documents in a notebook style, and whenever they wanted to use one, they would go to the notebook, they'd look it up, and then they would transcribe manually those codes into their program. Of course, the register numbers had to change, because in one case you might be using register three, in another case you
might be using register eight. And so when they wrote these in their book, they used the convention that all registers were zero or based on zero. So they invented relocatable programming just out of sheer raw need. Eventually, the programmers would write the numbers, but they would hire people to do the punching, and then the tape, the long tape, and these tapes got pretty long. The long tape would go back to the programmers and the programmers would verify
the holes against the code that they had written. Man there was no jump instruction. There was no way to do a loop unless you put the ends of the tape together and then you could have a loop, and they actually did do that. I'm not sure that's where the word loop came from, but they did make loops of tape. But usually what happened was that there was a halt instruction. There was an instruction that would stop
the machine, and then on the tape itself. The tape was fairly wide, twenty four channels right, so on the tape itself they would write instructions to the operator. If registered three is less than twenty eight, then go to and there would be a mark on the tape where they would back the tape up to and run it again. So all of the loops, all of the transfers of
control were manual. They couldn't be done automatically, which meant that the operators were always on call, always watching the machine, always repositioning the tape to try and get any kind of iterative process done correctly. That's just a glimpse of the horrors of the earliest of programming jobs.
One of my favorite characters that you also talk about, and I actually learned about him from reading the book about the Manhattan Project when I was a kid, is John von Neumann, who was an amazing intellect and persons give like you know, you watch a TV series like The Big Back Theory and everybody kind of amazed by the capabilities of the sheldn character. Well, think about somebody like that, only doubled, but also highly social. He was well known for his parties. So there's so, for example,
there's this famous story about him. He basically had what a photograph you don't say, photographic memory? How do you call it these days?
Photograph?
You know, dadic Anyway, so a friend of a friend of his, you know, tells a story where, you know, he claimed to have this amazing memory. So to test him out, he asked them to recite the chapters of Between Two Cities, which he read like when he was a youth. And he basically started reciting it, and he asked him to stop after something like ten or fifteen minutes.
I have seen that story reproduced a few times in slightly different contexts, but I think it's really clear that John von Newman may have been the smartest person ever to have been born and easily comparable to somebody like Einstein or James Clerk Maxwell or someone like that. He had this uncanny ability to switch disciplines and still be an expert. So he was deeply involved with quantum mechanics in the early days. He was deeply involved with the
Manhattan Project. He was the only person on the Manhattan Project who was allowed to leave and come back, and leave and come back at will. He could go anywhere he needed to go because all the other parts of the military needed his advice. He was deeply involved with ballistics. He was deeply involved with the shock waves of explosions. He was he was running the computers at Manhattan on
the Manhattan Project. He went out and looked at other ways of doing the computations, didn't find a good one, still stuck with the IBM punch card approach, but managed to get the initial h the initial models of the implosion of the of the plutonium corps to work. The guy was just a remarkable guy and and lucky as hell until the end of his life. Lucky as hell because he managed to leave Germany a year before it
became impossible to leave Germany. He joined the Princeton Institute. Right, he was the guy who brought a lot of other guys over from Germany, saying, hey, you know it's nice over here in the US. You could come to Princeton. Oh, Einstein, come on over here. You know, people like that. So he was a massive recruiter. And like you said, it's it's unusual to find a guy who is supreme intellect, who has supreme intellect and yet really good social skills,
and he did. He was a social animal, so very kind of like like fine, yes, a lot like Fineman.
The funny thing about him you talked about how some of these characters were kind of flawed, was that while he was such a great, amazing person and made so many contributions, he was also wrecked with self doubt. And he was like he felt that he did not he that he hadn't achieved as much as his colleagues.
What's the name of that syndrome. There's a it's that's got a name. I can't remember what the name of it.
Imposter syndrome, kind of.
The other way around. Right, It's like.
He basically thought you done enough? Right, Yeah, he thought that he would, like you know, obviously everybody knew what I Einstein would be remembered for, and everybody and they knew what Hilbert would be remembered for. And he thought that he would not be remembered.
Well he was remembered and fondly.
Yeah.
He was one of the inventors of Monte Carlo, the Monte Carlo method, and the story there is fascinating. They were trying to figure out, you know, how how to model the the diffusion of neutrons through a platon plutonium core. How do you model it? How do you calculate that? And his buddy, whose name escapes me at the moment, his buddy sat down and said, well, how would you determine the probability of winning at solitaire? Now you could do that mathematically, or you could play one hundred games
and count the number of ones that you won. And that was the beginning of Monte Carlo analysis, which plays a huge role in the rest of the book. It drives the whole notion of Monte Carlo analysis, drives nuclear physics for a good long time, but it also drives the creation of object oriented programming. It was Christian Nygard's thing. He was a Monte Carlo analyst, and because of that he started thinking about simulation and how to do simulation well.
And of course then you bring in computers and he wanted to create these the Monte Carlo compiler, and he recruited he recruited his buddy Ola Johan Dal and wrote this thing that they initially called the Monte Carlo Compiler and eventually became called Simula. And in the midst of all that they literally invented objectoried program.
And in the context of JavaScript, because it's a JavaScript Java, I think Java JavaScript borrows from self and as I recalled, self borrows from Simula.
Yeah, well, there's there's there's definitely something too that. The story that I have heard, and I don't know that this is absolutely correct, but the story I've heard about JavaScript is that it was it was brendan Ike's task to create a language that would run in the browser. This is back in the Netscape days, the Mozilla days, and he wanted to make it Lisp, but he didn't have time, and there was self there and he kind of borrowed from that and cobbled together this thing called JavaScript.
That may be an urban legend. I think I've seen that once or twice in various threads on the web. I don't know if that's true at all, but I think it's funny.
If you want to hear the full deal from the horse's mouth, we have an episode where.
Oh with brendan Ike Oh beautiful.
I also conversed with him about this online, even though I wasn't yet with the podcast when you recorded that episode with him. It's first of all, it's not exactly that he was toying with the concept, with the possibility of putting scheme in a browser, but it never really matured. And yes, he did create and implement JavaScript in ten days, which are fondly known in the community is the ten Days of Glory. But he said that JavaScript in a lot of ways is more influenced by ARC than it
is by scheme. For those of you don't know, is kind of like Pearl. It's a language for text processing.
Ah, somebody in Kernahan.
Correct, who's the W I forget. It's one of those member Unix utilities that you you can pipe stuff in and pipe stuff out.
Predecessor of Pearl, Yeah, exactly, predecessor of Ruby.
This is cool actually.
Away, By the way, the very first wiki ever put on on on the Internet was a couple one hundred lines of pearl written by Word Cunningham in the very late nineties, just you.
Know, well CGI scripts. You know, people don't remember the origins of the web, but the initial web servers were mostly done in pearl because people didn't want to do all that text processing in.
C Yeah, so I have another question. I'm going to change this topic a little bit because you know, we talked about how computers were initially kind of these calculating machines. And if you go watch like the Hidden Figures movie, right, they have these women that are called computers and right, and their job was to do the math right, and then they got this fancy computer that would do the math right, and so then they were programming the computer.
But when when did computers kind of go from this math machine to this sort of general purpose machine that we kind of think of as a computer today.
That's a really interesting question, and there's two ways to look at that. You could look at it from a from the practical point of view, When did computers start doing more than just math? When did they really start doing more than just math? And the guy who comes to mind there is Dykstra, because dystro is the guy who was playing with graph theory. He hey came up this clever way of computing the the best route to go from one city in Norway to another, something like that,
and it was a demonstration. He wanted to show it, show this demonstration to his superiors, and he came up with this algorithm to do that. And that's a very different kind of problem than computing the implosion wave in a plutonium core, so that was a more practical one. So from that point of view, you could lay this at Dykster's door, and that would have been late fifties, maybe the early sixties, but probably the late probably the
mid fifties actually. But it was Babbage, in his con his contemplations of his analytical engine, the thing that never got built, right, who started toying around with the idea that this machine that he had in his mind that had a thousand registers and a mill that could add, subtract, multiply, and divide, and an electro mechanical no excuse me, a mechanical bus that could move numbers from registers to the mill and back again, right, and was programmable by punched
pieces of wood. You know, Jakrde loom style, right, these big chunks of wood with holes drilled, and was how you would punish them and give it or that's how you'd program them, punish them good word bout that's how you would programmed them. And in the midst of just thinking about this Machie Babbage starts realizing that you could write a program for this machine that could play chess.
He started working that out. So in that sense, Babbage is the first guy to cross that boundary to get out of the mathematical world and into the symbolic abstract world. And he had a number of other ideas like that. He actually put together a machine that could play tic tactout. He actually built that one knots and crosses. Although you know, simple machine to build, still he was he was probably the guy that first had that concept.
That's amazing. I didn't consider that. There are several people that you decided not to include in your book.
Uh.
Few that come to mind are Donald Kanouth or or Church. You know, if we're looking more recently, maybe somebody like Linus Travaldi's. So how did you decide to leave certain people out?
Those are not conscious decisions. I did not have a list of people to leave out. What I did have was a hard cut off day. I wanted to. I wanted it to be a history book about other people right through the late sixties into the early seventies, and then from that point, that's where part two of the book begins. Then it starts to become autobiographical. From that point on, I can relate what was happening in the
industry as an eyewitness, as a participant. So I shifted years entirely and just started talking about my experiences through the next thirty years, thirty or forty whatever it is, some number of years, and I described the industry from a from an insider's point of view at that point. So the hard cut off date was one of the reasons that you can't put that I didn't put Linus in there. For example, people have complained a lot that I should have put Margaret Hamilton in there, right, and
I would have loved to. I actually bought a whole bunch of books on the Apollo program to read about that, but it turns out there's not a lot written deeply about the stories there, or if there is, I missed them. So you know, I went to look for that, but didn't find it. Limited amount of time. I thought, okay, I can probably skip that one. There's a number of other people that I should have written about if i'd had the space, Like John McCarthy, I would have loved
to have told an in depth story of Lisp. That would have been a great story to tell. Just you know, ran out of time, ran out of materials.
And the Mother of Old demos, I'm sorry, Engelbert and the Mother of All demos.
That's a story I don't know.
Check out the video for the Mother of All demos. Basically, it's you can find it on YouTube. Let me do a quick search.
Demos sounds good.
Yeah, it's still considered to be the greatest demo of all time.
It's like, I see a couple of them here. When of them was like an hour and forty minutes.
Yeah, it's pretty long. Basically, basically, while everybody was doing punch cards. So this this happened, let me do it. I'm looking at Wikipedia. It happened in sixty eight, so everybody was still doing punch card. This guy comes along and does well. Guy, he was a professor. He does a demo. I think it was Professor a ninety minute demo live demonstration showing stuff like Windows, a mouse, Dragon, drop, copy paste, hyperlinks sixty eight.
Yeah, well okay, it's where Alan k got the idea. Huh.
It's pretty nuts. And he does this in this kind of dead pan voice. Uh, and you know he's wearing a suit and tie, and it's he's he didn't do it for you know it. It wasn't like a CEO talking up there that this is like, you know, academics talking about stuff. So it's it's but it's I I highly recommend for our listeners or for you if you're not familiar with it, to go to YouTube and just you know, search for the Mother of All demos and watch the video.
Yeah, it's pretty amazing.
Great, So you said that the second half is kind of autobiographical.
When did you enter the industry?
Uh? I got my first job as a programmer at age It was either sixteen or seventeen, I can't remember exactly. And it was a summer job and it was very temporary. And my father had actually gone to this company who was just a few miles down the road, and had walked in there and said, you will hire my son.
That was the kind of person my father was, and I found myself working at this place, and it was like two weeks, two or three weeks that I was there, and I wrote a little bit of assembly language under the watchful eye of my supervisor, got one little program working, and then he said, well, thank you very much, Bob, and now your time here is done.
When was that they find my dad.
That I was. I think I was sixteen, That would have been I was born in fifty two, so that would have been sixty eight ish something like that. I went back to that company like a year and a half later, and for a while I operated offline printers, printing junk mail on third shift, and then rapidly became a programmer. I think I spent about six months doing the offline printers, but knew some guys who were programmers and talked to them and convinced them that I probably
could be could be writing code. And from that point I was writing a little bit of co ball, which I hated, and then from then on it was mini computer assembly language and a lot of it. So that was that's when I got my start. So I guess you'd have to say, really, my career began in the very very early nineteen seventy maybe late sixty nine.
And did you also go to university or college.
Or oh no, No, this was like the Vietnam War era, and the universities were all going nuts, and my family wasn't really very well off. And in the meantime I had devoured books on cobol, on PL one and four RAN and PDP eight assembly language. I was a real computer nerd still am.
So you're the original self taught developer.
Well, probably not one of them. I mean self taught. I think Grace Opera was self taught. But but one.
Of the she did come from academia, I believe she did.
Yeah, she was. She was a mathematics professor at I can't think, Vasser, I can't remember.
Look, I have to say that. You know, today CS departments are departments on their own, But when I studied in the university, the CS department did not exist. It was part of the math department. Yeah, I mean came a couple of years later.
Yeah, the department.
If you wanted to be a programmer. In nineteen sixty nine, there weren't a lot of courses you could do ache and access to computers was very difficult, and that was one of the problems that Kemedy was trying to solve. Kemedy was at oh Geez, one of the colleges out there, I can't remember where it is on the East coast, and you know, access to computers was a really big problem. They eventually got time on one of the computers at M I T. And they would they would do it
by schlepping punched cards several miles. One of the guys would get on a train and haul punch cards up there and run the jobs and then come back with the listings. And so if you were a student, you would submit a program and maybe a week later you got a listing. And Kemedy wanted to solve that problem, and he bought a little mini computer. It was a really dinky little thing, and maybe he had six students
that really learned how to do it very well. And then it occurred to him that he needed a bigger machine, and he wrangled General Electric to give him, for a very very low price, a couple of big honk and
ge machines. I actually worked on on a machine like that at about that time, at that at that same company General General Electric Data at thirty, really really big in those days, big machines, and he and his buddy and a few undergrads wrote in assembly language, a time sharing system and a basic compiler in about six months and turned the student body loose. They had a whole bunch of teletypes that they just scattered around the school Dartmouth.
They scattered around Dartmouth, and the students could suddenly find themselves writing code and seeing it execute in the same session within minutes. And what did the students do? They wrote games?
Well, And you did bring up the fact that that Ritchie and Thompson and Richie created the uniques and c because they wanted to play games.
Space war.
Yeah. By the way, one of the things that I'm really sad about is I remember, in the nineties or something get a copy of the I Triple E Spectrum magazine talking about the origins of the video game industry Atari and whatnot, and unfortunately I did not keep it. And some crazy stories there as well. I mean, the original Atari's had one k of RAM, which you know, think about that the next time you're writing your five megabyte,
your thirty megabyte web application that does absolutely nothing. They wrote Space Invaders in one K.
You got a bunch of guys out there on the net going okay, Boomer.
I don't deny it.
I remember playing games on the Atari. I mean I was like six.
Well, I can tell you a funny story is that it was the device was limited to four colors, and one of the games they wanted to have eight colors. So they want to have four different colors at the
top and four different colors at the bottom. So what they did is they actually synchronized the game loop with the television refresh, and they would switch the palette of the colors mid screen so that that way they could get four different colors at you know, the two halves of the upper part of the screen and the lower part of the screen.
There was a lot of that kind of Shenanigan's going on.
I love video game podcasts like and and the YouTube channels like Modern Vintage Gamer and Video Game Historian doesn't really do much anymore, but the stuff that's there is great. I love learning about all those tricks that I think
Modern Vintage Gamer just did one on. I think it was the Nintendo that does that that that where they're doing that where they're swapping on the chip they're swapping what's being presented to the thing that's reading it in real time with a little microprocessor so that they can get two color ballads.
Yeah, they can't afford the garbage collection in the middle of their loop.
It's all written an assembly language, all right.
Well, well.
Yeah, just as an and that's interesting aside, we were talking, we mentioned lisp. Lisp in the I believe fifties or sixties I think, introduced the concept of garbage collection.
Yeah, that's true. Yeah, Nigarden and dol needed garbage collection in their in their Monty Carlo compiler, and they tried to write their own and then eventually they bailed out and and borrowed McCarthy's the concept of McCarthy's garbage collector, and that's what they put into simula for a while.
All Right, I'm gonna push his picks because I've got to go. I have I have a call in ten minutes.
Okay, I could talk history forever, I know.
Right, I know, it's the it's the uh.
Glory ship pop back when clean Coders comes out, and we'll see when you get them on Ruby Rogues and go into more of this stuff.
But yeah, let's do picks, and let's be.
Fast because I want to be able to do them, so AJ you want to start us.
The picks, Yeah, I'll just pick a short one. No, no, I can't do that, But the Expanse. I finished book two, and I just have to say, so far between book one and book two, the book is like, the book and the TV show are.
Very very very similar.
If I were to describe the plot of them, they're pretty much identical. But the book is so much better because in the TV show they cut out like critically important elements that are absolutely essential for you to understand why they transitioned from what seemed like two completely different TV shows with the same actors between season one and season two, where it's like, okay, these are not related other than it's the same people.
There's like a.
Few key pieces that if you know, it's like, oh okay, now I can have suspension of disbelief again. And then likewise, there's so much stuff that they added into the TV show that's completely irrelevant and just draws out like a couple extra episodes. Man, yeah, so if if the Expanse didn't hit for you on the TV show, but you like the first the first season and you want to
know where it goes. I think I think the books are better, Chuck, You'll have to chime into, you know, if the is the ending satisfying after what is it six books or nine books or something.
But they don't. They don't do all the books in the TV series, so.
Yeah, I think they were they cut out pretty early.
The books are very, very good, way better than the TV shows. I had the benefit of having read the books before I watched the TV show. There's a little bit of a gap because the sci fi folks dropped the show and then Amazon Prime picked it up and so there was like a year where they didn't record.
But yeah, anyway, it's the TV show.
Is terrific, but the books or and yes, they do stay pretty pretty close to the books.
So yeah, yeah, so keep things short. That's that's all I'll pick today. It's just got finished for that book, and I liked it. And I do have to say, Avola Sara is worse in the book than in the TV show. Previously, I complain all she does in the TV show was come in, say the F word a couple of times and leave. Yeah, she's the same in the book, like.
Better in there, there's the books.
Go on.
Okay, Dan, what are your picks?
Yeah? So I called Dibbs actually on this pick when it came along, because it's so great and it's kind of related to some of the stuff were we talk about today. So it turns out that this guy called Dmitri Mitropoulos I hope I pronounced his name correctly implemented the game Doom in the typescript type system. Because, as we all know, the typescript type system is touring complete.
It's effectively a dialect of Lisp, I think in a certain way, because you can implement loops with recursion and you also do case if statements, you know, along deseignes. So he basically managed to implement something like a compiler that's something that takes I think ll VM code and basically translates it into typescript types. It took him all of a year of working ten hour days to implement, and I think he has it running at something like a frame a week. But it works, and it's the
most insane thing I've ever seen. He put a video up, he said he'll put two more one that he talks about you know, he'll go into the details of how he actually implemented it. And I'm really trying to to get him to come on the show. If you're listening, please do. I've reached out to him and I hope that I'll be successful. You know, he did something like there's something like a trillion types in the code, something
like that. He had to remove all the limits out of the Typescript compiler source code.
Wow, I wish I worthwhile.
You know, you're going to change humanity.
This was very different from the the floppy Bird implementation. Well, the floppy Bird was a was an interpreter and this is LVM.
Yeah, something wrong if iind just correctly. Like I said, we really need to get him on the show. But you know, the funny thing though, it's we talked about is the fact that, yeah, the type system in certain programming languages, you know, Typescript also a C plus plus comes to mind. I think even Java to an extent is effectively a touring complete programming language in and off its own because you can implement recushion and with halting conditions.
So yeah, it's pretty nuts. Anyway, you can't top that, and that would be my pick for today.
I can't top that. I'm gonna throw out two picks really quick. I'm gonna do a card game.
I've picked it before, I've picked it recently, but it's the one that I've been playing the most lately. It is The Gang and it's basically cooperative Texas holden poker.
And so what you all get dealt your pocket cards?
You do, you know, you flip the river and the flip and the flop right, and at each stage in the game, there are chips for each there's one for each player, you know, one up to however many there are. Whoever thinks they have the winning hand will grab the top one right. Sometimes you fight over the chips and then you know, you go around and eventually, once you settle on the chips, then you do the flop or the river and you you know, so you get three more cards and then right and so then.
The the chips change hands.
Because right now you have a pair or two pair or three of a kind or whatever. And anyway, it's it's super fun. So you know, it takes about twenty minutes to play a game. I played it with four and five people. It gets a little harder when there are more people, but it's totally fun. So I'm gonna pick that. And then the other one is I've been watching the latest season of Reacher. I watch a lot of these kind of action kind of shows. I really
enjoy them. I have to say, the plots aren't always that creative, right, they have.
A lot of the same they're not supposed to be.
But you know, I can just you know, I can just sit and vedge and turn my brain off. So anyway, I'm enjoying that. There are like four episodes out, man, so reach here on Amazon Prime.
Bob, what are your picks?
In the spirit of ancient history, there are a couple of science fiction books that are worthy of a good, solid read, even though they're very old. The books that come to mind they're one hundred years old, are When Worlds Collide and the sequel After World's Collide. And don't get confused by Velikovsky's Worlds in Collision. That's not the
books that I'm talking about. When World's Collide and Afterworld's Collide wonderful stories written in the I think the nineteen twenties about an astronomical collision with the planet Earth and the way the scientists of the age find a way to survive. But I won't go any further than that except to say that it's very colorful and lovely and wonderful science fiction. If you can tolerate the glaring scientific errors that would have been obvious in the nineteen.
Twenties, awesome.
Can can you do spoilers after one hundred years? I guess maybe you could anyway, Bob. If people want to find you on the Internet or connect with you, where do they Where do they find you?
Clean cooder dot com. That's my website c L e A n C O d e R dot com. You can go there. Twitter handle is uncle Bob Martin beware and other than that, I don't know. Just around all right, good.
Deal, Well, thanks for coming, Bob.
This was fun, my pleasure always.
This was awesome. Thank you so much.
All Right, we're gonna wrap it up until next time, folks.
That's out.