Pioneers of Computing: A Journey Through Tech History with Bob Martin - JsJ 671

In this episode, we dive into a fascinating mix of tech history, personal stories, and entertainment recommendations. We chat with Bob Martin, who shares insights from his new book, offering a look back at the pioneers of computing, including early breakthroughs and the industry's evolution. Bob talks about the challenges of leaving out influential figures like Margaret Hamilton, Donald Knuth, and Linus Torvalds, while also reminiscing about his early career as a self-taught developer during the 70s.

The conversation takes a fun turn when we discuss some mind-blowing tech feats, including a wild project where Doom was implemented using TypeScript’s type system—a true demonstration of the power of programming languages. For those into entertainment, we share some great picks, like the classic science fiction novels When Worlds Collide and After Worlds Collide, plus a rundown of TV shows like Reacher and the intriguing comparison between the Expanse books and TV show. Packed with history, tech talk, and plenty of geeky fun, this episode is a must-listen for anyone interested in the past, present, and future of computing!

Become a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

Episode Transcript

Speaker 1 (00:05):
Hey, welcome back to Programmer Story Hour with Uncle Bob
or JavaScript Jabber as we call it every week.

Speaker 2 (00:14):
This week on our panel, we have a j O'Neal.

Speaker 3 (00:17):
Yo yah yoh, come that you live.

Speaker 4 (00:19):
From the now with plywood paneling shed or like I said,
a drywall. I got someplywood from a friend who is
dumping it nice.

Speaker 2 (00:30):
We also have Dan Shapere.

Speaker 3 (00:32):
Hello from Tel Aviv.

Speaker 5 (00:34):
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.

Speaker 6 (00:42):
Thank you so much. Good to be back.

Speaker 5 (00:45):
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.

Speaker 6 (00:57):
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?

Speaker 3 (01:12):
Even cleaner Code, we can only pray.

Speaker 6 (01:16):
Clean Code second Edition. I tried to play with other titles,
but the publisher was very adamant be Clean Code second edition.

Speaker 2 (01:26):
I think it's easier to sell if you keep the title.

Speaker 3 (01:28):
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?

Speaker 2 (01:45):
Oh heavens, I did say, story our go for it, Bob.

Speaker 6 (01:53):
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

(02:18):
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.

(02:41):
How does that play in. And besides that, there's languages.

Speaker 7 (02:45):
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.

Speaker 6 (03:03):
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

(03:26):
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.

Speaker 3 (03:45):
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

(04:08):
the code being clean, Like would you apply the same
principles in order to achieve clean code in different programming languages.

Speaker 6 (04:19):
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

(04:41):
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

(05:02):
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.

Speaker 2 (05:13):
Yeah, I remember, with the help of co.

Speaker 6 (05:15):
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.

Speaker 2 (05:37):
Very cool. We're looking forward to that coming out.

Speaker 4 (05:40):
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?

(06:01):
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

(06:21):
your actual advice on function size or grouping of logic?

Speaker 6 (06:28):
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

(06:51):
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.

Speaker 3 (07:05):
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.

(07:26):
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.

Speaker 6 (07:35):
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

(07:56):
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.

Speaker 4 (08:12):
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

(08:36):
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

(08:57):
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

(09:18):
you have to make your font size really small, then
you know it's too much context in the brain.

Speaker 3 (09:23):
I've got these I don't make my font size too small.

Speaker 6 (09:29):
Yeah.

Speaker 4 (09:29):
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

(09:50):
this much logic or transforming if it's like a parser
or a transformer.

Speaker 6 (09:57):
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?

Speaker 2 (10:19):
How do you remove the.

Speaker 6 (10:20):
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

(10:41):
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.

Speaker 4 (10:54):
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.

Speaker 3 (11:06):
I literally want had to refactor code that had in
it one through in it ten oh jee.

Speaker 6 (11:18):
Yeah, but that's useful. But they kept the line rule.

Speaker 5 (11:22):
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.

Speaker 2 (11:30):
For one.

Speaker 5 (11:30):
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.

Speaker 2 (11:47):
They're just the next layer of abstraction.

Speaker 5 (11:49):
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,

(12:12):
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.

Speaker 2 (12:35):
But beyond that. Yeah, typically you can break it out into.

Speaker 3 (12:39):
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

(13:00):
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.

Speaker 1 (13:20):
Oh, yeah, we're here to talk about we programmers.

Speaker 5 (13:28):
Go go ahead and answer this question, Bob, and then
we'll move on and move on to story hour.

Speaker 6 (13:32):
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

(13:55):
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,

(14:18):
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.

Speaker 3 (14:32):
Often because you don't want side effects, all right right now.

Speaker 6 (14:36):
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

(14:56):
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.

Speaker 3 (15:08):
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.

Speaker 6 (15:22):
Well, yeah, given the constraints of the language.

Speaker 2 (15:26):
And it's not easy either.

Speaker 5 (15:28):
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.

Speaker 2 (15:41):
It was Voltaire, it was somebody important.

Speaker 5 (15:45):
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

(16:06):
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.

Speaker 6 (16:28):
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,

(16:53):
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,

(17:18):
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

(17:40):
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

(18:03):
he was out of the army and he just dropped
out of the school and said, yeah, the hell with that.

Speaker 7 (18:08):
And he he built himself a nice little Wi Fi system.

Speaker 6 (18:11):
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

(18:37):
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

(19:02):
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

(19:24):
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

(19:46):
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.

(20:11):
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.

Speaker 3 (20:22):
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

(20:44):
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.

Speaker 6 (20:58):
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

(21:20):
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.

(21:41):
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

(22:04):
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.

Speaker 3 (22:22):
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

(22:46):
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.

Speaker 6 (23:05):
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.

Speaker 3 (23:15):
Well, you know the story about Ellen Kay and Grace Hopper.

Speaker 6 (23:20):
Please please tell me the story.

Speaker 3 (23:23):
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

(23:44):
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.

Speaker 6 (24:04):
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

(24:24):
fun time for me. So I've walked away from that
language and never looked back.

Speaker 3 (24:29):
Remember what happened when COVID hit?

Speaker 6 (24:35):
I thought you were going to go for y two K.
So know what happened when COVID hit?

Speaker 3 (24:39):
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.

Speaker 6 (24:55):
Yeah, I've actually heard that, since there's a lot of
people talking about these things are all rich and in cobalt.

Speaker 5 (25:03):
Okay, Well, it's like any other project that I've worked on.
We don't actually update it until it's breaking.

Speaker 6 (25:14):
I think some of these are long past that point.

Speaker 2 (25:18):
Well look, yeah, but they can patch it over and yeah.

Speaker 3 (25:23):
Yeah, Well she also invented the term bug, as I recall.

Speaker 6 (25:27):
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

(25:48):
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

(26:13):
words like that that we all know and love today.

Speaker 3 (26:17):
So again, how did you go about the research?

Speaker 6 (26:21):
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

(26:42):
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

(27:03):
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.

(27:24):
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

(27:46):
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

(28:11):
difficult technical problems.

Speaker 5 (28:14):
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.

Speaker 6 (28:28):
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

(28:48):
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.

(29:09):
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,

(29:32):
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.

(29:57):
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

(30:20):
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

(30:43):
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

(31:03):
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

(31:25):
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,

(31:47):
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

(32:08):
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

(32:32):
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,

(32:53):
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,

(33:14):
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

(33:37):
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

(34:05):
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

(34:27):
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

(34:48):
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

(35:09):
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

(35:29):
the horrors of the earliest of programming jobs.

Speaker 3 (35:35):
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

(35:57):
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

(36:21):
a photograph you don't say, photographic memory? How do you
call it these days?

Speaker 6 (36:26):
Photograph?

Speaker 3 (36:27):
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

(36:50):
a youth. And he basically started reciting it, and he
asked him to stop after something like ten or fifteen minutes.

Speaker 6 (37:02):
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

(37:26):
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

(37:46):
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

(38:07):
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

(38:30):
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,

(38:51):
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

(39:12):
kind of like like fine, yes, a lot like Fineman.

Speaker 3 (39:19):
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.

Speaker 6 (39:41):
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.

Speaker 2 (39:45):
Imposter syndrome, kind of.

Speaker 6 (39:47):
The other way around. Right, It's like.

Speaker 3 (39:53):
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.

Speaker 6 (40:07):
Well he was remembered and fondly.

Speaker 3 (40:11):
Yeah.

Speaker 6 (40:12):
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,

(40:35):
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

(40:55):
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.

(41:18):
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.

Speaker 3 (41:43):
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.

Speaker 6 (41:53):
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,

(42:14):
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.

Speaker 5 (42:32):
If you want to hear the full deal from the
horse's mouth, we have an episode where.

Speaker 6 (42:38):
Oh with brendan Ike Oh beautiful.

Speaker 3 (42:42):
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.

(43:02):
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

(43:25):
kind of like Pearl. It's a language for text processing.

Speaker 6 (43:32):
Ah, somebody in Kernahan.

Speaker 3 (43:36):
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.

Speaker 6 (43:47):
Predecessor of Pearl, Yeah, exactly, predecessor of Ruby.

Speaker 2 (43:52):
This is cool actually.

Speaker 6 (43:55):
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.

Speaker 3 (44:10):
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.

Speaker 5 (44:23):
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

(44:44):
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.

Speaker 6 (45:00):
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

(45:24):
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

(45:45):
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

(46:05):
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,

(46:30):
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

(46:52):
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

(47:16):
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

(47:38):
the guy that first had that concept.

Speaker 3 (47:43):
That's amazing. I didn't consider that. There are several people
that you decided not to include in your book.

Speaker 6 (47:55):
Uh.

Speaker 3 (47:56):
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?

Speaker 6 (48:14):
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

(48:35):
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,

(48:56):
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

(49:17):
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,

(49:37):
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.

Speaker 3 (49:54):
And the Mother of Old demos, I'm sorry, Engelbert and
the Mother of All demos.

Speaker 6 (50:00):
That's a story I don't know.

Speaker 3 (50:03):
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.

Speaker 6 (50:13):
Demos sounds good.

Speaker 3 (50:17):
Yeah, it's still considered to be the greatest demo of
all time.

Speaker 2 (50:22):
It's like, I see a couple of them here. When
of them was like an hour and forty minutes.

Speaker 3 (50:26):
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

(50:49):
demo live demonstration showing stuff like Windows, a mouse, Dragon, drop,
copy paste, hyperlinks sixty eight.

Speaker 6 (51:03):
Yeah, well okay, it's where Alan k got the idea. Huh.

Speaker 3 (51:08):
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

(51:28):
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.

Speaker 2 (51:42):
Yeah, it's pretty amazing.

Speaker 8 (51:43):
Great, So you said that the second half is kind
of autobiographical.

Speaker 3 (51:54):
When did you enter the industry?

Speaker 6 (51:58):
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.

(52:20):
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.

Speaker 3 (52:42):
When was that they find my dad.

Speaker 6 (52:43):
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

(53:05):
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

(53:27):
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.

Speaker 3 (53:41):
And did you also go to university or college.

Speaker 6 (53:45):
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.

Speaker 3 (54:07):
So you're the original self taught developer.

Speaker 6 (54:11):
Well, probably not one of them. I mean self taught.
I think Grace Opera was self taught. But but one.

Speaker 3 (54:19):
Of the she did come from academia, I believe she did.

Speaker 6 (54:22):
Yeah, she was. She was a mathematics professor at I
can't think, Vasser, I can't remember.

Speaker 3 (54:30):
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.

Speaker 2 (54:49):
Yeah, the department.

Speaker 6 (54:53):
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,

(55:15):
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

(55:37):
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

(55:59):
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

(56:21):
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

(56:43):
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

(57:03):
themselves writing code and seeing it execute in the same
session within minutes. And what did the students do? They
wrote games?

Speaker 3 (57:16):
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.

Speaker 6 (57:29):
Space war.

Speaker 3 (57:31):
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.

(57:52):
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.

Speaker 6 (58:12):
You got a bunch of guys out there on the
net going okay, Boomer.

Speaker 3 (58:18):
I don't deny it.

Speaker 2 (58:22):
I remember playing games on the Atari. I mean I
was like six.

Speaker 3 (58:27):
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

(58:49):
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.

Speaker 6 (59:00):
There was a lot of that kind of Shenanigan's going on.

Speaker 4 (59:05):
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

(59:26):
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.

Speaker 3 (59:45):
Yeah, they can't afford the garbage collection in the middle
of their loop.

Speaker 6 (59:52):
It's all written an assembly language, all right.

Speaker 2 (59:55):
Well, well.

Speaker 3 (59:58):
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.

Speaker 6 (01:00:08):
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.

Speaker 5 (01:00:29):
All Right, I'm gonna push his picks because I've got
to go. I have I have a call in ten minutes.

Speaker 3 (01:00:36):
Okay, I could talk history forever, I know.

Speaker 6 (01:00:39):
Right, I know, it's the it's the uh.

Speaker 5 (01:00:44):
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.

Speaker 2 (01:00:53):
But yeah, let's do picks, and let's be.

Speaker 5 (01:00:55):
Fast because I want to be able to do them,
so AJ you want to start us.

Speaker 4 (01:00:58):
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.

Speaker 2 (01:01:18):
Very very very similar.

Speaker 4 (01:01:20):
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

(01:01:42):
season two, where it's like, okay, these are not related
other than it's the same people.

Speaker 6 (01:01:47):
There's like a.

Speaker 4 (01:01:47):
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

(01:02:08):
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.

Speaker 2 (01:02:26):
But they don't. They don't do all the books in
the TV series, so.

Speaker 4 (01:02:30):
Yeah, I think they were they cut out pretty early.

Speaker 5 (01:02:33):
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

(01:02:54):
so there was like a year where they didn't record.

Speaker 2 (01:02:55):
But yeah, anyway, it's the TV show.

Speaker 5 (01:02:58):
Is terrific, but the books or and yes, they do
stay pretty pretty close to the books.

Speaker 4 (01:03:06):
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

(01:03:26):
the book, like.

Speaker 2 (01:03:27):
Better in there, there's the books.

Speaker 3 (01:03:29):
Go on.

Speaker 2 (01:03:30):
Okay, Dan, what are your picks?

Speaker 3 (01:03:33):
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

(01:03:58):
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

(01:04:25):
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

(01:04:47):
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

(01:05:10):
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.

Speaker 6 (01:05:24):
Wow, I wish I worthwhile.

Speaker 2 (01:05:29):
You know, you're going to change humanity.

Speaker 4 (01:05:32):
This was very different from the the floppy Bird implementation. Well,
the floppy Bird was a was an interpreter and this
is LVM.

Speaker 3 (01:05:43):
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

(01:06:04):
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.

Speaker 2 (01:06:21):
I can't top that. I'm gonna throw out two picks
really quick. I'm gonna do a card game.

Speaker 5 (01:06:27):
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.

Speaker 2 (01:06:38):
And so what you all get dealt your pocket cards?

Speaker 5 (01:06:43):
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

(01:07:04):
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.

Speaker 2 (01:07:15):
The the chips change hands.

Speaker 5 (01:07:17):
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

(01:07:40):
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.

Speaker 3 (01:07:50):
A lot of the same they're not supposed to be.

Speaker 5 (01:07:52):
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.

Speaker 2 (01:08:03):
Bob, what are your picks?

Speaker 6 (01:08:05):
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

(01:08:25):
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

(01:08:49):
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.

Speaker 2 (01:09:02):
Twenties, awesome.

Speaker 5 (01:09:07):
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?

Speaker 6 (01:09:19):
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.

Speaker 2 (01:09:34):
Deal, Well, thanks for coming, Bob.

Speaker 6 (01:09:36):
This was fun, my pleasure always.

Speaker 3 (01:09:39):
This was awesome. Thank you so much.

Speaker 2 (01:09:41):
All Right, we're gonna wrap it up until next time, folks.

Speaker 6 (01:09:44):
That's out.