The following is a conversation with James Gosling, the founder and lead designer behind the Java programming language, which in many instances 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 express VPN. Please check out the sponsors in the description to get this content 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 those things, subscribe.

I need to review it with five stars and other podcast. Follow on Spotify, support on Patrón. Connect with me on Twitter. Elex Friedemann, 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 time stamps. So go ahead and skip. 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 a public goods, the one stop shop for affordable, sustainable, healthy household products, I take their official 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 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.

Thought 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 a public goods that council selects. Are you scolex at checkout to get 15 bucks off your first order? This show is also sponsored by Better Help Spelled Help, help! Check it out, better health outcomes. Lex, they figure out what you need and match with a licensed professional therapist in under 48 hours.

I chat with the person on there and enjoy it. Of course, I also regularly talk to David Gorgons 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 in time and schedule weekly audio and video sessions. Check it out, better help, Dotcom's neglects. This show is also sponsored by Express CPN, you can use it to unlock movies and shows that are only available in other countries. I did this recently with Star Trek, Discovery and 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, 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 Express EPN, it lets you change your location to almost 100 countries and it's superfast, go to express a podcast expired to get an extra three months of express support for free.

That's express VPN dot 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 you find beautiful?

Oh, there's lots of things in math that's really beautiful. You know, 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 is this book called the 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 like.

Filling out checks, you know, or, you know, paying for things with credit cards, I would want to make the the receipt add up to an interesting number.

Is there some numbers that stuck with you? 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 40 to. Well, yeah. I mean, that one forty two is pretty magical. And then the rationals I mean but is there a square root of two story in there somewhere.

Well it's, it's like the only number that has destroyed a religion.

In which way. Well the, the pathic Orian's they, they believe that all numbers were perfect and you could represent anything as a as a, as a rational number. And in that in that time period the proof came out that there was no, you know, rational fraction whose value was equal to the square root of two.

And that 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 Gatland completeness theorems in the 20th century that ruined it once again for everybody. Yeah.

Although although although girdles theorem. You know, the lesson I take from Girls Theorem is not that, you know, there are things you can't know, which is fundamentally what it says, but, you know, people want black and white answers. They want true or false. But if you if you allow a three state logic, that is true, false or maybe. Then then life's good.

I feel like there's a parallel to modern political discourse in there somewhere, but yeah, let me let me ask, so with your kind of early love or appreciation of the beauty of mathematics, do you see a parallel between that world and the world of programming?

You know, programming is all about logical structure, understanding the the patterns that come out of computation, understanding sort of. I mean, it's often like, you know, the path through the graph of possibilities to find a short a short route. Meaning like find a short program that gets the job done thing, but so then on the topic of irrational numbers, do you see this programming?

You just painted it so cleanly.

It's sort of this trajectory to find like a nice little program. But do you see it as fundamentally messy? Um, maybe unlike mathematics?

I don't think of it.

I mean I mean, you know, you watch somebody who's good at math do math and. You know, often it's it's fairly messy, sometimes it's kind of magical. When I was a grad student, one of the students, his name was Jim Sax was. He had this, this, this, this. This reputation of being sort of a walking, talking human thare improving machine, and if you're having a hard problem with something, you could just like a costume in the hall and say, Jim preterit and he would do this, this this funny thing where he would stand up straight, his eyes would kind of defocus.

He'd go, you know, just just like, you know, like like something in today's movies. And then he'd straighten up and say and log in and walk away and you'd go, well, OK, so and Log-in is the answer. How did he get there? By which time he's down the hallway somewhere. Yeah, I they just the oracle, the black boxes gives you the answer.

Yeah. And then you have to figure out the path from the question to the answer. They can one of the videos I watched, you mentioned Don Knuth, uh, well, at least recommending his you know, his book is something people should read. Oh yeah.

But in terms of, you know, theoretical computer science.

Do you see something beautiful that has been inspiring to you?

Speaking of and in your work, I'm programming languages that in their whole world of algorithms and complexity and, you know, these kinds of more formal mathematical things, or did that not really stick with you in your programming life?

But it did stick pretty. Clearly for me, because one of the things that I care about is being able to. Sort of look at a piece of code and be able to prove to myself that it works, you know? And so so, for example, I find that I'm. I meant odds with many of the people around me over issues about like how you lay out a piece of software, you know, so so software engineers get really cranky about how they format the documents that are the programs, you know, where they put new lines and where they put, you know, the braces, the braces and all the rest of that.

Right.

And. I tend to go for a style that's very dense. Minimize the white space. Yeah, well, to maximize the amount that I can see at once, right? 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. Yeah. And people don't like that.

Yeah, I've had I've had multiple times when engineering teams have staged what was effectively an intervention, you know, where they invite me to a meeting and everybody's arrived before me and they sort 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 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, you know, it's almost like a piece of machinery with, you know, this connected to that and like these gears side. Yeah, yeah, I, I see them or more like that than I see the the the 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, well, just kind of like like it leaps off the page at me and. Yeah.

What are the inputs for the outputs. What the heck is this thing doing. Yeah. Yeah. Getting a whole vision of it. Can we go back into your memory, memory, long term memory access. What's the first program you've ever and. I have no idea what the first one was. I mean, I, I know the first machine that I learnt that I learned to program on or is it was a PDP eight. At the University of Calgary.

Do you remember the specs? Oh, yeah, so so the thing had four K of Ram nice 12 bit words. The clock rate was. It was about. A third of a megahertz. I said, and get to the to them, OK? Yeah, yeah, so, you know, we're we're like ten thousand times faster these days. And was this kind of like a supercomputer, like a serious computer for.

No, the people I was the the first thing that people were calling, like minicomputer. Got it. They were sort of inexpensive enough that a university lab could maybe afford to buy one. And was there timesharing 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 of the computer center, and it was.

It was bought as a part of a project to do computer networking, but, you know, 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 I could monitor, oh, this was way before monitors were coming.

So it was it was literally a model through teletype, OK, with a paper typewriter. OK, so the user interface wasn't very good. Yeah, yeah, it was 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. That's not the 10 or 12 billion that the machines have today.

So what does that I mean, feel like if you remember those? I mean, did you have kind of inklings of the 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?

That was just a call. It was just a toy. You know, I had always like building stuff. But one of the problems with building stuff is that you need to have parts, you know, you do have pieces of wood or wire or switches or stuff like that, and those all cost money.

And here you could build you could 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 and said, yeah, completely accessible, you don't need anything and anybody from anywhere could just build something really cool. Yeah.

I said, yeah, if you've got access to a computer, you can, you can build all kinds of crazy stuff and.

You know, and when you were somebody like me who had, like, really no money and I mean, I remember just lusting after being able to buy like a transistor, you know, and when I would do sort of electronics kind of projects that were mostly made done by, like dumpster diving for trash, you know.

And, you know, one of my big holes was 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. What do you use that for. I, I built a machine that played tic tac toe. Right out of relay's, of course, the thing that was really hard was that all the relays required a specific voltage, but getting a power supply that will would do that voltage was pretty hard. And since I had a bunch of trash television sets, I had to.

Sort of cobble together something that was. Wrong, but worked, so I was actually running these relays at three hundred volts and and none of the electrical connections were like properly sealed off.

Surprised you survived that period of your life? Oh, for so many reasons. For so many reasons. I mean, you know, you're you know, it's pretty common for teenage geeks to discover, oh, thermite. That's easy to make.

Well, I'm glad you did. But do you remember the do you remember what program in Calgary that you wrote? Anything that stands out and what language?

Well, so mostly the anything of any size was assembly code. And actually, before I learned assembly code, there was this programming language on the PDP called Focal Five and Tocal five was kind of like a really stripped down Fortran. And I remember playing, you know, building programs that did things like play blackjack or solitaire or for some reason or the things that I really liked were ones where they were just like plotting graphs. So something with like a function or a data, and then you plot it.

Yeah. Yeah, I did a bunch of those things and went, oh, pretty pictures.

And so this was like print out again. No, no monitors, right?

So it was like on a teletype. Yeah. So using something that's kind of like a typewriter. And then using those to plot functions.

So when I apologize to romanticize things. But when did you first fall in love with programming. You know, what was the first programming language like is serious maybe software engineer. We thought this is a beautiful thing.

I guess I never really thought of any particular language as being, like, beautiful, because it was never really about the language. For me, it was about what you could do with it. And, you know, even today, you know, people try to get me into arguments about particular forms of syntax for this or that, and I'm like, who cares? You know, it's about what you can do.

Not not not how you spell the word. And, you know, so back in those days, I learned like Peel one and Fortran and Kabalan and, you know, by the time that people were willing to hire me to do stuff, you know, it was mostly assembly code and, you know, pedicured assembly code and and Fortran code and control data assembly code for like the CDC, 64 hundred, which was an early guess supercomputer, even though that supercomputer has less compute power than my phone by a lot.

And that was mostly I said Fortran. Yeah, world.

That said, you've also showed appreciation for the greatest language ever that I think everyone agrees is Lisp.

Well, this was definitely on my list of the greatest ones that have existed.

The number one or I mean, are you I mean, you know, the you know, the thing is that it's that, you know, I wouldn't put it number one.

Now, is it the parentheses? What what do you know? Why do you not love about Lisp? Well, I guess the number one thing to not love about it is so freakin many parentheses. Yeah, on the on the love thing is, you know, out of those two 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 or thinking about it.

But, you know, so like like up the food chain for me and then from Lisp is simular, which a very small number of people have ever used.

But a lot of people, I think, had a huge influence. Right. And yeah, the programming. But in a similar way. I apologize if I'm wrong on this, but is that one of the first functional languages?

No, no. It was it was the first object oriented programming language. Got it. It's really where object oriented and languages sort of came together. And it was also the the language where code routine's first showed up as a part of the language. So you could have a programming style that was you could think of it as multiple sort of multithreaded with a lot of parallel parallelism, really, either ideas of parallelism in there.

Yeah. Yeah. So that was that was back, you know. S So the first stimulus back was simular 67 for like nineteen sixty seven.

Yeah. Wow. So it had, it had co routine's which are almost thread's. The thing about Kirkenes is that they don't have true concurrency so you can get away without. Really complex locking, you can't usually do curry routines on a on the multicore machine, or if you try to do corica routines on the multicore machine, you don't actually get to use the multiple cores at it. Either that or you, you know, because you start then having to get into the universe of, you know, semaphores and locks and things like that.

But, you know, in terms of the the style of programming, you could write code and think think of it as being multithreaded. The mental model was very much a multithreaded one and all kinds of problems you could approach very differently.

To return to the world of list for a brief moment, you at SEEM, you you've you wrote a version of Emax that I think was very impactful in the history of Emax.

What was your motivation for doing so at that time? So that was in. Like eighty five or eighty six.

I had been using Unix for a few years and most of the editing was this tool called ETTY, which was sort of an ancestor of VI, and it's a pretty good editor.

Not a good idea. Well, if if what you're using if your input device is a teletype, it's pretty good. Yeah, it's certainly more humane than Teko, which was kind of the the common thing in a lot of the tech universe at the time.

Tick tock, tick tock, tick tock, tick.

Oh, the text editor and corrector character had so many features and the original emacs came out as so Emax stands for editor Macro's and Teko had a way of writing macros. And so the original Emax from McTigue sort of started out as a collection of macros for Teco.

But then, you know, the these sort of iMac style got got popular originally at MIT and then people. Did a few other implementations of Emax that were. You know, the code base was entirely different, but it was sort of the philosophical style of the original Emax, what was the philosophy of Emax?

And by the way, were all the implementations always in C and then no.

And how does this fit into the picture now? So so the very first Emax was written as a bunch of macros for the Teko text. Wow. That's so interesting.

And the the the macro language for Teko was probably the most ridiculously obscure format. You know, if you just look at it HECO program on a on a page, you think it was just random characters. It really looks like just line noise, just kind of like latex or something.

Oh, this way.

Worse than a High-Tech way, way worse than latex. But you know, if you use Teko a lot, which I did, the teko 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 know, you get shift in control and all of those things. And it's just a way of very tightly encoding it. And mostly what Emacs did was it made that. That visual. Right, so one way to think of Teko is use Emax with your eyes closed.

Mm hmm.

Where you have to maintain a mental model of. You know, sort of a mental image, if you document, you have to go, OK, so the the cursor is between A and E and I want to exchange, though, so I do these these things. Right. So it almost it is almost exactly. The Emax command said, well, it's roughly approximate, roughly the same as the Max command said, but using emacs with your eyes closed.

So what Emax you know, part of what Emax added to the whole thing was, was being able to visually see what you were editing in a form that matched your document. And, you know, a lot of things changed in the in the command said it, you know, 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 it Amitav Lisp machine.

There was one done for MultiChoice and one somewhere. I got a got a summer job to work on the Pascal compiler for MultiChoice and that was actually the first time I used Emax. And and so right, the compiler so you work on compilers to this? Yes, I say yeah.

So I did a lot of work. You know, I mean, I spent like like a really intense three months working on this Pascal compiler, basically living in Emax, and it was it was the one written in maquilas by Bernard Greenberg. And I thought, wow, this is a just 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 so I wrote this this implementation of Emacs in C, because at the time C was really the only language that worked on on Unix.

On Unix. And you were comfortable with C as well. Oh yeah. That point. At that time, I had done a lot of C coding that this was in like 86. And. You know, it was running well enough to be it for me to use it to edit itself within a month or two, and then it kind of took over the university and and then spread and then. Yeah, and then it went outside. And largely because Unix kind of took over the research community on the on the on the ARPANET then.

And Emax was kind of the best editor out there. It kind of took over. And there was actually a brief period where I actually had log in IDs on every non-military host on the on the ARPANET, you know, 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? What was what? I mean, did you again, sorry for the silly question, but could you have possibly imagined that the the Internet would look like what it is today?

You know, some of it is remarkably unchanged. So one of the things that I noticed really early on, you know, when I was at Carnegie Mellon, was that a lot of social life became centered around the ARPANET. So things like, you know, between email and text messaging because, you know, text messaging was a part of the ARPANET really early on. There were no cell phones. But, you know, you're sitting at a terminal and you're typing stuff and essentially email or like what?

Well, it's just like a like a one line message. Right. So, so, so cool.

It's like chat. Like chat. Yeah, right. So it's like like sending a one line message to somebody. Right. And and so pretty much everything from. You know, arranging lunch to going out on dates, you know, was all like driven by social media. So you're right in the in the in the 80s, easier the phone calls. Yeah.

You know, and my life had gotten to where, you know. I was, you know, living on social media, you know, from like the. Early, mid 80s and. And so when when it sort of transformed into the Internet and social media explodes, I was kind of like, what's the big deal?

It's just a scale thing. It's it's right. The scale thing is just astonishing.

Yeah, but the fundamentals in some ways, the fundamentals have hardly changed. And, you know, the technologies behind the networking have changed significantly. The you know, the the the watershed moment of, you know, going from the ARPANET to the Internet and then people starting to just scale and scale and scale. I mean, the the the the scaling that happened in the early 90s and the way that so many vested interests fought the Internet.

Oh, interesting. What was the. Ah, because you can't really control the Internet.

Yes. The Internet. So, so, so fundamentally the you know, the cable TV companies and broadcasters and phone companies. You know, at the deepest fires of their being, they hated the Internet. But it was often kind of a funny thing because. You know, so so so think of a cable company. Right, most of the employees of the 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 in the cable companies, that view shifts because. Really, the business of the cable companies had always been selling eyeballs to advertisers. Right. And. You know, that view of of like a cable company didn't really dawn on most people who worked at the cable companies. But I mean, we you know, I had various dust ups with various cable companies where you could see, you know, in the stratified layers of the corporation that that this this this, this this view of, you know, the reason that you have, you know, cable TV is to capture eyeballs.

You know, there they didn't see it that way. Well, so so the people who the most of the people who worked at the phone company are at the cable companies, their view was that their their job was getting delightful content out to their customers and their customers would pay for them, would pay for that higher up. They viewed this as as a way of attracting eyeballs to them. And and then what they were really doing was selling the eyeballs.

There were glued to their content to the advertisers advertisers. Yeah, and so the Internet was a competition in that sense, right. And there were right.

Well, yeah.

I mean, there was one proposal that we. Said that we won detailed proposal that we wrote up, you know, back at that sun and in the early 90s that was essentially like, look, any but, you know, with with Internet technologies, anybody can become a provider of of content. So, you know, you could be distributing home movies to your parents or your cousins or your who are anywhere else. Right. So anybody can become a publisher.

While you were thinking about that already. That was like, yeah, that that was like in the in the early 90s.

Yeah. And we thought this would be great. You could you know, and the kind of content we were thinking about at the time was like, you know, home movies, kids essays, you know, stuff from like grocery stores or you know, you know that the aura or a restaurant that they could actually, like, start sending information about out. And that's brilliant. And the the the reaction of the cable companies was like. But no.

Because because then we're out of business, what is it about companies that because they could have just they could have been ahead of that way, they could have listened to that and they could say they didn't see a path to revenue.

You know, somewhere in there, there's a lesson for, like big companies, right? Like to to listen to to try to anticipate the renegade out there out of the box.

People like yourself in their early days of writing proposals about what this could possibly be.

Well, in that, you know you know, it wasn't you know, if you're in a in a position where you're making. Truckloads of money off of a particular business model. You know, the the the the whole thought of, like, you know, leaping the chasm, right, you know, you know, you can say, oh, new models that are more effective are emerging. Right. So like digital cameras versus film cameras. You know, I mean, why take the like, why take the leap, because you're making so much money off of film and, you know, in my past it's on one of our big customers was Kodak.

And I ended up interacting with folks from Kodak quite a lot. And they actually had a big digital camera research and, you know, digital imaging, business development group. And they knew that that, you know you know, you just look at the at the trend lines and you look at, you know, the emerging quality of of of these digital cameras. And, you know, you can just plot on the graph, you know, and it's like.

You know, sure, film is better today. But. You know, digital is is is is improving like this. The lines are going across and and, you know, at the point at which the lines cross is going to be a collapse in their business. And they could see that. Right. They absolutely knew that. The problem is that, you know, up to the point where they hit the wall, they were making truckloads of money.

Right. And when they did the math.

It never started to make sense for them to kind of lead the charge. And part of the issues for a lot of companies for this kind of stuff. Is that, you know, if you're going to leap over a chasm like that, like like with Kodak going from from film to digital, that's a transition that's going to take a while. We have we had fights like this with people over like smartcards, the smartcards fights were just ludicrous, but that's what visionary leadership comes in or something.

We roll in and say and take take the leap.

Well, it's it's partly take the leap, but it's also partly take the hit. Take the hit anyway.

So, so, so so you can draw all the graphs you want that show that you know, if we leap from here, you know, the, you know, on our present trajectory we're doing this and there's a cliff. If we force ourselves into it, 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 at a trough as you leave 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, take a big hit over some some quarter and many of these transitions. Involve a big hit for a 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 like like like they both did this thing of, you know. I don't care about the quarterly reports, I care about how many 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. Yes. How do they make that work?

I mean, Amazon will operate in the negative for a long time. It's like investing into the future. Right.

But, you know, you know, so Amazon and Google and Tesla and Facebook, a lot of those had what what amounted to patient money often because the there's there's like a charismatic central figure who has a really large block of stock and they can just make it so.

So and that happens just maybe a small tangent, but you've gotten a chance to work with some pretty big leaders. What are your thoughts about society, the mosque leadership on the Amazon side, Jeff Bezos, all of these folks with large amounts of stock and vision in their company?

I mean, their founders. Yeah, either either the complete founders or like early on folks and Amazon have taken a lot of leaps. And you know that probably at the time people would criticize as like, what is this bookstore thing? Why? Yeah.

And 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 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 it's just timing and timing and luck.

And, you know, you take companies like like like Tesla and really, you know, the original Tesla, you know, sort of pre Elon. It was kind of doing sort of OK, but but but he just drove them. And because. He had a really strong vision, you know, he would 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 this, so many people that oppose him on the Falcon wonder like the door from the engineering perspective, those doors are ridiculous.

It's like they are a complete travesty.

But but they're but they're exactly the symbol of what great leadership is, which is like you have a vision and you just got like if you happen to do something stupid, make it really stupid.

Yeah. And go all in. Yeah.

Yeah. And and, you know, to to my credit, he's a really sharp guy.

So going back in time a little bit to Steve Jobs. Yeah. You know, Steve Jobs was a similar sort of character who had a strong vision and was really, really smart. And, you know, and he wasn't smart about the technology parts of things. But but he was really sharp about the. The sort of human relationship between the relationship between humans and objects and but. He was a jerk, you know. Right. 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 that's that's the question. Right. So you take people like Steve, who was really hard on people. And and so the question is, was he really was he needlessly hard on people or was he just. Making people reach to. 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 was he had, he made people off and 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 like them. I could never work for them. Why do you think that?

Can you put into words the kind of tension that you feel would be destructive as opposed to constructive, though he said he'd yell at people, he'd call them names.

And you don't like that? No. No, I don't. I don't think you need to do that. Yeah. And. You know, I think, you know, there's 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 mosque. I know a number of people who have many of them have said and it's, you know, shows up in the press a lot that.

That mosque 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 become this there's come this 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. Yeah, right. And and 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.

You know, they they tend to. Not be in the public eye. The general public somehow lifts the jerks up into the into the hero status, right?

Well, because they do things that get them in the press. Yeah.

And, you know, the people who, you know, don't. Do the kind of things that spill into the press. Yeah, I just talked to Chris Lardner, um. 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 like a million technologies. But he also talked about the jerkiness of some of the folks. Yeah, yeah.

And the fact that being a jerk has become your required style.

But one thing that made me want to ask on that is maybe to push back a little bit. So there's the jerk side. But there's also if I were to criticize or I've seen a Silicon Valley, which is almost the resistance to working hard. So on the jerkiness side is. It so posted jobs and Ellen kind of pushed people to work really hard to do, and there's a question whether it's possible to do that nicely.

But one of the things that bothers me, maybe I'm just a Russian and just kind of, you know, romanticize the whole suffering thing. But I think working hard is is essential for accomplishing anything interesting, like, really hard.

And in the parlance of Silicon Valley, it's probably too hard. This idea of these you work smart, not hard often.

To me, sounds like you should be lazy because, of course, you want to be so smart. Of course it would be a maximally efficient but not to discover the efficient path that we're talking about with the short program.

Yeah, well, you know, the smart, hard thing isn't an either or it's an end as an end to.

Right. And. You know, the fact that. The people who say you should work smart, not hard. They pretty much always fail. Yeah. Thank you. Right, I mean, that's that's that's just just a recipe for disaster. I mean, there are there are counterexamples, but there are more people who benefited from the luck.

And you're saying, yeah, exactly. Like luck and timing, like you said, is often an essential thing. But you're saying, you know, you can be you can push people to work hard and do incredible work without without without being nasty.

Yeah. Without being nasty.

I think, um, Google is a good example of the leadership of Google throughout its history has been a pretty good example of not being nasty. Yeah.

I mean, the the the the twins, Larry and Sergei are both pretty nice people.

It's underpressure is very nice. Yeah. Yeah, yeah.

And you know, it's it's a culture of people who work really, really hard. Let me ask maybe a little bit of a tense question, we're talking about Emax. It seems like you've done some incredible work outside of Java. You done some incredible work that didn't become as popular as it could have because of like licensing issues and open source like there are issues. Um, is what are your thoughts about that entire mess?

Like what about open source now in retrospect, looking back, uh, about licensing, about open sourcing, do you think open source is a good thing or 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 it 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, you know, some some versions of that. End up saying that, but all all software engineers must take a vow of poverty.

Right, right. As though it's unethical to have money.

Yeah. To build a company to write and.

You know, there's a there's a there's a slice of me that actually kind of buys into that because, you know, people who make billions of dollars off of like a patent and the patent came from like, you know, literally at 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. You know, you see a lot of that in in like the the drug industry, you know, when.

You know, when you've got got got medications that cost, you know, cost you like one hundred dollars a day and it's like, no.

Yeah. So the the interesting thing about sort of opensource, what bothers me is when something is not opensource and because of that, it's a worse product. Yes.

So, like I mean, if I look at your just implementation of Emax, like that could have been the dominant implement. Like I use Emacs. That's my main idea. I apologize to the world by satellite and. You know, I could have been using your implementation of Emacs and why aren't I? So are you using the new Numax, I guess the default on Linux is that. Yeah, and that through a strange passage, started out as the one that I wrote.

Exactly. So it's it's still has. Right. Yeah.

Well, and part of that was because, you know, in the last couple of years of grad school. It it became really clear to me. That I was either going to be Mr. Emax forever or I was going to graduate. God, I couldn't actually do both. Was that a hard decision? That's so interesting to think about you as they get it's a different trajectory that could have happened.

Yeah, it's fascinating, you know, and maybe, you know, I could be fabulously wealthy today if I had become Mr. Emax and Emax had mushroomed into a series of text processing applications and all kinds of stuff. And, you know, I would have, you know, but. I have a long history of financially suboptimal decisions because I. Didn't want that life. Right. And, you know, I went to grad school because I wanted to graduate and.

You know, you know, being Mr. Emax for a while. Was kind of fun, and then it kind of became not fun, not fun, and, you know, when it was not fun and I was, you know, there was no way I could, you know, pay my rent right now. And and I was like, OK, do I carry on as a grad student, as you know? You know, I had a research assistantship and I was sort of living off of that.

And I was trying to do my you know, I was doing all my R.A. were all my R.A., you know, being grads work and being Mr. Emax 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, you know, all the people I knew on the the ARPANET who might be able to to to take over looking after Emax. And pretty much everybody said I got a day job.

So so I actually found, you know.

To folks and a couple of folks in a garage in New Jersey, complete with a dog, we're 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 upset 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 there, and he kind of represents this kind of, like you mentioned, free software.

Sort of a dogmatic focus on you all, all 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?

The years my my basic position is. That, you know, when you say information must be free to a really extreme form that turns into, you know, 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 and I don't. I don't want to be wildly rich. I am not wildly rich.

I do. OK. But I do actually, you know, you know, I've you know, 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 that people that like a bureaucracy begins to build and sometimes it doesn't.

It hurts the product. Oh, absolutely. Absolutely. It's so sad. And there's and there is a there is a balance in there that's a balance. And, you know, it's. It's not hard, hard over, you know, rapacious capitalism and and it's and it's not hard over in the other direction. And, you know, a lot of the the open source movement, they they have been magic to find the path to actually making money.

Right. So doing things like service and support works for a lot of people. You know, and there are some some ways where it's it's kind of. Some of them are a little a little perverse, right, so as. You know, a part of things like the 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 a corporation that is depending on some piece of software, you know, that often, you know, various accounting and reporting standards say if you don't have a support contract on this thing that that your business is depending on, then that's bad, you know, so so so, you know, if you've got a if you've got a database, you need to pay for support.

And and so but there's a difference between. You know, the sort of support contracts that, you know, the average open source database producer charges and what somebody who is truly rapacious, like Oracle charges.

Yes, it's it's a balance. It is. It is absolutely a balance.

And, you know, there are there are a lot of a lot of different ways to make the math work out for everybody. And, you know, the the very you know. An unbalanced sort of, you know, look like the winner takes all thing that that happens in so much of 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, the programming language that I first learned about object oriented programming with, uh, you know, I think it's of programming language that a lot of people use and 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 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, the really got going, and we started talking about it in 1990 and it really got going in 91. And it was all about. You know what was happening in terms of, you know, computing, hardware, you know, processors and networking and all of that, that was outside of the computer industry and that was everything from the the the sort of early glimmers of cell phones that were happening then to you know, you look at elevators and locomotives and process control systems in factories and all kinds of audio, audio equipment and video equipment.

They all had processors in them and they were all doing stuff with them. And and it and it sort of felt like. There was something going on there that we needed to understand. And so C, C and C++ is in the air already in C++, absolutely owned the universe at that time, everything was written in C and C++.

So where was the hunch that there was a need for a revolution?

Well, so the need for a revolution was not about the language. It was about it was just as simple and vague as there are things happening. Out there, when we understand them, we need to understand them and 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, you know, Toshiba and Sharp and Mitsubishi and Sony and all of these folks.

And, you know, because we worked for Sun, we had, you know, folks who were willing to like, give us introductions. You know, we we visited, you know, Samsung and, you know, a bunch of Korean companies. And we went all over Europe, went to, you know, places like like Philips and Siemens and Thompson.

And what did you see there? You know, for me, the one of the things that sort of left out was that they were doing all the usual computer computer things that people had been doing like 20 years before. The thing that really leapt 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 had made and since I had been doing a lot of work in the networking area, you know, you know, we'd go and visit, you know, Company X, they describe this networking thing that they were doing.

And just without any thought, I could I could tell them, like the twenty five 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 but but that particular story of, you know, sort of. Repeating the disasters of the computer science industry was there, and we and one of the things we thought was. Well, maybe we could do something useful here with, like, bringing them forward somewhat, but but also at the same time we learned a bunch of things from from these, you know, mostly consumer electronics companies and.

You know, high on the list was that. They viewed their, like, relationship with the customer as sacred. They they were never, ever.

Willing to make trade offs between. For her safety, it's 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. You know, the you know, they want faster, faster breaks a little more often because it's faster and maybe you run it a little harder than you should or like like the one that always blew my mind was the way that the folks at that Cray supercomputers got their division to be really fast was that they did Newton Graphs and approximations.

Huh. And so, you know, the bottom several bits of, you know, a Overbey were essentially random numbers.

What could possibly go wrong? What could go wrong. Right.

And, you know, just figuring out how to nail the bottom bit, how to make sure that, you know, 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 those are I guess those are the principles that were inspiring. But how did from the days of Java is called OK, because of a tree outside the window so that a lot of people. Now, how did it become this incredible, like, powerful language?

Well, so it was a bunch of things. So we you know, after all that we started, you know, the way that we decided that we could understand things better was by building a demo, building a prototype of something. So kind of because it was easy and fun, we decided to build a control system for some home electronics, you know, TV, VCR, that kind of stuff. And as we were building it, we you know, we sort of discovered that there were some things about standard practice in C programming.

That. We're really getting in the way and and it wasn't it wasn't exactly because we were writing this all the C-code and C++ code that. 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 who's who's. You know, his sort of top level job was he was a business guy, you know, he was sort of an MBA kind of person, you know, think about business plans and all of that and.

You know, there were a bunch of things that were kind of, you know, we would talk about things that were going wrong and things that were going wrong, things that were going right. And, you know, as we thought about, you know, things like like the requirements for security and safety, some low level details and see like naked pointers. Yeah. And. You know, so so back in the early 90s, it was well understood that, you know, the number one source of, like, security vulnerabilities at this point was just pointers, was just bugs and.

Right. And it was like, you know, 50, 60, 70 percent 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 this cannot continue. And one of the things I find really entertaining this year was I forget which published it. But there was this article that came out that was an examination. It was sort of the result of of an examination of all the security vulnerabilities in Chrome. And Chrome is like a giant piece of C++ code.

And 60 or 70 percent of all the security vulnerabilities were stupid pointer tricks. And I thought it's 30 years later and we're still there, though there and we're still there. And, you know, that's one of those, you know, slap your forehead and and just just 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 to see point?

It's obvious problem. Well, I mean, that was that was one of the the trigger points. And Steve mentioned concurrency was a big deal, you know, because when you're interacting with people, you know, the last thing you ever want to see is, is the thing like waiting and, you know, issues about the software development process. You know, 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, you know, one of the most common C problems, which is storage leaks and its its evil twin, the the the friede, but still being used piece of piece of memory. You know, you free something and then you keep using it. Oh yeah. You know, so, so when I was originally thinking about that I was thinking about that in terms of. Of sort of safety and security issues, and one of the things I sort of came to believe came to understand was that it wasn't just about safety and security, but it was about developer velocity.

Right. So and they got really religious about this because at that point, I had spent an ungodly amount of my life. Hunting down mystery pointer bugs. Yeah, and, you know, like like two thirds of my time as a software developer was because that mystery pointer bugs tend to be the hardest to find because they tend to be very, very statistical. The ones that hurt, you know, they're you know, they're like a one in a million chance.

And but nevertheless create an infinite amount of suffering. Right. Because when you're doing a billion operations a second. Yeah. You know, one in a million chance means it's going to happen. And so I got really religious about this thing about, you know, making it so that if something fails, it fails immediately and visibly. And, you know, one of the the things that was a real attraction of Java to lots of development shops was that, you know, we get our code up and running twice as fast.

You mean like the entirety of the development process, the being, all that kind of stuff? Yeah, if you you so so if you measure time from, you know, you first touch fingers to keyboard until you get your first demo out. I. Not much different, but if you look from fingers touching keyboard to solid piece of software that you could release in production, there would be way faster.

And I think what people don't often realize is, yeah, there's things that really slow you down, likes hard to catch bugs probably is is the thing that really slows down, that really slows things down.

But but also there were you know, one of the things that you get out of object oriented programming is a strict methodology about, you know, 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 then and you say and you say, well, look, you know, I built this thing, you use it this way and then you change it in such a way that that it still does what you said it does.

It just does it a little bit different. Then you find out that somebody out there was sneaking around the side. They sort of huddled in a back door and this person, their code broke. And because they were sneaking through a side door and. And normally the attitude is to dummy, but a lot of times, you know. You can't get away, you can't you can't just slap their hand and tell them to not do that because it's.

You know, somebody is. You know, some banks, you know, account reconciliation system that that, you know, some developer decided, oh, I'm lazy, you know, I'll just sneak through the back door.

And because the language allows it, I mean, you can't even get mad at them.

And so one of the things I did that on the one hand upset a bunch of people was that I made it so that you really couldn't go through back doors. Right. So the whole point of that was to say, if you need the interface here isn't right, the wrong way to deal with that is, is to go through the 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.

Right. And so it was kind of like a social engineering thing and it's brilliant.

And people ended up discovering that that really made a difference in terms, you know, and a bunch of this stuff, you know, if you're just like screwing around right in your own like, you know, class project scale stuff, a lot of stuff doesn't isn't quite so, so important because, you know, you're, you know, both sides of the interface.

But, you know, when you're building, you know, sort of. Larger, more complex pieces of software that have a lot of people working on them, and especially when they expand organizations. You know, having having really clear having clarity about how that gets structured saves your life. Yeah. And, you know, especially, you know, there's so much software that is fundamentally untestable, you know, and, you know, 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 to figure out where the bugs are.

Yeah, it's like it's like it's like with a shortcut cause that rocket to not get where it was to go.

So I think one of the most beautiful ideas, philosophically and technically is of a virtual machine is the Java Virtual Machine. Again, apologize to romanticize things, but how did the idea of the JVM come to be?

How to you radical of an idea is because it seems to me to be just a really interesting idea in the history of programming. So. 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 of our time. But the other way to think of it and the way that it ends up being explained is that it's it's like the 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 win back to the early 90s when we were talking to all of these these companies doing consumer electronics.

And you talked to the purchasing people. There were interesting conversations with purchasing. So if you look at how you know these you know, these devices come together, they're the sheet metal and gears and circuit boards and capacitors and resistors and stuff. And everything you buy has multiple sources, right, so you can buy a capacitor from here, you can buy a capacitor from there, and you've got kind of a market. So, you know, so that the you can actually get a decent price for a capacitor.

But CPU's, and particularly in the early 90s. CPU's were all different and all proprietory, so if you use the chip from Intel. You had to be an Intel customer for the end till the end of time, because if you wrote a bunch of software, you know, when you wrote software using whatever technique you wanted and C was particularly bad about this big because there was a lot of. Properties of the underlying machine that came through, so for stocks, for the euro, you're stuck to that particular machine, you were stuck to that particular machine, which meant that they couldn't decide, you know, Intel is screwing us all.

I'll start buying chips from. You know, Bob's better chips. This drove the like the purchasing people absolutely insane. That that they would they were welded into this decision and would they would have to make this decision before the first line of software was written.

It's funny that you're talking about the purchasing power. So that's one perspective, right? It's you could there's a lot of other perspectives that all probably hated this idea. Right. 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, I mean, that's brilliant, right?

Well, and and and, you know, so that's like across the spectrum of providers of chips. But then there's also the time thing, because, you know, as you went from one generation to the next generation to the next generation, there were all different. And you would often have to rewrite your software.

I mean, generations of copy of machines of different kinds. Yeah.

So so like like like one of the things that sucked about a year out of my life was when the sun went from the the Motorola 68 OTAN processor to the 68 or 20 processor. Then they had a number of differences and one of them hit us really hard. And I ended up being the the point guy on the worst case of where.

The new instruction, cash architecture hurt us well, OK, so I mean, one of this idea, I mean, OK, so yeah, you articulate a really clear fundamental problem in all of computing, but how do you get the guts to think we can actually solve this?

You know, in our conversations with, you know, all of these vendors, you know, these 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 my thesis advisor, well, I had to thesis advisers for bizarre reasons. One of them was a guy named Raj Reddy.

The other one was Bob Sproul and. Roger, I love you, I love both of them, right? So the.

The department had bought a bunch of. Like early work stations 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 they built a machine whose instruction set was. The was literally the bytecode for UCSC, Pa., the Piccard and. So we had a bunch of software that was that was written for this machine and for various reasons.

You know, the company wasn't doing terrifically well, we had all of this software on these machines and we wanted it to run on other machines, principally the backs. And and Saraj asked me if I could come up with a way.

To support all of this software translation from the from from from the the the the machines to vaccines. And I think he. You know, what he had in mind was something that would translate from like Pascal. To see. Or Pascal, to actually hit those times, pretty much it was you could translate to C or C, and if you didn't like translate to see, you could translate to see if there was you know, it's like the Henry Ford, you know, any color you want it just as long as it's black.

And and I went. That's really hard to say, and I and I noticed that, you know, and I was like looking at stuff when I went. Oh, I bet I could rewrite the code into VACC Assembly code. And. And then I started to realize that there were some properties of peacoat that made that really easy. Some properties that made it really hard. So I ended up writing this thing that translated from from peacoat on the Three Rivers percs into assembly code on the backs.

And I actually got higher quality code than the C compiler. And so so everything just went 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 and I tried to convince people that that was maybe a good thesis topic. Yeah. And nobody was what was you know, it was like now early this I mean, yeah, it's it's kind of a brilliant idea right now.

Maybe you didn't have the you weren't able to articulate the big picture of it. Yeah. And I think that was a.

A key part, but so then 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, peacoat, you know, I could do you like multiple translators and I spent some time thinking about that and thinking about what worked and what didn't work when I did, the the the the peacoat tiebacks translator and I talked to some of the folks who are involved in small talk because small talk also did about code.

And and then I kind of went. Yeah, I want to do that because that know, and it had the 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?

You know, sometimes I think most of my good ideas are driven by laziness, and often I find that people some people stupidest ideas are because they're insufficiently lazy and they just want to build something really complicated.

Doesn't need to be that complicated. Yeah. And so and so that's how that came out. Mm hmm. And, you know, but that also turned into kind of almost a religious position on my part, which was which got me in in several other fights. So like like one of the things that was a real difference was the way the arithmetic worked. You know, once upon a time there, you know, it wasn't always just to complement arithmetic.

There were some machines that had one 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 to complement integer arithmetic as one. So just. Let's just do that just to do that, one of the other places where there was a lot of variability was in the way that 14. 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 on a desk machine.

And as a as a part of that whole struggle, there had been this this big body of work on on 14. standards. And this thing emerged that came to be called, I believe, 754, which is the floating point standard that pretty much has taken over the entire universe. And at the time I was doing job, it had pretty much completed taking over the universe, there were still a few pockets of holdouts. But I was like, you know, it's important to be able to say what two plus two means.

Yeah.

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, I believe, 754 correctly. Of course, that that's all short term kind of fights, I think, in the long term, and I think this vision is one out.

Yeah, and I think it's it worked out over time. I mean, the the biggest fights were with Intel because they had done some strange things with rounding. They've done some strange things with their transcendental functions, which turned into a mushroom cloud of, you know, weirdness and the name in the name of optimization.

But from the perspective of the developer, that's not that's not good.

Well, they're issues with transcendental functions were just stupid that because there's not even a shred of. That's just absolutely. Yeah, they were they were doing range reduction and for sine and cosine using a slightly wrong value for PI.

Got ten minutes in the interest of time to 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, you know, 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. Kind of, you know, violated all kinds of contracts, the guy who who led it?

Andy Rubin, it crossed a lot of lines.

There's some lines crossed. Yeah, lines were crossed, but have since, you know, mushroomed into giant court cases. And, you know, they didn't need to do that. And in fact, it would have been so much cheaper for them to not cross lines.

I mean, I suppose they didn't anticipate the success of this whole endeavor. Or do you think at that time it was really clear that this is going to blow up? I guess I sort of came to believe that it didn't matter what Andy did, it was going to blow up.

OK, you know, I kind of started to think of him as as like a manufacturer of bombs.

Yeah. Some of the best things in this world come about. They're a little bit of, uh, explosive. Well, in some of the worst and some of the worst.

Beautifully put. But is there and like you said, I mean, does that make you proud that the Java is in. Yeah, it's in millions. I mean, it could be billions of devices and.

Yeah, well, I mean, it was in in billions of phones before Android came on. And, you know, I'm I'm just as proud as you know of the way that, like the the smart card standards adopted Java. And they did it. They, you know, everybody involved in that did a really good job. And that's, you know, billions and billions. It's crazy.

The SIM cards, you know, the SIM cards in your pocket. Yeah. I mean, I've been outside of that world for a decade, so I don't know how that has evolved. But, you know, 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 the people talk about you, write about you five hundred years from now, what do you hope your legacy is?

People not being afraid to take a leap of faith. I mean, you know, I've got this this kind of weird history of doing weird stuff and it worked out pretty damn well. It worked out right. And I think some of the weirder stuff that I've done has been the coolest. And some of it some of it crashed and burned. And, you know, I think well over half of the stuff that I've done has crashed and burned, which is occasionally been really annoying.

But still, you keep doing it.

Yeah, yeah, yeah. And, you know, there you know, even when things crash and burn, you at least learn something from it by way of advice.

You know, people, developers, engineers, scientists are 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 OK to do stupid things once, maybe a couple of times. You know, you get you get a pass on the first time or two that you do something stupid, you know, the third or fourth time. Yeah, not so much.

But also, you know. I don't know why, but really early on, I started to think about ethical choices in my life. And because I am a big science fiction fan, I got to thinking about, like just about every technical decision I make in terms of how do you, you know, are you building Blade Runner, Star Trek?

Which one's better?

Which which future would you rather live in? You know, so what's the what's the answer to that?

Well, I would say I would sure rather live in the universe of Star Trek. Star Trek. Yeah.

That opens up a whole topic about A.I. But that's a really interesting. Yeah, yeah. Yeah. It's a really interesting idea. So your favorite A.I. system would be data from, uh, from Star Trek, as my least favorite would easily be Skynet.

Yeah, 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 to meet you, to talk to you. Thanks so much for wasting your time with me today. Not a waste at all.

Thanks, Jason. All right. Thanks. Thanks for listening to this conversation with James Gosling, a thank you to our sponsors, Public Goods Better Help and express VPN. Please check out these sponsors in the description to get a discount and to support this podcast. If you enjoy this thing, subscribe. I need to review it with five stars and up a podcast. Follow on Spotify, support on Patrón or connect with me on Twitter, Allex Friedman. And now let me leave you with 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.