The following is a conversation with James Gosling, the founder and lead designer behind
the Java programming language, which in many indices is the most popular programming language
in the world, or is always at least in the top two or three. We only had a limited time for
this conversation, but I'm sure we'll talk again several times in this podcast. Quick summary of
the sponsors, public goods, better help, and ExpressVPN. Please check out these sponsors in
the description to get a discount and to support this podcast. As a side note, let me say that
Java is the language with which I first learned object-oriented programming and with it, the art
and science of software engineering. Also, early on in my undergraduate education, I took a course
on concurrent programming with Java. Looking back at that time, before I fell in love with
neural networks, the art of parallel computing was both algorithmically and philosophically
fascinating to me. The concept of a computer in my mind before then was something that does one
thing at a time. The idea that we could create an abstraction of parallelism where you could do
many things at the same time while still guaranteeing stability and correctness was beautiful.
While some folks in college took drugs to expand their mind, I took concurrent programming.
If you enjoy this thing, subscribe on YouTube, review it with $5,000 up a podcast, follow on
Spotify, support on Patreon, or connect with me on Twitter at Lex Freedman. As usual, I'll do a
few minutes of ads now and no ads in the middle. I try to make these interesting, but I do give
you timestamps, so go ahead and skip, but please do check out the sponsors by clicking the links
in the description. It's the best way to support this podcast. This show sponsored by Public Goods,
the one-stop shop for affordable, sustainable, healthy household products. I take their fish
oil and use their toothbrush, for example. Their products often have a minimalist black and white
design that I find to be just beautiful. Some people ask why I wear this black suit and tie.
There's a simplicity to it that, to me, focuses my mind on the most important bits of every moment
of every day, pulling only at the thread of the essential in all that life has to throw at me.
It's not about how I look, it's about how I feel. That's what design is to me, creating an
inner conscious experience, not an external look. Anyway, Public Goods plants one tree for every
order placed. Just kind of cool. Visit publicgoods.com slash Lex or use code Lex at checkout to get 15
bucks off your first order. This show is also sponsored by BetterHelp, spelled H-E-L-P Help.
Check it out at betterhelp.com slash Lex. They figure out what you need and match you with a
licensed professional therapist in under 48 hours. I chat with a person on there and enjoy it. Of
course, I also regularly talk to David Goggins these days, who is definitely not a licensed
professional therapist, but he does help me meet his and my demons and become comfortable to exist
in their presence. Everyone is different, but for me, I think suffering is essential for creation,
but you can suffer beautifully in a way that doesn't destroy you. I think therapy can help
in whatever form that therapy takes, and I do think that better help is an option worth trying.
They're easy, private, affordable, and available worldwide. You can communicate by text anytime
and schedule weekly audio and video sessions. Check it out at betterhelp.com slash Lex.
This show is also sponsored by ExpressVPN. You can use it to unlock movies and shows
that are only available in other countries. I did this recently with Star Trek Discovery on UK
Netflix, mostly because I wonder what it's like to live in London. I'm thinking of moving from
Boston to a place where I can build the business I've always dreamed of building. London is probably
not in the top three, but top 10 for sure. The number one choice currently is Austin, for many
reasons that I'll probably speak to another time. San Francisco, unfortunately, dropped out from the
number one spot, but it's still in the running. If you have advice, let me know. Anyway, check
out ExpressVPN. It lets you change your location to almost 100 countries, and it's super fast.
Go to expressvpn.com slash Lex pod to get an extra three months of ExpressVPN for free.
That's expressvpn.com slash Lex pod. And now here's my conversation with James Gosling.
I've read somewhere that the square root of two is your favorite irrational number.
I have no idea where that got started. Is there any truth to it? Is there anything in mathematics
or numbers that you find beautiful? Oh, well, there's lots of things in math that's really
beautiful. I used to consider myself really good at math, and these days I consider myself really
bad at math. I never really had a thing for the square root of two, but when I was a teenager,
there was this book called The Dictionary of Curious and Interesting Numbers,
which for some reason I read through and damn near memorized the whole thing.
And I started this weird habit of when I was filling out checks or paying for things with
credit cards, I would want to make the receipt add up to an interesting number.
Is there some numbers that stuck with you that just kind of make you feel good?
They all have a story. And fortunately, I've actually mostly forgotten all of them.
Are they so like 42? Well, yeah. I mean, 42 is pretty magical.
And then the irrationals. I mean, but is there a square root of two story in there somewhere?
How does that homework get started? It's like the only number that has destroyed a religion.
In which way? Well, the Pythagoreans, they believed that all numbers were perfect and you could
represent anything as a rational number. And in that time period,
this proof came out that there was no rational fraction whose value was equal to the square root
of two. And that means nothing in this world is perfect, not even mathematics.
Well, it means that your definition of perfect was imperfect.
Well, then there's the Gatal incompleteness theorems in the 20th century that ruined it once
again for everybody. Yeah. Although Gertl's theorem,
the lesson I take from Gertl's theorem is not that there are things you can't know,
which is fundamentally what it says. But people want black and white answers.
They want true or false. But if you allow a three-state logic that is true, false, or maybe,
then life's good. I feel like there's a parallel to modern political discourse in there somewhere.
But let me ask, with your early love or appreciation of the beauty of mathematics,
do you see a parallel between that world and the world of programming?
Yeah. Programming is all about logical structure, understanding the patterns that come out of
computation, understanding the path through the graph of possibilities to find a short root.
Meaning like find a short program that gets the job done kind of thing. So then on the
topic of irrational numbers, do you see programming? You just painted it so cleanly.
It's a little of this trajectory to find a nice little program. But do you see it as
fundamentally messy, maybe unlike mathematics? I don't think of it as, I mean, you watch somebody
who's good at math do math. And often it's fairly messy. Sometimes it's kind of magical.
When I was a grad student, one of the students, his name was Jim Sacks, was, he had this reputation
of being sort of a walking, talking, human, theorem-proving machine. And if you were having
a hard problem with something, you could just like accost him in the hall and say, Jim. And he
would do this funny thing where he would stand up straight. His eyes would kind of defocus.
He'd go, just like something in today's movies. And then he'd straighten up and say,
end log in and walk away. And you'd go, well, okay, so end log in is the answer. How did he get there?
By which time he's down the hallway somewhere. Yeah.
Hey, today's just the oracle of the black boxes. It gives you the answer.
Yeah. And then you have to figure out the path from the question to the answer.
I think in one of the videos I watched, you mentioned Don Knuth. Well, at least recommending his
book is something people should read. But in terms of theoretical computer science,
do you see something beautiful that has been inspiring to you speaking of end log in
and in your work on programming languages that's in the whole world of algorithms and complexity
and these kinds of more formal mathematical things? Or did that not really stick with you
in your programming life? It did stick pretty clearly for me because
one of the things that I care about is being able to look at a piece of code and be able to
prove to myself that it works. And so, for example, I find that I'm at odds with many
of the people around me over issues about how you lay out a piece of software. So, software
engineers get really cranky about how they format the documents that are the programs,
where they put new lines and where they put the braces and all the rest of that.
And I tend to go for a style that's very dense.
So, minimize the white space.
Yeah. Well, to maximize the amount that I can see at once. So, I like to be able to see
a whole function and to understand what it does rather than have to go scroll, scroll, scroll,
and remember. Yeah. I'm with you on that. And people don't like that?
Yeah. I've had multiple times when engineering teams have staged what was effectively an
intervention where they invite me to a meeting and everybody has arrived before me and they
all look at me and say, James, about your coding style. I'm sort of an odd person to be programming
because I don't think very well verbally. I am just naturally a slow reader. I'm what
most people would call a visual thinker. So, when you think about a program, what do you see?
I see pictures. Right. So, when I look at a piece of code on a piece of paper,
it very quickly gets transformed into a picture. And it's almost like a piece of machinery with
this connected to that and gears and knobs and things. Yeah. I see them more like that than
I see the sort of verbal structure or the lexical structure of letters. So, then when you look at
the program, that's why you want to see it all in the same place, then you can just map it to
something visual. Yeah. And it just kind of like it leaps off the page at me. Yeah. What are the
inputs? Where are the outputs? What the heck is this thing doing? Yeah. Yeah. Getting a whole
vision of it. Can we go back into your memory, long-term memory access? What's the first program
you've ever written? Oh, I have no idea what the first one was. I mean, I know the first machine
that I learned to program on was a PDP-8 at the University of Calgary.
Do you remember the specs? Oh, yeah. So, the thing had 4K of RAM. Nice. 12-bit words. The clock
rate was about a third of a megahertz. Oh, so you didn't even get to the M, okay. Yeah. So,
we're like 10,000 times faster these days. And was this kind of like a super computer,
like a serious computer? No. The PDP-8i was the first thing that people were calling like mini
computer. Got it. They were sort of inexpensive enough that a university lab could maybe afford to
buy one. And was there time sharing, all that kind of stuff? There actually was a time sharing OS for
that. But it wasn't used really widely. The machine that I learned on was one that was
kind of hidden in the back corner of the computer center. And it was bought as part of a project
to do computer networking. But they didn't actually use it very much. It was mostly just
kind of sitting there. And it was kind of sitting there. And I noticed it was just kind of sitting
there. And so, I started fooling around with it. And nobody seemed to mind. So, I just kept doing
that. And I had a keyboard and like a monitor. Oh, this is way before monitors were common.
So, it was literally a Model 33 teletype with a paper tape reader.
Okay. So, the user interface wasn't very good. Yeah. It was the first computer ever built
with integrated circuits. But by integrated circuits, I mean that they would have like
10 or 12 transistors on one piece of silicon. Nice. Not the 10 or 12 billion that machines
have today. So, what did that feel like if you remember those? I mean, did you have kind of
inklings of the magic of exponential kind of improvement of Moore's law of the potential of
the future that was at your fingertips kind of thing? Or was it just a cool? Yeah. It was just
a toy. I had always liked building stuff. But one of the problems with building stuff is that you
need to have parts. You need to have pieces of wood or wire or switches or stuff like that.
And those all cost money. And here you could build. You could build arbitrarily complicated
things and I didn't need any physical materials. It required no money. That's a good way to put
programming. You're right. It's if you love building things, it's completely accessible.
You don't need anything. And anybody from any work could just build something really cool.
Yeah. If you've got access to a computer, you can build all kinds of crazy stuff.
And when you were somebody like me who had really no money, and I remember just lusting
after being able to buy a transistor. And when I would do electronics kind of projects,
they were mostly made done by dumpster diving for trash. And one of my big halls was
a discarded relay racks from the back of the phone company switching center.
Oh, nice. That was the big memorable treasure.
Oh, yeah. Yeah. That was a really good one.
What do you use that for?
I built a machine that played tic-tac-toe out of relays. Of course, the thing that was really
hard was that all the relays required a specific voltage. But getting a power supply that would
do that voltage was pretty hard. And since I had a bunch of trashed television sets,
I had to sort of cobble together something that was wrong but worked.
So, I was actually running these relays at 300 volts. And none of the electrical connections
were properly sealed off. Surprised you survived that period of your life.
Oh, for so many reasons. I mean, it's pretty common for teenage geeks to discover,
oh, thermite. That's really easy to make. Yeah. Well, I'm glad you did. But do you remember
what program and calorie that you wrote, anything that stands out? And what language?
Well, so anything of any size was assembly code. And actually, before I learned assembly code,
there was this programming language on the PDP-8 called Focal 5. And Focal 5 was kind of like a
really stripped-down Fortran. And I remember building programs that did things like play Blackjack
or Solitaire. For some reason, the things that I really liked were ones where they were just
like plotting graphs. So, something with a function or data, and then you plot it.
Yeah. I did a bunch of those things and went, ooh, pretty pictures.
And so, this would print out, again, no monitors. Right. So, it was on a teletype.
Right. Yeah. So, using something that's kind of like a typewriter and then using those two
plot functions. So, when, I apologize to romanticize things, but when did you first
fall in love with programming? What was the first programming language? Like,
as a serious maybe software engineer, what are you thought this is a beautiful thing? I guess I
never really thought of any particular languages being like beautiful, because it was never really
about the language for me. It was about what you could do with it. And even today, people try to
get me into arguments about particular forms of syntax or this or that. And I'm like, who cares?
Right. It's about what you can do, not how you spell the word.
And so, back in those days, I learned like PL1 and Fortran and Koval. And by the time that people
were willing to hire me to do stuff, it was mostly assembly code and PDP assembly code and
Fortran code and control data assembly code for like the CDC-6400, which was an early I guess
supercomputer. Even though that supercomputer has less compute power than my phone by a lot.
And that was mostly, like you said, Fortran world. That said, you've also showed appreciation
for the greatest language ever that I think everyone agrees is Lisp.
Well, Lisp is definitely on my list of the greatest ones that have existed.
Is it at number one? I mean, you know, the thing is that I wouldn't put it number one, no.
Is it the parentheses? What do you not love about Lisp?
Well, I guess the number one thing to not love about it is so freaking many parentheses.
On the love thing is out of those tons of parentheses, you actually get an interesting
language structure. And I've always thought that there was a friendlier version of Lisp
hiding out there somewhere. But I've never really spent much time thinking about it.
But you know, so like up the food chain for me from Lisp is Simula,
which a very small number of people have ever used.
But a lot of people, I think you had a huge influence, right? Yeah.
The programming, but in the Simula, I apologize if I'm wrong on this, but is that one of the
first functional languages? No, it was the first object-oriented programming language.
Got it.
It's really where object-oriented and languages came together. And it was also the language where
co-routines first showed up as a part of the language. So you could have a programming style
that was, you could think of it as sort of multi-threaded with a lot of parallelism.
Really? There was ideas of parallelism in there?
Yeah. Yeah. So that was back, you know, so the first Simulus back was Simula67.
Like 1967? Yeah. Wow.
So it had co-routines which are almost threads. The thing about co-routines is that they don't
have true concurrency, so you can get away without really complex locking. You can't
usually do co-routines on a multi-core machine. Or if you try to do co-routines on a multi-core
machine, you don't actually get to use the multiple cores. Either that or you, you know,
because you start then having to get into the universe of semaphores and locks and things like
that. But, you know, in terms of the style of programming, you could write code and think of
it as being multi-threaded. The mental model was very much a multi-threaded one and all kinds
of problems you could approach very differently. To return to the world of Lisp for a brief moment,
you, at CMU, you wrote a version of Emacs that I think was very impactful on the history of Emacs.
What was your motivation for doing so? At that time, so that was in like 85 or 86.
I had been using Unix for a few years and most of the editing was this tool called ED,
which was sort of an ancestor of VI. Is it a pretty good editor, not a good editor?
Well, if what you're using, if your input device is a teletype, it's pretty good.
It's certainly more humane than TIKO, which was kind of the common thing in a lot of the deck
universe at the time. TIKO is called TK? Is that the one? No, TIKO, T-E-C-O, the text editor and
corrector. So many features. The original Emacs came out as, so Emacs stands for editor macros,
and TIKO had a way of writing macros. The original Emacs from MIT started out as a
collection of macros for TIKO. But then the Emacs style got popular originally at MIT,
and then people did a few other implementations of Emacs that were... The code base was entirely
different, but it was sort of the philosophical style of the original Emacs.
What was the philosophy of Emacs? And by the way, were all the implementations always in C,
and how does Lisp fit into the picture? No, so the very first Emacs was written as a bunch of
macros for the TIKO text editor. Wow, this is so interesting. And the macro language for TIKO
was probably the most ridiculously obscure format. If you just look at a TIKO program on a page,
you think it was just random characters. It really looks like just line noise.
It's just kind of like latex or something. Oh, way worse than latex. Way, way worse than latex.
But if you use TIKO a lot, which I did, the TIKO was completely optimized for touch typing
at high speed. So there were no two-character commands, or there were a few, but mostly
they were just one character. So every character on the keyboard was a separate command.
And actually, every character on the keyboard was usually two or three commands because
you can shift and control and all of those things. It's just a way of very tightly encoding it.
And mostly what Emacs did was it made that visual. So one way to think of TIKO is use Emacs
with your eyes closed, where you have to maintain a mental model of sort of a mental image of your
document. You have to go, okay, so the cursor is between the A and the E. And I want to exchange
those so I do these things. So it is almost exactly the Emacs command set. Well, it's roughly
the same as Emacs command set, but using Emacs with your eyes closed. So part of what Emacs added
to the whole thing was being able to visually see what you were editing in a form that matched your
document. And a lot of things changed in the command set. Because it was programmable,
it was really flexible. You could add new commands for all kinds of things. And then
people rewrote Emacs like multiple times in Lisp. There was one done at MIT for the Lisp machine.
There was one done for Multix. And one summer, I got a summer job to work on the Pascal compiler
for Multix. And that was actually the first time I used Emacs. To write the compilers. You worked
on compilers too. It's fascinating. Yeah, so I did a lot of work. I spent a really intense
three months working on this Pascal compiler, basically living in Emacs. And it was the one
written in Maclist by Bernie Greenberg. And I thought, wow, this is just a way better way to do
editing. And then I got back to CMU, where we had kind of one of everything. And two of a bunch
of things and four of a few things. And since I mostly worked in the Unix universe, and Unix
didn't have an Emacs, I decided that I needed to fix that problem. So I wrote this implementation of
Emacs in C, because at the time, C was really the only language that worked on Unix. And you
were comfortable with C as well, at that point? Yeah, at that time, I had done a lot of C coding.
This was in like 86. And it was running well enough for me to use it to edit itself within a
month or two. And then it kind of took over the university. And then it spread outside.
Yeah. And then it went outside the, and largely because Unix kind of took over the research
community on the ARPANET. And Emacs was kind of the best editor out there. It kind of took over.
There was actually a brief period where I actually had login IDs on every non-military host
on the ARPANET. Because people would say, oh, can we install this? And I'd like,
well, yeah, but you'll need some help. The days when security wasn't... When nobody cared.
Nobody cared. Yeah. I mean, you can ask briefly, what were those early days of ARPANET and the
internet like? I mean, did you, again, sorry for the silly question, but could you have possibly
imagined that the internet would look like what it is today? Some of it is remarkably unchanged.
So one of the things that I noticed really early on when I was at Carnegie Mellon was that
a lot of social life became centered around the ARPANET. And so things like between email and
text messaging, because text messaging was a part of the ARPANET really early on. There were no
cell phones, but you're sitting at a terminal and you're typing stuff. So essentially email,
or what is... Well, it's just like a one-line message, right? So... Oh, cool. It's like chat.
Like chat, right? So it's like sending a one-line message to somebody, right?
And so pretty much everything from arranging lunch to going out on dates was all like
driven by social media, right? In the 80s. Easier than phone calls, yeah.
Yeah. And my life had gotten to where I was living on social media from the early-mid-80s.
And so when it sort of transformed into the internet and social media explodes,
I was kind of like, what's the big deal? Yeah. It's just a scale thing. Right. The scale thing
is just astonishing. Yeah. But the fundamentals in some ways were insane.
The fundamentals have hardly changed. And the technologies behind the networking have changed
significantly. The watershed moment of going from the ARPANET to the internet,
and then people starting to just scale and scale and scale. I mean, the scaling that happened in
the early 90s and the way that so many vested interests fought the internet.
Oh, interesting. Because you can't really control the internet?
Yeah. So fundamentally, the cable TV companies and broadcasters and phone companies at the
deepest fibers of their being, they hated the internet. But it was often kind of a funny thing
because… So think of a cable company. Most of the employees of a cable company,
their job is getting TV shows, movies, or whatever out to their customers. They view their business
as serving their customers. But as you climb up the hierarchy in the cable companies,
that view shifts because really, the business of the cable companies
had always been selling eyeballs to advertisers. Right. And that view of a cable company didn't
really dawn on most people who worked at the cable companies. But I had various dust-ups with
various cable companies where you could see, in the stratified layers of the corporation,
that this view of the reason that you have cable TV is to capture eyeballs there.
So they didn't see it that way. Well, so the people who… Most of the people who worked at
the phone company or at the cable companies, their view was that their job was getting delightful
content out to their customers. And their customers would pay for that. Higher up,
they viewed this as a way of attracting eyeballs to them. And then what they were really doing
was selling the eyeballs that were glued to their content to the advertisers.
To the advertisers, yeah. And so the internet was a competition in that sense.
Right. And so… They were right.
Well, yeah. I mean, there was one proposal that we sent, one detailed proposal that we
wrote up back at that sun in the early 90s that was essentially like,
look, with internet technologies, anybody can become provider of content. So you could be
distributing home movies to your parents or your cousins who are anywhere else. So anybody can
become a publisher. Wow. You were thinking about that already, yeah. Netflix.
Yeah, that was like in the early 90s. Yeah.
And we thought, this would be great. And the kind of content we were thinking about at the time was
like home movies, kids' essays, stuff from grocery stores or a restaurant that they could actually
start sending information about. That's brilliant.
And the reaction of the cable companies was like, fuck no, because then we're out of business.
What is it about companies that, because they could have just been ahead of that wave.
They could have listened to that. They didn't see a path to revenue.
There's somewhere in there, there's a lesson for big companies, right?
To listen, to try to anticipate the renegade out there, out of the box,
people like yourself in the early days writing proposals about what this could possibly be.
Well, if you're in a position where you're making
truckloads of money off of a particular business model,
the whole thought of like leaping the chasm, you can see new models that are more effective
are emerging, right? So like digital cameras versus film cameras.
Why take the leap? Why take the leap? Because you're making so much money off of film.
In my past at Sun, one of our big customers was Kodak, and I ended up interacting with
folks from Kodak quite a lot. They actually had a big digital camera research and digital imaging
business or bit development group. They knew that you just look at the trend lines and you look at
the emerging quality of these digital cameras. You can just plot it on the graph, and it's like,
sure, film is better today, but digital is improving like this. The lines are going to cross, and
the point at which the lines cross is going to be a collapse in their business, and they could see
that. They absolutely knew that. The problem is that up to the point where they hit the wall,
they were making truckloads of money. And when they did the math,
it never started to make sense for them to lead the charge. And part of the issues for a lot of
companies for this kind of stuff is that if you're going to leap over a chasm like that,
like with Kodak going from film to digital, that's a transition that's going to take a while.
We had fights like this with people over smart cards. The smart cards fights were just ludicrous.
But that's where visionary leadership comes in, right? Somebody needs to roll in and say,
then take the leap. Well, it's partly take the leap, but it's also partly take the hit.
So you can draw all the graphs you want that show that if we leap from here,
you know, on our present trajectory, we're doing this and there's a cliff. If we force
ourselves into a transition and we proactively do that, we can be on the next wave. But there
will be a period when we're in a trough. And pretty much always there ends up being a trough
as you leap the chasm. But the way that public companies work on this planet,
they're reporting every quarter. And the one thing that a CEO must never do
is take a big hit over some quarter. And many of these transitions
involve a big hit for a period of time, you know, one, two, three quarters. And so you get some
companies and, you know, like Tesla and Amazon are really good examples of companies that take
huge hits. But they have the luxury of being able to ignore the stock market for a little while.
And that's not so true today, really. But, you know, in the early days of both of those companies,
you know, like they both did this thing of, you know,
I don't care about the quarterly reports. I care about how many happy customers we have.
Yeah. Right. And having as many happy customers as possible can often be
an enemy of the bottom line. Yeah. So how do they make that work? I mean,
Amazon operated the negative for a long time. It's like investing into the future.
Right. But, you know, so Amazon and Google and Tesla and Facebook, a lot of those had
what amounted to patient money, often because there's like a charismatic central figure
who has a really large block of stock. And they can just make it so.
So on that topic, just maybe it's a little small tangent, but you've gotten a chance to work with
some pretty big leaders. What are your thoughts about Tesla side Elon Musk leadership on the
Amazon side, Jeff Bezos, all of these folks with large amounts of stock and vision in their company?
I mean, they're founders. Yeah. Either complete founders or like early on folks.
And Amazon have taken a lot of leaps, you know, that probably at the time people would
criticize as like, what is this bookstore thing? Why? Yeah. And, you know, Bezos had a vision
and he had the ability to just follow it. Lots of people have visions and, you know,
the average vision is completely idiotic and you crash and burn. You know, the Silicon Valley
crash and burn rate is pretty high. And they're not, they don't necessarily crash and burn because
they were dumb ideas, but, you know, often it's just timing. Timing and luck. And, you know,
you take companies like Tesla and really, you know, the original Tesla, you know,
sort of pre-Elon was kind of doing sort of okay, but he just drove them. And because
he had a really strong vision, you know, he would make calls that were always, you know,
well, mostly pretty good. I mean, the Model X was kind of a goofball thing to do.
But he did it boldly anyway. Like there's so many people that just said like,
there's so many people that oppose them on the Falconwind door, like the door.
Yeah. From the engineering perspective, those doors are ridiculous. It's like...
Yeah, they are a complete travesty.
But they're exactly the symbol of what great leadership is, which is like,
you have a vision and you just go like...
If you're going to do something stupid, make it really stupid.
Yeah, and go all in.
Yeah. Yeah. And, you know, to my credit, he's a really sharp guy.
All right. So, going back in time a little bit to Steve Jobs,
you know, Steve Jobs was a similar sort of character who had a strong vision and was really,
really smart. And he wasn't smart about the technology parts of things, but he was really sharp
about the sort of human relationship between, you know, the relationship between humans and objects.
But he was a jerk.
You know, can we just linger on that a little bit? Like people say he's a jerk.
Is that a feature or a bug?
Well, that's the question, right? So, you take people like Steve,
who was really hard on people. And so, the question is, was he really,
was he needlessly hard on people or was he just making people reach to meet his vision?
And you could kind of spin it either way.
Well, the results tell a story. You know, he's,
he, whatever jerk ways he had, he made people often do the best work of their life.
Yeah. Yeah. And that was absolutely true. And, you know, I interviewed with him several times.
I did, you know, various negotiations with him. And even though kind of personally I liked him,
I could never work for him.
Why do you think that, can you put into words the kind of tension that you feel would be
destructive as opposed to constructive?
Oh, he'd yell at people. He'd call them names.
And you don't like that?
No. No, I don't think you need to do that.
And, you know, I think, you know, there's pushing people to excel.
And then there's too far. And I think he was on the wrong side of the line.
And I've never worked for Musk. I know a number of people who have,
many of them have said, and it shows up in the press a lot, that Musk is kind of that way.
And one of the things that I sort of loathe about Silicon Valley these days is that
a lot of the high-flying successes are run by people who are complete jerks.
But it seems like there's come this sort of mythology out of Steve Jobs that the reason
that he succeeded was because he was super hard on people. And in a number of corners,
people start going, oh, if I want to succeed, I need to be a real jerk. And that for me just
does not compute. I mean, I know a lot of successful people who are not jerks,
who are perfectly fine people. They tend to not be in the public eye.
The general public somehow lifts the jerks up into the hero status.
Right. Well, because they do things that get them in the press.
And the people who don't do the kind of things that spill into the press.
Yeah, I just talked to Chris Ladner
for the second time. He's a super nice guy, just an example of this kind of kind of individual
that's in the background. I feel like he's behind a million technologies, but he also
talked about the jerkiness of some of the folks. Yeah. And the fact that being a jerk has become
your required style. But one thing I maybe want to ask on that is, and maybe to push back a little
bit. So there's the jerk side, but there's also, if I were to criticize what I've seen
is to the Bound Valley, which is almost the resistance to working hard. So on the jerking
aside, it's so posted jobs and Elon kind of pushed people to work really hard to do. And
it's a question whether it's possible to do that nicely. But one of the things that bothers me,
maybe I'm just Russian and just kind of romanticize the whole suffering thing.
But I think working hard is essential for accomplishing anything interesting, like really
hard. And in the parlance of Silicon Valley, it's probably too hard. This idea of that you
should work smart, not hard. Often, to me, sounds like you should be lazy, because of course you
want to be to work smart. Of course, you would be maximally efficient. But in order to discover
the efficient path, like we're talking about all of the short programs. Yeah. Well, the smart,
hard thing isn't an either or, it's an and. It's an and, yeah. Right. And the people who say you
should work smart, not hard, they pretty much always fail. Yeah. Thank you. Right. I mean,
that's just a recipe for disaster. I mean, there are counter examples, but
there are more people who benefited from luck. And you're saying, yeah, exactly. Luck and timing,
like you said, is often an essential thing. But you're saying you can push people to work hard
and do incredible work without being nasty. Yeah, without being nasty. I think Google is
a good example of the leadership of Google throughout its history has been a pretty good
example of not being nasty and being kind. Yeah. I mean, the twins, Larry and Sergey,
are both pretty nice people. Sandoval Chavez, very nice. Yeah. Yeah. And
you know, it's a cultural of people who work really, really hard.
Let me ask maybe a little bit of a tense question. We're talking about Emacs. It seems like you've
done some incredible work outside of Java. You've done some incredible work that didn't
become as popular as it could have because of licensing issues and open source and issues.
What are your thoughts about that entire mess? What's about open source now in retrospect,
looking back about licensing, about open sourcing. Do you think open source is a good thing, a bad
thing? Do you have regrets? Do you have wisdom that you've learned from that whole experience?
So in general, I'm a big fan of open source. The way that it can be used to build communities
and promote the development of things and promote collaboration and all of that is really pretty
grand. When open source turns into a religion that says all things must be open source,
I get kind of weird about that because it's sort of like saying some versions of that
end up saying that all software engineers must take a vow of poverty.
As though… It's unethical to have money to build a company to write.
Right. There's a slice of me that actually buys into that because people who make billions of
dollars off of a patent and the patent came from literally a stroke of lightning that hits you as
you lie half awake in bed. Yeah, that's lucky. Good for you. The way that that sometimes
sort of explodes into something that looks to me a lot like exploitation.
And you see a lot of that in the drug industry when you've got medications that cost you like
$100 a day. And it's like, no. Yeah, so the interesting thing about open source,
is what bothers me is when something is not open source and because of that, it's a worse product.
Yeah. So if I look at your just implementation of Emacs, that could have been the dominant
implementation. I use Emacs. That's my main ID. I apologize to the world, but I still love it.
And I could have been using your implementation of Emacs. And why aren't I?
So are you using the GNU Emacs? I guess the default on Linux. Is that GNU?
Yeah. And that through a strange passage started out as the one that I wrote.
Exactly. And part of that was because in the last couple of years of grad school,
it became really clear to me that I was either going to be Mr. Emacs forever or I was going to
graduate. I couldn't actually do both. Was that a hard decision? That's so
interesting to think about you as a, it's a different trajectory that could have happened.
Yeah. That's fascinating. And maybe I could be fabulously wealthy today if I had become Mr. Emacs
and Emacs had mushroomed into a series of text processing applications and all kinds of stuff.
But I have a long history of financially suboptimal decisions
because I didn't want that life, right? And I went to grad school because I wanted to graduate.
And being Mr. Emacs for a while was kind of fun and then it kind of became
not fun. Not fun. And when it was not fun and I was, there was no way I could pay my rent,
right? Yeah. And I was like, okay, do I carry on as a grad student as a,
I had a research assistantship and I was sort of living off of that and I was trying to do
my, I was doing all my RA work, all my RA being grad student work and being Mr. Emacs all at the
same time. And I decided to pick one. And one of the things that I did at the time was I went
around all the people I knew on the ARPANET who might be able to take over looking after Emacs.
And pretty much everybody said, I got a day job. So I actually found two folks and a couple of
folks in a garage in New Jersey, complete with a dog who were willing to take it over.
But they were going to have to charge money. But my deal with them was that they would
only, that they would make it free for universities and schools and stuff. And they said,
sure. And you know that upsets some people. So you have some, now I don't know the full
history of this, but I think it's kind of interesting. You have some tension with Mr.
Richard Stallman over the, and he kind of represents this kind of, like you mentioned,
free software, sort of a dogmatic focus on. Yeah. All information must be free.
Must be free. So what, is there an interesting way to paint a picture of
the disagreement you have with Richard through the years?
My basic opposition is that when you say information must be free to a really extreme form
that turns into all people whose job is the production of
everything from movies to software, they must all take a vow of poverty
because information must be free. And that doesn't work for me.
Right. And I don't want to be wildly rich. I am not wildly rich. I do okay.
But I do actually, I can feed my children. Yeah. I totally agree with you. It does just
make me sad that sometimes the closing of the source, for some reason the people that,
like a bureaucracy begins to build, and sometimes it doesn't, it hurts the product.
Oh, absolutely. Absolutely. It's always sad.
And there is a balance in there. There's a balance.
And it's not hard over rapacious capitalism, and it's not hard over in the other direction.
And a lot of the open source movement, they have been managing to find the path to
actually making money. So doing things like services and support works for a lot of people.
And there are some ways where it's kind of, some of them are a little perverse. So as
a part of things like this Sarbanes-Oxley Act and various people's interpretations of all kinds of
accounting principles. And this is kind of a worldwide thing. But if you've got a corporation
that is depending on some piece of software, the often various accounting and reporting
standards say, if you don't have a support contract on this thing that your business is
depending on, then that's bad. So if you've got a database, you need to pay for support.
But there's a difference between the sort of support contracts that the average
open source database producer charges and what somebody who is truly rapacious like Oracle charges.
Yes, it's a balance. It is absolutely a balance. And there are a lot of different ways
to make the math work out for everybody. And the very unbalanced sort of like the
winner takes all thing that happens in so much of modern commerce. That just doesn't
work for me either. I know you've talked about this in quite a few places, but you have created
one of the most popular programming languages in the world. So there's a programming language
that I first learned about object oriented programming with. I think it's a programming
language that a lot of people use in a lot of different places and millions of devices today,
Java. So the absurd question, but can you tell the origin story of Java?
So a long time ago, it's on in about 1990, there was a group of us who were kind of worried that
that there was stuff going on in the universe of computing that the computing industry was missing
out on. And so a few of us started this project at Sun. We started talking about it in 1990 and
it really got going in 1991. And it was all about what was happening in terms of computing hardware
processors and networking and all of that that was outside of the computer industry. And that was
everything from the early glimmers of cell phones that were happening then to you look at elevators
and locomotives and process control systems and factories and all kinds of audio equipment and
video equipment. They all had processors in them and they were all doing stuff with them. And it
sort of felt like there was something going on there that we needed to understand. So C and C
plus plus was in the air already. Oh no, C and C plus plus absolutely owned the universe at that
time. Everything was written in C and C plus plus. So where was the hunch that there was a need for
a revolution? Well, so the need for a revolution was not about a language. It was just as simple
and vague as there are things happening out there. We need to understand them. We need to
understand them. And so a few of us went on several somewhat epic road trips.
Literal road trips? Literal road trips. It's like get on an airplane, go to Japan, visit
Toshiba and Sharp and Mitsubishi and Sony and all of these folks. And because we worked for
Sun, we had folks who were willing to give us introductions. We visited Samsung and
a bunch of Korean companies and we went all over Europe, went to places like Phillips and
Siemens and Thompson. And what did you see there? For me, one of the things that sort of left out
was that they were doing all the usual computer things that people had been doing like 20 years
before. The thing that really left out to me was that they were sort of reinventing computer
networking and they were making all the mistakes that people in the computer industry had made.
And since I'd been doing a lot of work in the networking area, we'd go and visit
the company X, they'd describe this networking thing that they were doing.
And just without any thought, I could tell them the 25 things that were going to be complete
disasters with that thing that they were doing. And I don't know whether that had any impact on
any of them. But that particular story of repeating the disasters of the computer science
industry was there. And one of the things we thought was, well, maybe we could do something
useful here with bringing them forward somewhat. But also, at the same time, we learned a bunch of
things from these mostly consumer electronics companies. And high on the list was that
they viewed their relationship with the customer as sacred. They were never ever
willing to make trade-offs for safety. So one of the things that had always made me nervous in the
computer industry was that people were willing to make trade-offs in reliability to get performance.
They want faster and faster. It breaks a little more often because it's faster. Maybe you run it
a little hotter than you should. The one that always blew my mind was the way that
the folks at Cray Supercomputers got their division to be really fast,
was that they did Newton-Raphson approximations. And so the bottom several bits of A over B
were essentially random numbers. What could possibly go wrong?
What could go wrong? And just figuring out how to nail the bottom bit, how to make sure that
if you put a piece of toast in a toaster, it's not going to kill the customer.
It's not going to burst into flames and burn the house down.
So I guess those are the principles that were inspiring. But how did, from the days of
Java is called oak, because of a tree outside the window story that a lot of people know,
how did it become this incredible powerful language?
Well, so it was a bunch of things. After all that, we started,
the way that we decided that we could understand things better was by building a demo,
building a prototype of something. So because it was easy and fun, we decided to build
a control system for some home electronics, TV, VCR, that kind of stuff. And as we were
building it, we sort of discovered that there were some things about standard practice in C
programming that were really getting in the way. And it wasn't exactly because we were
writing all this C code and C++ code that we couldn't write it to do the right thing, but that
one of the things that was weird in the group was that we had a guy who's his sort of top level
job was, he was a business guy. He was sort of an MBA kind of person, think about business plans
and all of that. And there were a bunch of things that were kind of, and we would talk about things
that were going wrong and things that were going wrong, things that were going right. And
as we thought about things like the requirements for security and safety,
some low level details in C like naked pointers. And so back in the early 90s,
it was well understood that the number one source of security vulnerabilities
was just pointers, was just bugs. And it was like 50, 60, 70% of all security
vulnerabilities were bugs. And the vast majority of them were like buffer overflows.
So you're like, we have to fix this. We have to make sure that this cannot happen.
And that was kind of the original thing for me was this cannot continue.
And one of the things I find really entertaining this year was, I forget which
rag published it, but there was this article that came out that was an examination, it was sort of
the result of an examination of all the security vulnerabilities in Chrome. And Chrome is like a
giant piece of C++ code. And 60 or 70% of all the security vulnerabilities were stupid pointer
tricks. And I thought, it's 30 years later, and we're still there. And we're still there.
And that's one of those, slap your forehead and just want to cry.
So would you attribute, or is that too much of a simplification, but would you attribute the
creation of Java to C pointers? Obvious problem. Well, I mean, that was one of the trigger points.
Concurrency you've mentioned. Concurrency was a big deal.
Because when you're interacting with people, the last thing you ever want to see is the thing like
waiting. And issues about the software development process, when faults happen,
can you recover from them? What can you do to make it easier to create and eliminate
complex data structures? What can you do to fix one of the most common C problems, which is storage
leaks? And it's evil twin, the freed but still being used piece of memory. You free something,
and then you keep using it. So when I was originally thinking about that, I was thinking
about it in terms of safety and security issues. And one of the things I came to understand was that
it wasn't just about safety and security, but it was about developer velocity. And I got really
religious about this because at that point, I had spent an ungodly amount of my life hunting down
mystery pointer bugs. And two thirds of my time as a software developer was because the mystery
pointer bugs tend to be the hardest to find because they tend to be very, very statistical.
The ones that hurt, they're like a one in a million chance. But nevertheless,
create an infinite amount of suffering. Right. Because when you're doing a billion
operations a second, one in a million chance means it's going to happen. And so I got really
religious about this thing about making it so that if something fails, it fails immediately
and visibly. And one of the things that was a real attraction of Java to lots of development
shops was that we get our code up and running twice as fast.
You mean like the entirety of the development process, the bugging, all that kind of stuff?
Yeah. So if you measure time from you first touch fingers to keyboard until you get your
first demo out, not much different. But if you look from fingers touching keyboard to solid piece
of software that you could release in production, it would be way faster.
And I think what people don't often realize is there's things that really slow you down.
Hard to catch bugs probably is the thing that really slows down that.
It really slows things down. But also one of the things that you get out of
object oriented programming is a strict methodology about what are the interfaces
between things and being really clear about how parts relate to each other. And what that
helps with is so many times what people do is they kind of like sneak around the side.
So if you've built something and people are using it and you say, well, okay,
I've built this thing. You use it this way. And then you change it in such a way that it
still does what you said it does. It just does it a little bit different. But then you find out
that somebody out there was sneaking around the side. They had sort of tunneled in a back door
and this person, their code broke because they were sneaking through a side door.
And normally the altitude is dummy. But a lot of times,
you can't get away. You can't just slap their hand and tell them to not do that.
Because it's somebody's, some bank's account reconciliation system that some developer
decided, oh, I'm lazy. I'll just sneak through the back door.
And because the language allows it, I mean, you can't even mad at them.
Right. And so one of the things I did that on the one hand upset a bunch of people
who I made it so that you really couldn't go through back doors. So the whole point of that
was to say, if the interface here isn't right, the wrong way to deal with that is to go through
a back door. The right way to deal with it is to walk up to the developer of this thing and say,
change the interface, fix it. And so it was kind of like a social engineering thing.
It was brilliant. And people ended up discovering that that
really made a difference in terms of, and a bunch of this stuff, if you're just like
screwing around right in your own class project scale stuff, a lot of stuff isn't quite so
important because you're both sides of the interface. But when you're building larger,
more complex pieces of software that have a lot of people working on them, and especially when
they like span organizations, having clarity about how that gets structured saves your life.
And especially there's so much software that is fundamentally untestable
until you do the real thing. It's better to write good code in the beginning
as opposed to writing crappy code and then trying to fix it and trying to scramble and
figure out and through testing, figure out where the bugs are. It's like which shortcut
caused that rocket to not get where it was needed to go. So I think one of the most beautiful ideas
philosophically and technically is of a virtual machine, the Java virtual machine.
Again, I apologize to romanticize things, but how did the idea of the JVM come to be?
How do you radical of an idea it is? Because it seems to me to be just a really interesting idea in
the history of programming. And what is it? So the Java virtual machine, you can think of it
in different ways because it was carefully designed to have different ways of viewing it.
So one view of it that most people don't really realize is there is that you can
view it as sort of an encoding of the abstract syntax tree in reverse Polish notation.
I don't know if that makes any sense at all. I could explain it and that would blow all over
time. But the other way to think of it and the way that it ends up being explained is that
it's like the instruction set of an abstract machine that's designed such that you can
translate that abstract machine to a physical machine. And the reason that that's important,
so if you wind back to the early 90s when we were talking to all of these companies doing
consumer electronics and you talk to the purchasing people,
there were interesting conversations with purchasing. So if you look at how these devices
come together, they're sheet metal and gears and circuit boards and capacitors and resistors and
stuff. And everything you buy has multiple sources. So you can buy a capacitor from here,
you can buy a capacitor from there, and you've got kind of a market so that you can actually get
a decent price for a capacitor. But CPUs, and particularly in the early 90s,
CPUs were all different and all proprietary. So if you use the chip from Intel,
you had to be an Intel customer till the end of time. Because if you wrote a bunch of software,
when you wrote software using whatever technique you wanted, and C was particularly bad about
this because there was a lot of properties of the underlying machine that came through.
So the code you wrote, you were stuck to that particular machine.
You were stuck to that particular machine, which meant that they couldn't decide Intel is screwing
us. I'll start buying chips from Bob's Better Chips. This drove the purchasing people absolutely
insane that they were welded into this decision. And they would have to make this decision before
the first line of software was written. That's funny that you were talking about the purchasing
people. So there's one perspective, right? There's a lot of other perspectives that all
probably hated this idea. But from a technical aspect, just like the creation of an abstraction
layer that's agnostic to the underlying machine from the perspective of the developer, that's
brilliant. So that's across the spectrum of providers of chips. But then there's also the
time thing because as you went from one generation to the next generation to the next generation,
they were all different. And you would often have to rewrite your software.
I mean, generations of machines of different kinds.
Yeah. So one of the things that sucked about a year out of my life was when
San went from the Motorola 68010 processor to the 68020 processor,
then they had a number of differences and one of them hit us really hard.
And I ended up being the point guy on the worst case of where the new instruction
cache architecture hurt us. Well, okay. So I mean, so one of this idea,
I mean, okay, so yeah, you articulate a really clear fundamental problem in all of computing.
But where do you get the guts to think we can actually solve this?
You know, in our conversations with all these vendors, these problems started to show up.
And I kind of had this epiphany because it reminded me of a summer job that I had had in grad school.
So back in grad school, my thesis advisor, well, I had two thesis advisors for bizarre reasons.
One of them was a guy named Raj Reddy, the other one was Bob Sproul. And Raj, I love Raj,
I love both of them. So the department had bought a bunch of early workstations
from a company called Three Rivers Computer Company. And Three Rivers Computer Company
was a bunch of electrical engineers who wanted to do as little software as possible.
So they knew that they'd need to have like compilers and OS and stuff like that. And they
didn't want to do any of that. And they wanted to do that for as close to zero money as possible.
So what they did was they built a machine whose instruction set was
literally the bytecode for UCSD Pascal, the P code. And so we had a bunch of software
that was written for this machine. And for various reasons, the company wasn't doing
terrifically well. We had all this software on these machines and we wanted it to run on other
machines, principally the Vax. And so Raj asked me if I could come up with a way
to port all of this software from the perk machines to Vax's. And I think he,
you know what, he had in mind was something that would translate from Pascal to C or Pascal to,
actually at those times, pretty much, you could translate to C or C. And if you didn't
like translate to C, you could translate to C. There was, it's like the Henry Ford,
any color you want, just as long as it's black. And I went, that's really hard.
And I noticed that, you know, and I was like looking at stuff and I went,
oh, I bet I could rewrite the P code into Vax assembly code. And then I started to realize
that, you know, there were some properties of P code that made that really easy,
some properties that made it really hard. So I ended up writing this thing that translated
from P code on the three rivers perks into assembly code on the Vax.
And I actually got higher quality code than the C compiler. And so everything just got really
fast. It was really easy. It was like, wow, I thought that was a sleazy hack, because I was
lazy. And in actual fact, it worked really well. And I tried to convince people that that was maybe
a good thesis topic. And nobody was, you know, it was like, nah.
Really? I mean, it's kind of a brilliant idea, right? Maybe you didn't have the,
you weren't able to articulate the big picture of it.
Yeah. And I think, you know, that was a key part. But so then, you know, clock comes forward a few
years. And it's like, we've got to be able to, you know, if they want to be able to switch from,
you know, this weird microprocessor to that weird and totally different microprocessor,
how do you do that? And I kind of went, oh, maybe by doing something kind of in the space of
you know, Pascal P code, you know, I could do like multiple translators.
And I spent some time thinking about that and thinking about, you know, what worked and what
didn't work when I did the P code to Vax translator. And I talked to some of the folks
who were involved in Smalltalk because Smalltalk also did a Vax code. And then I kind of went,
yeah, let's, I want to do that. Because that actually, you know, and it had the other advantage
that you could either interpret it or compile it. And interpreters are usually easier to do,
but not as fast as a compiler. So I figured, good, I can be lazy again.
You know, sometimes I think that most of my good ideas are driven by laziness.
And often I find that people, some of the people's stupidest ideas are because they're
insufficiently lazy. They just want to build something really complicated. It's like,
doesn't need to be that complicated. Yeah. And so that's how that came out.
And, you know, but that also turned into kind of a, you know, almost a religious position on my part,
which was, which got me in several other fights. So like, one of the things that was a real
difference was the way that arithmetic worked. You know, once upon a time,
there were, you know, it wasn't always just two's complement arithmetic. There were some machines
that had one's complement arithmetic, which was like almost anything built by CDC.
And occasionally there were machines that were decimal arithmetic. And I was like,
this is crazy. You know, pretty much two's complement integer arithmetic has one. So just,
let's just do that. Just do that. One of the other places where there was a lot of variability
was in the way that floating point behaved. And that was causing people throughout the
software industry much pain because you couldn't do a numerical computing library that would work
on CDC and then have it work on an IBM machine and work on a deck machine. And as a part of that
whole struggle, there had been this big body of work on floating point standards. And this
thing emerged that came to be called IEEE 754, which is the floating point standard that pretty
much has taken over the entire universe. And at the time I was doing Java, it had pretty much
completed taking over the universe. There were still a few pockets of holdouts, but I was like,
it's important to be able to say what 2 plus 2 means. And so I went that. And one of the
ways that I got into fights with people was that there were a few machines that did not
implement IEEE 754 correctly. Of course, that's all short-term kind of fights. I think in the
long term, I think this vision is one out. Yeah. And I think it worked out over time.
I mean, the biggest fights were with Intel because they had done some strange things with rounding.
They had done some strange things with their transcendental functions, which turned into a
mushroom cloud of weirdness. Yeah, in the name of optimization, but from the perspective of the
developer, that's not good. Well, their issues with transcendental functions were just stupid.
Okay. So that's not even a trade-off. That's just absolutely.
Yeah, they were doing range reduction for sine and cosine using a slightly wrong value for pi.
Got it. Go ahead, 10 minutes. So in the interest of time, two questions. So one about Android,
one about life. So one, I mean, we could talk for many more hours. I hope eventually we might talk
again. But I got to ask you about Android and the use of Java there because it's one of the many
places where Java just has a huge impact on this world. Just on your opinion, is there things that
make you happy about the way Java is used in the Android world? And are there things that
you wish were different? I don't know how to do a short answer to that,
but I have to do a short answer to that. So I'm happy that they did it.
Java had been running on cell phones at that time for quite a few years and it worked really,
really well. There were things about how they did it and in particular,
various ways that they violated all kinds of contracts. The guy who led it, Andy Rubin,
he crossed a lot of lines. There's some lines crossed.
Yeah, lines were crossed that have since mushroomed into giant court cases
and they didn't need to do that. In fact, it would have been so much cheaper for them to not cross
lines. I suppose they didn't anticipate the success of this whole endeavor. Do you think
at that time it was already clear that this is going to blow up? I guess I came to believe that
it didn't matter what Andy did, it was going to blow up. I started to think of him as a manufacturer
of bombs. Yeah, some of the best things in this world come about. They're a little bit of
explosive. Well, and some of the worst. And some of the worst, beautifully put.
But is there, and like you said, does that make you proud that the Java is in millions?
I mean, it could be billions of devices. Yeah. Well, I mean, it was in billions of phones
before Android came along. And I'm just as proud of the way that the smart card standards
adopted Java. Everybody involved in that did a really good job. And that's billions and billions.
That's crazy. The SIM cards in your pocket. I've been outside of that world for a decade,
so I don't know how that has evolved, but it's just been crazy.
So on that topic, let me ask, again, there's a million technical things
we could talk about. But let me ask the absurd, the old philosophical question about life.
What do you hope when you look back at your life and people talk about you, write about you
500 years from now, what do you hope your legacy is? People not being afraid to take a leap of faith.
I've got this kind of weird history of doing weird stuff. It worked out pretty damn well.
It worked out. And I think some of the weirder stuff that I've done
has been the coolest. And some of it crashed and burned. And I think well over half of the stuff
that I've done has crashed and burned, which has occasionally been really annoying.
But still you kept doing it. Yeah. And even when things crash and burn,
you at least learn something from it. By way of advice, people, developers,
engineers, scientists, or just people who are young to look up to you, what advice would you give
them? How to approach their life? Don't be afraid of risk. It's okay to do stupid things once.
Maybe about a couple of times. You get a pass on the first time or two
that you do something stupid. The third or fourth time, yeah, not so much.
But also, I don't know why, but really early on, I started to think about
ethical choices in my life. And because I'm a big science fiction fan,
I got to thinking about just about every technical decision I make
in terms of, are you building Blade Runner or Star Trek?
Which one's better? Which future would you rather live in?
So what's the answer to that? Well, I would rather live in the universe of Star Trek.
Star Trek, yeah. That opens up a whole topic about AI, but that's a really interesting idea.
So your favorite AI system would be data from Star Trek.
And my least favorite would easily be Skynet.
Beautifully put, I don't think there's a better way to end it, James. I can't say enough how much
of an honor it is to meet you, to talk to you. Thanks so much for wasting your time with me today.
Uh, not a waste at all. Thanks, James. All right, thanks.
Some words from James Gosling. One of the toughest things about life is making choices.
Thank you for listening and hope to see you next time.