- Not hundreds of thousands,
but he dumped all this like money he'd inherited,
he dumped it into Apple stock
the day Steve Jobs announced the Intel.
It was literally the best stock market advice
I've ever given any human being in all of history.
Apple can just wake up on a Tuesday morning,
look at all the data and say,
we're gonna turn down the chip space
we're gonna give for crypto
and we're gonna turn up the chip space
we're gonna do for video editing,
and that'll be called the M2.3 or whatever.
And because of portable operating systems
and the ability to recompile, they can just play that.
(mellow music)
- Hey everyone.
David Bombal back with Dr. Chuck.
Dr. Chuck, welcome. - It's good to be back.
I really enjoyed our last interview
and I watch it and I promote it all over the place
'cause it was a lot of fun.
- It's really great to have you back.
So before we get into details, give us an update.
What have you been up to?
Because last time you were like talking about
a whole bunch of things that you were working on.
- The thing we talked about last time
was what I call the path to the master programmer,
which is taking kind of a skilled trades approach
to teaching programming.
And focusing not on the theory of programming
or the math behind programming.
Which I still think is a fascinating topic.
I just don't think it's what should be front of mind
for most people just starting out
any more than queuing theory
should be the first thing that a CCNA person starts talking-
the math behind.
There's math behind networks,
but that doesn't mean your job
is about the math behind networks.
And so... I told you last time
that this is a long process for me.
It's going to be a couple of years
before I finish all this stuff.
And so what I do is I tend to have a set of courses
and I've got four out there on Coursera right now
and I'm working on my fifth.
And it's gonna take me two years to make my fifth.
But this course is turning out to be lovely.
First four courses are Python, Django, PHP, and Postgres.
Those are kind of like
just learning to program a little bit.
And then C is my next course.
And then hardware, architecture, and Java-
Java will be my capstone when it's all said and done.
And Java will overlap with internships, right?
So the first half of Java is like, "What's the language?"
And the second half is like, "Let's go to work."
Because I really am just getting stronger and stronger
with the notion
that the only way you really learn to program
is to work and not just do synthetic things.
And so, it's like,
I gotta stop just teaching you syntax at some point
and put you to work, get you in a job
and hopefully pay you.
And so I've been working on this C programming for everybody
www.cc4e.com.
And the crown jewel of C four everybody
is this textbook C programming,
just touching this textbook
makes the hair on the back of my neck stand up,
in a good way. This is beloved.
Millions and millions and millions of software developers
cut their teeth on this textbook.
Brian Kernighan, Dennis Ritchie.
But there are two editions of the textbook.
The textbook has a 1978 edition and a 1984 edition.
In 1978, Kernighan and Ritchie
were not sure if Unix was gonna be a good idea.
They were not sure if C was gonna be a good idea.
They knew they liked it.
They were in a research lab at AT&T and they were using it,
and they loved it.
And this book is kind of like, "Look what we have found.
Look at this really cool weird thing
you've never heard about."
And so the tone of the book is a tone of like,
"Hey, we're still researching this,
but this is what we like about this stuff
and this is what's cool and this is what-
yeah, and see that this and the whole word thing
versus character thing..."
And they're kind of always like breaking the fourth wall
and apologizing to the reader or explaining to the reader
or giving more detail to the reader.
And so this '78 book, changed the world.
And we can talk a lot about how I see the world
as previous to 1978 and post 1978.
And '78 is like everything changed in 1978.
And I could go on for hours
about all the things that I think the modern era
of computing started in 1978.
And I'm not talking like networking,
I'm talking about programming and hardware
and the ability to make our modern M1 processor.
In 1978 the foundation was laid
that made it so Apple could switch from Intel to M1,
literally, period.
The M1 processor potentially wouldn't even exist
if it weren't for the C language,
Unix and what they did back then.
But here's the thing,
I wanna give this course not just as like,
"I'm gonna teach ya' how to program C."
I mean there's like 18 million courses
that teach you how to program C,
and I think they're mostly pretty bad.
Because they mostly take a language
that should really never be used by 98% of the programmers.
And they teach it as the first programming language.
This programming language is ugly and it's bumping,
it's flawed and it breaks and it has buffer overrun
and off by one errors.
And this language is responsible
for 95% of the security problems in all of computing.
It's this programming language,
and we teach it the programmers at the beginning.
So I'm not trying to say
that we should write everything in C.
Now Rust, of course, is a really interesting language
that I'm-
I very rarely like to look at new languages
because I think they're nothing new under the sun, but Rust-
- So one of my questions, you know,
you're hitting all my questions without me even asking.
- Okay, sorry. Okay.
- No, no, no, go for it. It's brilliant.
Go for it. So one of my questions is,
should I learn C or should I learn Rust?
So carry on, I don't wanna interrupt your flow.
- And the answer is yes.
I believe, I'm not a hundred percent sure on that,
but I think the answer is yes.
But I have to look more closely at Rust.
If we can get some memory protection
of like a Python language where, you can make a string
and you don't blow your computer up
or create a security hole
just by going one beyond the end of that string,
then Rust is worth it.
And the key thing to Rust
is this may not ever be a kernel language
but it's gonna be a utility language in Linux.
It's been adopted in Linux.
And so I think what we'll find,
and we saw this in the Mac too,
they started thinking about-
Mac OS tends to like do language du jour,
the cool cool kids language du jour.
So you saw for a while Mac itself was using Ruby
to do utility work.
'Cause Ruby on Rails was all sexy in 2007, 2008, 2009.
And...now it's not.
And then they're like, "Oh we're gonna go with Python."
So Ruby's not the answer.
They're gonna go to Python and then they used Python 2.0
and so they started baking Python 2.0 into Mac OS
and then Python 2.0 became obsolete
and they had to take it all back out.
And so this is an example of trying to build utility code
in something other than C, right?
Like Telnet or Bash or whatever.
What would you build Bash in today?
And I think that maybe Rust will be that language, right?
Ruby was not that language.
Python 2.0 was not that language.
I don't think that Mac is now using Python 3.0.
I think that maybe they'll be smart like Linux is
and just switch to Rust because that means
if Rust is a long-term commitment of Linux,
then it's worth learning.
So Rust is the Python of the future.
I think it's a combination of C and Python,
but I need to look at it
and it's gonna have to evolve a little bit.
But the fact that Linux has put it in the kernel
in their next kernel,
that doesn't mean we should write everything in Rust.
We'll have to see about that because there are things that-
there's affordances in Java
that lead to better enterprise software I think.
I think that Rust is a good language
for operating system utilities
and we shall see if they start building web servers
out of Rust and they start building the next generation
of Nginx in Rust and stuff like that. So, we'll see.
So my goal is to take users back to 1978,
that's like in time travel and read a book
that was written in 1978
by people who didn't know the future, right?
- And that's a book you've got with you, right?
That's this book, that's the book.
This was written in 1978.
I'm not sure the authors of this book
like this book anymore, well one of them has passed away,
but I'm not sure that Kernighan still likes this book
because it shows him in his sort of youthful honesty
and openness and whatever.
And so I think that-
I mean this book is out of print.
I have about a hundred used copies of this book.
I bought a hundred used copies until I found a good one.
And then what I did was I digitized the book
and then I had a grad student spend all summer finding
all the typos in the book.
Then I built a website and I made it so that
all of the code examples in the book can be run online.
And then I recorded the book as a podcast.
So I have-
Well and then I also annotated the book.
So every time they go and they kind of break the fourth wall
in this book I put a comment, and it says
"What they're saying in the previous paragraph
is that there was a fundamental change in architectures
where we are going from word oriented architectures
to character oriented architectures.
And that's the difference between B and C.
Now you'll note that in 1978
they weren't sure which is the right architecture,
but then what happens is,
the future architectures all happened.
C happened. Unix happened.
In 1984 they wrote this same book
and they took all of that innocence out of it, right?
They're like, "Mm, C great language, you must use."
and that's the book that you can have in print
because they were confident.
They had changed the world between '78 and '84
and we all just bought into this idea.
So that's what's beautiful about this book, right?
Don't let your viewers all start buying the used copies
'cause then I can't buy 'em anymore, right?
I'm trying to corner the market.
- [David] Okay I'm going onto eBay now.
- Yeah, corner the market for used copies of this book
because they're precious.
But because of that I had to create the book
and I made it accessible.
The other thing I did when I read the book,
is I read the code samples.
One the things that's lovely about-
- Can I just ask you, sorry,
you've got that on your website, right?
- Yeah, www.cc4e.com, but it's behind a secret code.
So if you go to www.cc4e.com, and you click on book,
it will say you can't see this book
unless you can guess the secret code.
And then of course proceeds to give you many clues
about the secret code.
The easiest clue to get the secret code
is to know the number that I choose for my race car.
The secret code to unlock the textbook
is the same as the number for my race car.
That's all I'm gonna say.
Or if you've taken any of my other remote classes,
it is the number for which,
if you ever see it as one of the multiple choice answers,
it's always the right answer.
So if you've got like four things
and one of them is this number,
in every class I've ever taught
and every test I've ever made,
if it's like C and it's that answer
that is the right answer to the question
and that probably for most people watching your show
will be way more than enough.
They'll get it on the first try,
I'm guessing from that particular description.
And that's actually by design.
So one of the principles of what I've done
is a copyright principle called fair use.
And fair use is a way that we teachers take something
without asking permission and say,
"This is historically significant,
it's not accessible to the blind and low vision users,
dada, dada, dada dada dada."
And I'm like, "I have no choice but to do what I'm doing
to your copyrighted work
and I'm doing it in the name of education."
And so what I've done is I've saved this historical moment
in ways that the authors are choosing to have it expired.
Now, one of the things I'm gonna do
is I am gonna talk at some point to Brian Kernighan
and I'm gonna say,
"Brian, do you love or hate what I'm doing?"
And I have no way of knowing what he's going to say
because he certainly doesn't seem to show publicly
any love for this book.
He shows a lot of love for his 1984 book,
but maybe enough time has passed that
we can celebrate the joy with the joyful voice
with which he wrote this book.
I talked about seed programming for everybody in this book.
The last time we talked, I have made some progress.
I will probably have it on Coursera by June of 2023.
I am teaching it on campus
at the University of Michigan School of Information,
to a carefully selected set of 25 students
whose main purpose is to figure out if I messed it up.
I'm gonna teach 'em.
We're gonna meet once a week
and we're gonna look at the book.
So it's kind of like a special topics class
that really the goal is to fix the course
and run through it all and learn C and see if my theories
of what's the way to teach it are working well.
So I love to teach any scalable class I create,
I love to teach it face-to-face.
That's an advantage I have that you don't have,
I'm also a college professor, right?
And so you can make a thing on Cisco,
but you can't then test it with people in the same room
who are wonderful students of the University of Michigan
who are gonna give me a ton of feedback and help me out.
And then when I put it up on Coursera
it's usually in pretty good shape.
That's the next thing that I'm building.
And that will, in June,
it will be like the end of a two year sprint for me
to build "C Programming for Everybody."
And then when it's on Coursera,
usually for me it's done.
I mean, it's like I worked so much in the beginning
to engineer the course
that you know, I can teach a million students one day later,
it's ready.
It's not like it's gotta be cleaned up or beta tested.
I beta test all that before I send it out,
'cause I only want to do it once.
And that will- as soon as I do that
I will immediately start working on the hardware
and architecture class.
And then I will,
after that I will work on the Java and internship class,
Java, get to work class, and then I'll be done.
Although there's a couple of other things that I'm thinking.
I have a saying, it's only my saying,
the end of a journey
is only the beginning of the next journey, right?
When you say, "Well I've got there. I've finished it.
It's all done, I've climbed the mountain."
Then you go like, "Wait, wait, dang.
Now I see that other mountain up there.
I thought this was the mountaintop."
So, Rust is actually-
we talked about Rust.
Rust is actually something I'm thinking about
having a little mini short course on.
And another thing I'm thinking about is Amazon.
And it has to do with what are the core skills
that I think every programmer needs.
I mean, I think at some point every programmer
needs to know how to deploy something, right?
You can't just say you're gonna write code
and like your boss is gonna take it.
So I think DevOps, basic DevOps-
and I already got the website AWS4e.com
and it just redirects somewhere right now.
But I will probably end up teaching an Amazon course.
So I was at a conference a couple weeks back,
EDGE Class and I kept running into people from Amazon
who are saying, "Oh hi, I'm from Amazon."
I'm like, "What do you do there?"
"Well I'm part of their higher education engagement team."
I'm like, "What does that mean?"
And they're like, "Well we just want a higher education
to just start using Amazon
rather than buying services from third parties
that use Amazon.
Just how about universities begin to learn to use Amazon,
do their own DevOps."
And I don't know, do you do Amazon, David?"
- I use it for labs and stuff like that, but not production.
- Here's the thing, Amazon is a beautiful, beautiful thing.
I run like 35 servers, DevOps, I'm my own DevOps.
All my courses, all that stuff.
I run 'em myself and when they need scaling,
I go find a button, I click the scale button.
I mean it's exactly, the Amazon user interface is terrible,
but I'm not sure I want them to-
- (chuckling) I was gonna say that, its...
- I'm not sure I want them to fix it because honestly,
if you try to apply like user experience concepts to it
and try to make it as easy as an atm,
you'll actually break it, right?
Because the things are in AWS for a reason.
And so I think it's more important
to teach people how to understand AWS then it is to say,
"Let's make an easy button in AWS."
Like, "Oh, I want AWS, big easy button."
Unfortunately in that easy button
is a whole bunch of assumptions,
they're completely not appropriate, right?
So I kind of love the fact that Amazon is a little clunky.
It just, you can get things done.
You gotta-
I mean I bet the CLI for Cisco is the same kind of way.
It's a a bit clunky at times, but you know what?
You eventually get things done.
I think people just need to be permitted
to think that they could do DevOps.
And I think that almost all developers need to believe
that they can do DevOps there.
There'll be big places
that need to have much more specialized DevOps.
But I bet for a bunch of small places,
the average developer overlaps with DevOps pretty naturally.
So I was talking to people at conference and then Amazon,
my name started going through the Amazon AI bot,
whatever it was, then my phone starts ringing in my-
"Hi, I'm your Amazon handle." Right?
'Cause I have a company and stuff.
And I was starting to talk about this whole education thing
and how I want higher education to learn to use Amazon
on their own and carry their own water a little bit
'cause it's just not that hard.
And they were like,
"Oh, we got a lot of really cool instruction."
And I'm like, "Okay,
usually instruction from vendors is terrible.
You know that right? You know? - Yep. You know that, yeah?
- Of course, of course.
There's a whole industry of people doing training
about x, y, Z vendor. Yeah.
- Well the problem if it comes from the vendor
is it's really a sales pitch, right?
They can't resist selling.
- Sell you. Yep, always.
- They go like, "Well here's AWS,
by the way, AWS was the greatest value on earth
because of this and this and this and this...
And it's like, "No, no, no, I just wanna learn
how to click the buttons." Right?
- Exactly. And so they assured me
that their training's great.
And oh, I took their advice
and I started looking at their Amazon training
and I signed up for some courses on the Amazon training.
The first course is how to get your procurement to approve
Amazon purchases.
I mean, literally that's the first course.
Okay. Now the, the second course is "What's EC2?"
What's Aurora serverless? Really?
That's good.
Those are the first two things I would teach people.
And so the interesting thing is, is that,
even though they couldn't resist a sales pitch,
they did get some good material.
And so the more I look at it,
the more I realize it's not really inspirational at all.
It's not inspirational at all.
They got this whole thing where they tell you
that Amazon is a coffee shop, AWS is a coffee shop,
and they talk about the doorway
and they talk about the baristas.
And Auto Scaling is like,
there's too long of a line for coffee,
and so you need a new barista.
I'm like, huh, how's that help?
So should we teach Cisco with a barista model?
And then the problem is- - Yep, yep.
- They'll start a sentence and talk about coffee,
and then they'll end a sentence
talking about the intricacies of Auto Scaling groups
and health checks.
I mean it's like, look man,
if you're so dumb
that you have to have such a simple metaphor,
by the end of the sentence,
you went from like 5 years old to 25 years old
in one sentence, in terms of a skill.
Because these people are writing script, you know.
That's just me complaining about overproduced, overthought,
corporate training stuff.
But they have good stuff in it.
- But you gonna create a course,
that's the question, you know?
- Yes. I'm gonna do what you did.
- Great, great.
Great - I am going to do
what teachers really need to do.
And that is have symbolic understanding of things.
Motivate.
Think about how the learner's actually gonna progress.
Because you're a practitioner, right?
Not an instructional designer. Right.
For you, it's not a script.
For you it's about like,
"I just gotta get this thing in my head
out to those students
in a way that they can understand it."
And then I'll just say, "Oh yeah,
and the textbook for this class
is all this other Amazon training, which is pretty good."
It's just completely uninspirational.
It's just, there's no symbolism to it,
there's no connection in it,
there's no nothing.
It's just a script read by really nice people.
And it's not wrong, but they should have just wrote a book.
- It's so good to see.
You saw a problem eating your own dog food.
I think that's the American term, right?
- [Dr. Chuck] Yes, it is.
- You're doing it.
And then you seeing the problem with the training
and you're creating a solution for that.
- Yeah. I mean, when you're a teacher and a practitioner,
right? You understand the value
that real teachers bring.
Teachers who are teaching from expertise
rather than scripts.
And passion and belief.
I mean, I believe in the idea that schools
and universities should directly interact with Amazon.
I mean I it's like it's just in me.
And so I'm just, it's bursting out of me.
I can't wait to talk to this very camera
and record all these lectures about you are gonna love AWS
and you're gonna feel so powerful when you use AWS
and not like
(using robotic voice) "It's Lanka, a coffee shop."
- So the the big question is, "You got a long line."
- when do we get it? That's the question.
- Oh, geez, that's gonna be hard to know.
I gotta finish the C class.
I gotta finish the hardware class
and I gotta finish the Java class.
- You sold us and now we wanna buy it now.
Take my money! - Yeah.
- I know. Well, maybe you could do it.
Maybe you could teach an Amazon class.
- No, no, no, no.
I'll let you do it.
That's fantastic.
So I wanna come back to C
because I think there's a list of questions,
like I said is should I learn C, should I learn Rust?
If I was starting, what would you suggest I do?
- Well, I certainly wouldn't start with either C or Rust.
Right. - Okay
I think Python for all perpetuity is the right language.
And that's because I just think
that to become a confident programmer,
you need six or seven programming languages, right?
And so it's not like, you can't say that Rust
is the best programming language,
and so therefore you should start with Rust
and go to a Rust bootcamp
and four weeks later you're going to be making $200,000
as a Rust programmer.
That's just a fallacy, right?
That's not really teaching.
That's kind of like taking advantage of,
you have a little bootcamp
that's next door to a really big company
that needs Rust programmers
and you're just kind of like preparing Rust programmers,
manufacturing them
and sticking them in the doorway of this company.
But that's not a career, right?
That's- - Yeah.
If that company goes away, that's like,
bootcamp was useless
and your next job you have no idea what to do.
And so, you know, you should learn Python.
I think people should learn PHP.
I think people should learn JavaScript.
And so the question is not what's the first language?
The question is a,
"What are the super set of all languages
you should eventually learn?"
So I mean it's, it's Python.
I like PHP because...
and I like SQL and then I'm gonna teach C.
And then I'm gonna teach assembly,
then I'm gonna teach Java.
And there's a difference between that
and what you do in the professional world, right?
What I'm really doing in that training
is I'm getting to the point where you can have a job
in a Java shop,
meaning that you can do your first internship
in a Java shop.
That doesn't mean that you shouldn't later learn scala
or something else,
'cause you're going to work at a place that does scala.
But my education for you
is not so that you can immediately start typing on the job.
My education is so that you can learn on the job, right?
And so once you've got all those languages,
then you can learn other languages
and you really don't care anymore what the language is.
So I want you to learn so many languages
while you're being trained that the next language you learn
will be completely no big deal.
And one of the things about the C class,
and it's really cool because I'm teaching it on campus now,
the last part of the C class,
which is a kind of a circle back,
is not C,
it's how did Python build the dictionary object in C.
So you take a procedural language with all of its flaws
and memory allocation problems
and potential security holes
and you build an object oriented environment.
So you could think of it as how you can go from C to C++.
How did C++ get implemented in C?
How did Python get implemented in C?
The last of this C class is,
you are going to build a dictionary object.
And the test is,
I'm gonna call your dictionary object
and I'm gonna stick things in
and I'm gonna ask for them out
and I'm gonna ask you to sort 'em
and do stuff like that, right?
We talked before the essence of programming
is understanding object orientation in context.
Not just understanding object orientation like,
"I know what this parenthesis does
or what this arrow operator does
or what the dot operator does."
But like problem solving, real problems,
large complex code, object oriented.
And that's why the end of the C class
is gonna be implementing object oriented,
not so that you can then write Python yourself.
But then from that moment forward,
the next time you use Python and make a dictionary
and add an item to it,
in your brain, you know,
"I know what's going on here.
"And I know why self matters in a Python object.
And I know why this matters in a Java object.
And so what is this and what is self?"
It's some of the hardest concepts
in object oriented programming, is why is self so important?
I tell my students over and over about what it is,
and I know it took me so long to understand that.
It took me so long
to really understand object oriented programming.
And so I just say it over and over and over again.
And by making them build an object oriented runtime in C,
I hope that I'm going to sort of take 'em down the path
where maybe, "Oh, okay, this is really easy."
Because once you know it, it's like,
"Oh of course. why didn't I think of that?" Right?
You know, I'm glad someone else thought of it before me
and I just can use this stuff in languages like Python
and Java.
- Should companies be writing code in C
or should they use Rust or something else?
Because it, like you said in the beginning, you know,
there's a lot of vulnerabilities using C.
- I can't imagine anyone writing C code
unless it was like a boot loader or something
that was so highly constrained.
Or perhaps you're in a washing machine
and you have so little memory
or you have a processor that's so slow that you gotta worry
about every single thing.
But even then, if you're in these highly constrained,
high consequence environments,
because if you're writing software for a washing machine,
you have no way of upgrading the software
in the washing machine.
And so your washing machine is simple software,
but it's gotta work perfectly forever
or you throw a whole washing machine away, right?
And so this is where you start in these highly constrained
non upgradable environments.
You might find that C++ is a better language, right?
And I'm not sure that you wanna put Rust
in a washing machine.
if you've got like 4K of memory or something like that.
Now maybe washing machines have 50 GB of RAM in them-
I don't think so-
but they probably have a little tiny chip
that's got like 64K of RAM in it
and a CPU and nothing else,
and it's just like 18 cents or something like that.
And then something like that, you might want to program C,
you might have to program C.
And it would be fine at that point
because the need to review your code
and test your code and think through everything
in your code.
It's not so bad when you're just making a control panel
for a washing machine.
But again, I think that the sweet spot for Rust
is going to be utilities, right?
Like you know,
a future person might write a Python like language
in Rust, right?
Or a web browser in Rust rather than a web browser in C.
And again, I have to evaluate Rust more.
But if it's everything I'm imagining,
then yeah we shouldn't be writing web servers in C anymore,
or C++.
We should be writing those in Rust.
And the key thing will be is if Rust evolves to the point
we get memory safety from Rust
without having much of a garbage collection cost,
then maybe Rust could be used for things like web servers
and Nginx and all those things will slowly but surely
be rewritten in Rust.
And TCP/IP stacks could be written in Rust.
I do think the world has experimented enough
with other programming languages
and we do have, in general purpose computing,
enough memory to tolerate
a kind of a lightweight garbage collection.
So I don't know if you follow Java or not,
but garbage collection has been the historical bugaboo
for Java forever and ever and ever.
It's both the greatest and scariest feature of Java
at the exact same time.
And interestingly,
going back to C, they talk about garbage collection in 1978
as one of the hardest problems to solve
and why it is that they left it out of the language, right?
They said memory management
is one of the hardest problems to solve.
So there is no memory management in C,
we put it in a library.
And what they couldn't have known in 1978
is how good the garbage collection has gotten, right?
So I've been doing Java since 2002
and garbage collection has been scary
and the Java garbage collection has just gotten better
and better and better.
I mean, it's kinda like relational databases,
Java garbage collection
and the join in a relational database
are both things that so much computer science brain power
has been focused on and it's yielded, I mean,
relational stuff yielded some time ago.
But like if you go back to like two years ago
three years ago,
and you look at the garbage collection aspects of Java
compared to the modern Java,
the garbage collection is amazing.
And so that suggests to me, I can't prove this yet,
but that suggests to me that because Java
has cracked the garbage collection problem,
it means that Rust will steal all of that innovation.
And to some degree Rust was not going to be successful
until Java was successful with garbage collection.
So we could figure out how to make a fast garbage collector
that didn't pause.
I mean the problem the old Java garbage collectors,
you're sitting there doing, you know,
100 transactions a second in a web server
and then all of a sudden it's gotta do garbage collection.
It goes like 1,001, 1,002, 1,000, 1,004,
oh back to 100 transactions a second.
And that's garbage collection in 2005 Java, right?
It's like it runs great, it runs great,
it runs great and then it stops for three seconds
and then it runs great again.
And then like 10 minutes later it stops for three seconds.
Which you just like, ah,
like that is not a good way to run things.
It doesn't do that anymore, right?
And so the struggle of understanding garbage collection
is the reason that we haven't built
high performance application in garbage collected languages.
So if Rust keeps garbage collection
in a little corner over here
and uses the latest and greatest
garbage collection techniques,
then we can write a lot in Rust and it will be awesome.
You can't have Nginx pause for a few seconds
to garbage collect.
You can't do that.
You can't have a TCP/IP stack pause for three seconds.
You just can't do that.
You can't have Linux pause for three seconds.
You can have Twitter pause for three seconds.
Especially if it's got a bunch of servers
and it's only one server that's pausing at any given minute
and it routes things around during those three seconds
or whatever.
I mean Google uses Java for lots and lots of things, so.
So part of the reason that I love this 1978 edition
of the Kernighan and Ritchie book,
is that 1978 is the single most pivotal moment
in all of computer science history.
And the key thing is as you can draw a line and after 1978,
literally nothing before 1978 was true, right?
I mean there was a truth, there was a truth before 1978
and then after 1978 there was a new truth, right?
The things that were true pre '78 were not true post '78.
Let me give you a couple of examples of that.
Pre '78 we tended to write FORTRAN on computers
that were word oriented.
And so they were not,
they were tended to think about floating point
and injury calculations for like weather simulations
and stuff, 'cause we tended to use computers to compute.
We didn't use computers to communicate
or write word processing documents or whatever.
And so the architecture of computers
was tuned to computation, to numeric computation.
And so the programming languages
were tuned to numeric computation.
The hardware was tuned to numeric computation.
The problems that we solve
were tended to be numeric computation before 1978.
And what's happening in the 70s is, partly driven by
the growth of the ARPANET and the internet,
is computers were becoming mediators
for human communication.
So that you and I are talking,
but computers are mediating our conversation.
First it was mostly text, right?
And so what happened was, is this notion
that a computer word had to be long
so that you could have high accuracy computations,
but characters are short.
And so when I was young,
you had 10 characters per word and you would mask and shift
to get a character out, right?
And when I started, there was no lower case on computers.
We only had uppercase on computers,
we wrote code in FORTRAN, it was like the Hulk shouting.
Right?
And what was happening in 1978.
And the thing that C and Unix at AT&T Bell Labs
was the smaller computers were not really aimed
at computation
and think about AT&T, was a telephone company.
So it's thinking about communication, not computation.
So it wasn't doing ballistics or weather computations
or supercomputer simulations,
it was just like getting phone calls to go back and forth
and getting billing to work.
And what is billing?
Billing is text, right?
It like, oh you know,
you made a long distance call
and let's send a bill out later.
And so the idea of billing and all that stuff moves from
computation as the essential purpose of computers
to mediated human interaction, right?
So that you're just getting a bill from a computer, right?
Or doing accounting or doing inventory.
None of that is computationally intensive.
And so what happened was,
is the computer architecture changed from these long words
for high accuracy mathematical calculations
to single characters, eight bits, six bits, nine bits,
10 bits, whatever it was,
so that you could do characters, right?
Eight bits could do upper and lower case
from a kind of a western character set,
Western Latin character set.
And then, you know,
1978 that was kind of what mattered was eight characters,
eight bit bites. And so the problem was, is all the program,
none of the programming languages were suitable,
none of the operating systems were suitable,
nothing was suitable.
And here you have AT&T
moving from a mathematical computation
to textual computation.
And they were building everything in 1960s, 70s.
And there's a language that comes before C, called B.
And the difference between B and C is,
B is a word oriented language that looks like C
and C is a character oriented language that looks like C
and that's like whoa, that changed everything.
But then what happens is these character oriented computers
were slow and cheap compared to the big super computers
that were 4, 8, $10 million for one computer, right?
These things are like, you know,
$100,000 cheap.
Cheap little $100,000 computers that you can throw around.
A department could own one or a bank could own one,
but they didn't have any operating systems,
they didn't have any programming languages.
And the problem with them is in the 1970s,
these little computers were coming out like pall mall,
they were just like boom, boom, here's another one,
here's another one, and this one's completely different.
'Cause they were exploring a new fundamental change
in architecture of a bite oriented architecture
rather than a word oriented architecture.
And so the problem that they had to solve at AT&T Bell Labs
was, "Whoa, we just wrote an operating system
for this particular PDP8,
but now we just bought a bunch of these other things.
Crap. Now what do we do?"
Well maybe we should just make an operating system
in a language that abstracts away the low level bits of it
and just make a compiler for this new thing.
An Interdata shows up, a VAX shows up, a PDP8 shows up.
And they had a whole range of new cool computers
and old crappy computers
and they wanted to use them all to do things right?
The old hand me down computers they would use for email
and stuff like that.
So they wanted to write an operating system that would work
all the way from the latest cool computer they bought
to the old crappy hand-me-downs.
So they were studying language
and operating system portability
and their goal was to take Unix
and reduce the amount of assembly language into it
to a smaller and smaller fraction.
And that was the research.
The research was all operating systems
are written in assembly language before Unix.
And now we're writing an operating system
crazy in a high level language
and then we still have to write a little tiny bit
of assembly language and we have to write a compiler.
but that compiler can generate code that's probably faster
than hand built assembly language.
And so they're just like,
we got all these problems to solve.
And so what happened was is by the time they were done,
in '78, you see them talking in the book
about the inner data and the PDP and how like,
and we did this in the PDP and then we had to change Unix
and we had to change C
so that it would work with the inner data.
And in that portability,
in that sort of progress of hardware progress marching on,
they figured out when they got a new piece of hardware,
how to quickly get to the point
where they had an operating system.
Quickly get to the point where they had a compiler.
Quickly get to the point where they had some networking
and they could plug that system in
and it was materially the same as all the other systems
that they had purchased for the last five or six years.
What this allowed for,
was it allowed for separately procuring the operating system
and the hardware.
Which meant that if there's a little company
that came up with an innovation
that was a computer hardware innovation,
they could buy that. They could say, "You know what,
we've been buying these PDP8s for a long time,
but this Interdata company man, they're cheaper,
they're faster, they got more memory.
Let's just recompile everything and use this Interdata stuff
'cause that's cheap.
'cause they talk a lot about Interdata,
company that I don't even think even exists anymore,
in 1978.
And so their research was how to use a wide variety
of new to old hardware to do the same thing.
And then what happened was
is because they had solved the problem
of software portability,
hardware vendors
could begin to accelerate their iteration time.
They could say, Hmm.
And even the same hardware vendor
could come up with later versions of the same thing
and make changes in the architecture once they realize
that this instruction slowed the whole computer down.
So we're gonna take that instruction out.
Whoa, in the old days of assembly language
that would break your code.
Well not in C,
it just changed the compiler not to use that instruction.
And then we recompile everything
and then boom this new, twice as fast computer
that had one- I'm just making this up-
twice as fast computer that had one instruction removed,
you're working like a week later.
You're up and running on that new hardware.
And so it permitted innovations to happen
and that innovation has led to the Moore's law,
the doubling every few years and all that stuff.
And the most recent thing that we see of this is how Apple
switched from, this is a little older,
from PowerPC as their core hardware architecture
to Intel as their core hardware architecture,
to an arm-based M1, et cetera, processor.
And it wasn't all that hard.
And if you kind of know the history of the,
I mean the M1 is, it's almost like easy.
It's like of course, but of course 'cause it's using C
and it's using portable languages,
and of course it-
so when they switched from Intel,
you could see that happening.
Right when they switched from Intel to M1.
'Cause they were doing it in all their portable stuff
and all their iPads
and they're sneaking these arm processors
and I knew some Apple people and they're like,
"Hmm, you might want to keep an eye on the fact that
Apple's hiring a lot of hardware people.
We're gonna build our own processor eventually."
And I'm like, "I don't think that's gonna work."
And of course I was wrong on that particular thing, right?
Apple is now optimizing the hardware on every iteration
of the M processor, right?
They're instrumenting it, they're running, you know,
video editing software, everything,
they instrument everything and they go like,
"We're gonna change the architecture like every year
because guess what?
We're using C and portable. Everything's portable,
we recompile it and yeah I can add three instructions
or take away three instructions
and it's okay on a year by year basis to iterate.
But the one that's actually way more interesting than,
well way more surprising, than the the Intel to arm
was the PowerPC to Intel.
'Cause that was a very closely held secret
because if you go back in time,
Steve Jobs spent a lot of time marketing how bad Intel was
and the how much better the PowerPC was.
And he wasn't lying
but he was being very selective in what he pointed out.
'Cause the PowerPC was a better floating point processor
than it was an integer processor, right?
And the Intel was a better integer processor.
So all the marketing until they were Intel
was how important floating point was
to things like the charcoal filter in Photoshop.
Like watch how fast a charcoal filter in Photoshop works on
a Mac versus a Windows.
It's 12 times faster
and that's just 'cause it was floating point.
The algorithm was using floating point
which was fast on the PowerPC.
Now other than that,
the PowerPC is a terrible architecture
for a portable computer.
It's big, makes a lot of heat,
uses up your battery real fast,
and it was not nearly as good as Intel
on integer calculations.
What turn out to be word processing and stuff like that,
which is most of what we do.
I mean what part of your day
are you running the charcoal filter in Photoshop?
Not much on any given day.
And so Steve Jobs I think had like a five year project
that was five people,
that was recompiling the Mac operating system
and running it on Intel based hardware for five years
in a secret lab that only like 10 people knew about.
And I mean I was at the Apple,
I think it was 2007 or 2008,
when they sort of talked the Intel.
And I was sitting in the room when he walked out
and said, "We're gonna use Intel processors."
For me you could have heard a pin drop.
I'm like, "You've been criticizing these folks all along
and here you have had a secret project
to use Intel processors."
And so what they did is, I walked out of that room,
I walked out of that room with Steve Jobs in front and said,
and the Intel guy, they're hugging, "Oh Intel's great,
Intel's great."
Yeah like one week ago you said they were terrible
and now you say they're great.
I walked out of that room with Steve Jobs
and they had opened this big show floor
with a bunch of prototype Intel-based Mac OS.
literally they had them in another room.
And they just gave you a root account.
You walked in, sat down on a prototype Intel-based Mac box
and I immediately logged in
and I had been doing development on a
Windows a Intel-based Mac for years and I started running
the stuff that I ran and it worked first time,
this was Rosetta with a simulation mode.
It worked first time and it was twice as fast.
The thing I was doing,
which was running a Java application was twice as fast on
on the Intel-based Mac on the first day,
on the first prototype.
That's dramatic.
But C is why they could do that.
C is why they could have an operating system
that secretly they're running on Intel
for five years and selling on PowerPC for five years.
And then boom, I walked outta that room,
I called my brother-in-law and I said,
"If you have any money, buy Apple stock right now."
And I didn't buy any Apple stock at that point in time,
but my brother-in-law did.
He had just gotten like an inheritance or something.
He literally put it on the day they announced Intel support,
he dumped his whole, not not hundreds of thousands,
but he dumped all this like money he'd inherited,
he dumped it into Apple stock the day Steve Jobs announced
the Intel.
It was literally the best stock market advice
I've ever given any human being in all of history.
I mean I've bought stock and usually I'm wrong.
Stock...
If I tell you, if I give you advice it might be good,
but if I actually take my own advice
then it probably is gonna be a disaster
'cause I'm not very good in the stock market.
But again,
it comes back to 1978 and the things that were set in motion
that led to the PowerPC, to the Intel, to the M1,
to the M2, to the M3, to the M4, to the M5,
because it's all portable and they can iterate on hardware
in the same way that they could iterate on software.
And that is the thing
that sort of drives technology forward.
I don't know if you- do you have an M1 Mac
or are you a Mac guy?
- Yeah. Yeah yeah.
I've got the M1 and M2. Yeah.
- Yeah I think I have an M1.
But here's the thing. I dunno if you've done this,
but I go teach a lecture,
I don't take a power supply to lecture anymore.
I literally... - It's amazing.
never, I would never, it's amazing. I would never walk-
that power supply was always like within one foot of me
at any given minute.
I now leave it in my office.
I have a power supply, I don't even take it to work.
I go to work, I give a lecture, I go to lunch,
I plug it into the power supply in my office
and then I go do another lecture
and I never take a power supply to work.
And that's because the M1 processor,
but it's also because portable operating systems
made it so that one processor could do what they do
and they've optimized everything in the name of power.
And when the Apple people told me
they were hiring hardware people, they were like,
"We are going to optimize an architecture based on power."
- It's amazing that, I mean I've,
I'm actually talking to you on an Intel.
And the difference between Intel and the M1, M2s
is astounding.
- I don't understand
why I'm not hearing your fan then, right?
I mean if you're, if we're talking on a Intel,
you should be, your fan should be turned on.
- Exactly.
Yeah. I've got nothing on except Zoom.
That's why. - Okay.
Yeah, it's, I mean the fan thing is unbelievable,
like the power you've said.
I mean the, power it's exactly that.
You can use M1, M2 laptops for so long
compared to Intel and yeah.
fan and heat are typically the worst,
in my experience, on Intel.
- Yeah, I mean I wonder going forward
the extent to which crypto influenced the M1 and M2
and the extent to which maybe crypto won't influence
the M3 and M4 and M5 and M26 or whatever.
I do think that if you look at the first M1s that came out
crypto as a workload
was one of the things they were thinking about.
And I just wonder if they'll figure out
that it didn't work out making a laptop
that's good for both crypto and really low power,
high, high capability, low power.
And so again, Apple can just wake up on a Tuesday morning,
look at all the data and say, you know what,
we're gonna turn down the chip space we're gonna give
for crypto and we're gonna turn up the chip space
we're gonna do for video editing
and that'll be called the M2.3 or whatever.
And because of portable operating systems
and the ability to recompile, they can just play that.
And this is part of the reason in the master programmer
computer architecture's important, right?
'Cause now we can have this conversation about chips
and about memory sizes and all this stuff.
And if you don't even know what assembly language is,
you don't quite understand how the M2 is profoundly
different than the Intel processor.
And then if you're gonna be a professional,
you should have some concept,
not that you're building hardware,
but you should have some concept
of the nature of changing hardware
and how that changes what you can do,
changes how we can save power across the entire world.
Cause all these cloud servers are just sucking power
and doing all kinds of terrible things.
But if all of a sudden a simple,
just a simple iteration can cut that power down
by a factor of 10, 'cause it can,
portable software is what lets us then save so much energy.
- That's amazing. So would you say that C changed the world?
- Yeah. There's no question that C changed the world.
And the strange thing is that
not only does C change the world in 1978,
but it's still not a programming language you should use,
right?
So C is the single most important innovation
in computer science, hardware and software architecture.
But I still am not suggesting that you programming it.
But I am suggesting that you learn it
because it teaches you about the nature of computation.
You should use the a much better tools for the job
like JavaScript or Python or even Java or whatever.
Those are way better tools for getting programming done.
But there is no better tool
to understand programming than C.
- Dr. Chuck, I really want to thank you, you know,
not just for sharing your knowledge and experience with us
through videos like this and other things you do,
but also for making it accessible to everyone
through the courses that you've created
and this path to Master Programmer.
I want to give you the floor.
Is there anything you want to say?
Otherwise we're gonna wrap it up.
- I guess the only thing I would say
is that people who sort of see scarcity
as the way to financial success, they're really mistaken.
The key is the world is such a large market
and there are so many people
and there are so many ways to become financially successful
without hoarding intellectual property.
And I think that if there's one lesson in all of this,
both the work that you do and the work that I do,
it's that hoarding Intellectual property just is like,
stop doing it. Right?
There are ways to be successful without hoarding
intellectual property.
- Dr. Chuck as always, thanks so much.
- Thanks Dave. (static crackling)
(mellow music)