#242 Dean Tribble between innovation and reinventing the wheel
Transcript
⚠ The following transcript was automatically generated.
❤ Help us out, Submit
a pull-request to correct potential mistakes
Dean Tribble 0:00
The requirements of programming are fundamental and are largely not entirely independent to the language languages can provide some new abstractions. But you know, fundamentally, there's a conditional or choose operation, where you can choose A or B. And fundamentally, there's a given a collection of things, do something for all of them. You know, when when you're looking at a new language, you can orient yourself by sort of some of those core concepts, and then be able to write something and learning language quickly. So programmers need to get that level of internalization of the concepts of computation, so that they're in order to be a good programmer. And that's sort of the architectural level. And you know, what's a dependency? Not? Did I say import that file, right? If I'm having two strings that have to be the same in two files, that's a dependency and now you just didn't report it? Right? But But understanding, you know, internalizing the notion of a dependency, it's an example of an architectural thing. You just, you just have to have to learn.
Tim Bourguignon 0:54
Hello, and welcome to developer's journey, the podcast, bringing you the making of stories of successful software developers. To help you on your upcoming journey. I'm your host team building you. On this episode 242. I received Dean Tribble from right after high school, Dean has founded multiple companies and developed an array of software products, most of which, involving large scale, distributed systems, smart contracts, and novel computer security. He is now the CEO of agric, a proof of stake blockchain platform for smart contracts. And that's a mouthful, actually, Dean coupe. Welcome to the afternoon.
Dean Tribble 1:33
Thank you for having me.
Tim Bourguignon 1:34
Oh, it's my pleasure. Even though I'm reading bios, I know why this just doesn't work all these words. But before we come to your story, I want to thank the terrific listeners who support the show every month, you are keeping the dev journey lights up, if you would like to join this fine crew, and help me spend more time on finding a nominal guests then editing audio tracks, please go to our website, Dev journey dot info, and click on the Support me on Patreon button. Even the smallest contributions are giant steps toward a sustainable dev journey. journey. Thank you. And now back to today's guests. So Dean, as you know, the show exists to help listeners understand what your story looked like and imagine how to shape their own future. So as as usual on the show, let's go back to your beginnings. Where would you place the start of your journey?
Dean Tribble 2:30
I would say it has to be reading science fiction in elementary school, who might lane or actually doc Smith has, you know, it's one of those, there was a series of books where you could solve problems by building cool technology and inventing cool technology. And so I wanted to do robots I found a building a basic robot, actual you know, book and went and bought transistors and resistors and motors and all this sort of thing then and you know, wanted to try putting that together. But clearly the main the way to make all of these work was to build the you know, software Hooper brain that can control these things. And that was sort of the, the the child's vision of it, I then in sixth grade, so I was what 10 Nine, whatever it is, read the shirt, blue paper, Terry Winograd thesis, shirred Lu was the blocks world where you would type in, you know, move the blue block into the red box, or whatever it is, and it would figure out how to do that. So some of the early light English language understanding programs, and his thesis was fabulous, because in addition to talking about this AI model, in the graphics model, it talked about Lisp and Prolog basically, how to do a simple language and explain that, then explain how you use it to do this thing. And I learned more about English grammar by understanding how these Lisp programs would deconstruct an English sentence are represented and and learned about Prolog essentially, because he had this, you know, prolog, like pattern matching written in Lisp and stuff like that. So this was no computers involved, but I was learning software learning how you could have computers do amazing things, from Terry Winograd thesis, which I suspect is still well worthy of reading for new new programs. So that was sort of my introduction to the idea that one could do this. My elder brother, you know, got involved in software. And suddenly, you know, there were this is now back in the 70s. Right, there's a long time ago, there are now you know, P eight, you know, one of these ancient things and as toggle switches on the front of it. And so there's like, oh, flashing lights, you can make them flash the way you want. So that was kind of how I got into into the idea of software. And it was clearly the thing I wanted to do. You had such ability to change the world by writing code. I mean, you know, how awesome was that?
Tim Bourguignon 5:01
We can hear you in your voice and your four year right now, being back there, which is awesome. I do want to date you. But indeed it was it was the early days where you didn't have that many building blocks, you had to buy the components on your own you had to start from scratch.
Dean Tribble 5:16
You buy he's getting build up your heat get thing, there was a soul 20 So there's lots of builder yourself kind of computers inside ADHD. I still remember I'll hear songs, right from the era. And it will remind me of like two or three weeks, I had this horrible flu. But I had just gotten the hardware manual for an S 100 Bus computer. So what else could I do? But you know, pull out the motherboard and look at the manual and figure out you know, how it all work? Because it was you know, I couldn't leave my bed. There was nothing else to do. I would just you know, so I remember, you know, reading what, you know, like an mccaffrey's Dragonriders series and and the inside in the MDS 100. Bust technical manuals. And, and I mean, that might have been two different illnesses, and I blurred them together. But but but but, but I that's what that that music ends up reminding.
Tim Bourguignon 6:05
Awesome. Exactly the same thing was last year, which was that Ayn Rand, I think, oh, that's rug. Yeah. And I read it and listening to the same CD again, and again and again. And now every time I hear one of these songs, I'm just in that book again. Which is nuts. Brain brains are nuts. Did you know that this would be your life right away?
Dean Tribble 6:30
Oh, yeah, I think so. I mean, I'm pretty, you know, the, but I expected my original focus was on like, AI kinds of things, because I originally got, you know, built robots. And then I wanted to write software to control robots, right? Then, you know, got in high school and actually got, you know, a job doing software stuff in high school, which was low level system. You know, I mean, I was I was sort of the, the assistant tech for fourth Inc. Right. Fourth is language that was created for controlling telescopes, but it's used very, very, very small memory footprint, and, you know, for using device control, it's actually at the base of the bootloader. For Apple, right, you know, and, and so it's, it is a, it is a tool that's been around for a long time. But you know, in high school, we used RPN, calculators, the HP calculators, so stack language made sense to me, I was explaining this to someone that I was working on a programming language that used a stack wasn't that awesome? And they're like, have you seen fourth? One? So I learned the fourth language. So when I was 15, and a half, and could get a job or whatever, I went over to fourth Inc, and said, I work here. And they made me a junior, you know, admin to the tech guy who, and I was, you know, dragging network cables from room to room. And, you know, and moving large disk packs around, you know, and eventually, I got to write some fourth as a disk driver for interrupt dip driven scuzzy driver for the PDP 11. That was the first first professional software I wrote. Yes, when I was 15, and a half, so you know, almost 16. And it and I could not get into work, because the scuzzy hardware that I have turns out it's interrupt system was flaky. And so I wasn't getting anywhere. It was very embarrassing that sitting there trying to interrupt different thing, and I have to pull it's like,
Tim Bourguignon 8:13
that's how you did it before. And that's that's the state of the art back then. That is beginning of the 80s. Something like this.
Dean Tribble 8:21
Yeah. Something like that. Yeah. Wow.
Tim Bourguignon 8:25
If I have a cheating, you call that cheating, cheating paper on the side, so I can see your resume. So that around that time you started working at Xerox PARC?
Dean Tribble 8:35
Yes. So I went to so I went to Xerox PARC. So I worked at fourth and then I went to Aerospace Corporation, Aerospace Corporation is like random. It's a it's a research company for space and technology for the government. And it is one of the places that had the early ARPANET. So at Aerospace Corporation, I, you know, I did lots of you know, I mean, I remember running, you know, putting up microwave things and running wires for having, you know, and we had, you know, 19, two kilobyte modems, they were like the very first ones that were giant like this, and could do this amazing 19 two speed when everyone else is at 300 baud, and you know, but those were professional installations from built building the building. But we had one of the original ARPANET nodes. So when they were like, you know, I mean, you had a text file that listed them all, there were a few 100. Right, so and we had one of them. But the other thing we had is we had one of the Xerox dolphin computers that had Smalltalk on it. So this is the first realization of small talk, and I got exposed to small talk and went, Oh my gosh, I must programming this. This is awesome. This was the first machine that had windows and a mouse. I mean, it was just you know, and Xerox had, you know, like the second laser printer ever created. And the first one of the and one of the early one of these things. So it was just awesome. You know, oh, these came from Xerox PARC. I have no idea who that is. But I want to go work in small talk. And it's a band you know. So but but okay, So, just out of high school, I had the opportunity to start a startup company though. So I did not go to Xerox PARC. Immediately I went and started a startup company to do a vector graphics gaming system. This was funded, it was very small, but funded by Nolan Bushnell, who started Atari. And you know, he had a tax write off, so we, you know, put some money on a on a high school student. But the way that started going back to the robots thing, which I don't think I've talked about this, I was at an event for, you know, valedictorians or whatever, that had a bunch of people that had succeeded to bring together with people who might succeed, or, you know, had done something good in high school or whatever. I mean, there were there were there were some really awesome people there. But the two most tour two of the most memorable were Nolan Bushnell and Steve Wright, where this is a few years after Nolan had told Steve No, I don't want to invent I don't want to build this apple thing here. You know, that computer idea at Atari. And so Steve spun off. So it was very entertaining to see them both presenting to this audience of kids, you know, positioning themselves, but anyway, as soon as no one had was just starting on, you know, he had finished Atari had left that. And he was just starting his pizza franchise, they had lots of animatronics and robots. So as soon as he finished talking about, you know, I've got an excuse to do robots and have robots interact with kids. I had come from doing robots. So he immediately ran over to him, sat down next to him and said, I've been working on robots tell me about robots, right. And so we just got to talking and he ended up funding, you know, we talked about gaming, we talked about robots, and he ended up funding this this startup company to do and we just, you know, wanted to find some way to do something together. And so he you know, there was this, you know, opportunity to do vector graphics for the consumer market, you know, basically the next generation after dude as a as a console, you could just take it home and plug in and now you can play and so we started working on that, and it didn't pan out so I'm gonna be just a market and so it shut down and then I had to go to college. And so I went Smalltalk Xerox PARC, what's the nearest college Stanford? Great. I'll apply there
Tim Bourguignon 12:07
before we get there this sounds completely nuts somebody investing on an on a high school student to do a vector graphics was it no
Dean Tribble 12:16
what No, but you know, there was definitely you know, there was definitely a side comment to Larry kala who was his AOL at the time of the flavor we need a tax write off can we do this okay, great. Let's do this. I mean to a kid 100k Isn't this amount of money and in the 80s you know, that was that was you know, coming from coming out of having catalysts, which was their big VC incubator where they're talking you know, millions per setup 100k to do something kind of cool that they could point out that was probably pretty easy. But I'm you know, I just you know, I can't I can't You can't imagine just how much I appreciated the time how unique this one so no, it was definitely not never gore. So what is this Silicon Valley thing? This is like crazy I'm gonna go up there I'm gonna you know, when we visited got the tour, you know, talk to you know, Alcor to create it was the other grader Paul and lots of others. And and, you know, there was the map company, the time began with a e cat or something like that, where a lot of this mapping, you know, doing having a navigation map in your car for started so there's all sorts of really cool stuff that was going on there. You just got to get washed out, washed over you.
Tim Bourguignon 13:28
This is like looking at history book actually. So you were seeing so obviously you went to Stanford and next College in town, just round was it in Terry Winograd
Dean Tribble 13:41
unshare remember, I read Terry Winograd thesis and you know, and, and Terry Winograd was there as well, as were a few other Doug Lennon was there who was, which was another awesome AI. And I always thought I would go into software to do AI. So that was awesome. So I showed up at Stanford, like the first week, I wandered into Terry's offices explained, having read his thesis so long ago, and asked him to be my advisor. So I didn't know what you get with an advisor, but but I knew I was supposed to have one. So I was so you know, you know, I was so clueless about college at the time, it sort of it is, it is only not embarrassing, because I look back and realize how silly all of us were at the time, but you know,
Tim Bourguignon 14:19
it's the innocence of the of the younger of the younger. You do think sometimes you don't, afterwards you realize why I do that. But
Dean Tribble 14:28
But I think the two, I mean, a couple of those key things, they're all you know, just going for it right, especially as a kid or as a teenager, you know, you can call people up and just ask for stuff. Right? And, and sometimes it works, right? But but if you don't ask for it, you definitely don't get it. And so going in, and it wasn't that I went up to Nolan Bushnell and asked for money. I went up and just wanted to share my passion. And I saw his passion and wanted to talk about it. And that led to this opportunity. You know, same with going to Stanford and talking Terry, you know, I'm used like, normally take students. Okay, you know, right. And then I called up, you know, Xerox PARC and said, Can I talk to the small talk group and they connected me to Adelle Goldberg, who was, you know, leading the small talk group. And she said, I came to Stanford in order to work on Small Talk, can I come over there and work for you? Maybe here talk to Peter. And he connected me to Peter Deutsch. And he ended up being my mentor at Xerox PARC as a freshman. Now, the disadvantage of that is I didn't get the usual college experience, right. I didn't get the, the, you know, because I had this. I mean, I had this job at Xerox PARC, which is kind of why I was there. So you know, Stanford's like, Ivy League, what's that? I don't
Tim Bourguignon 15:48
know, partying for you. Oh, nice drinking.
Dean Tribble 15:56
Definitely was not why I was there. Okay. So I did it. And then I ended up in the computer science program. And
Tim Bourguignon 16:04
so did you fulfill that dream of going into AI?
Dean Tribble 16:07
No. Oh, well, okay. So I worked for Terry, but well, so I worked for Terry, and he had a project he was working with, you know, the name, the name will come back to me, but but on speech act theory, which was software, that's basically he was like, you know, it was workflow before the term workflow, you know, so, so enforcing interactions between people in the structure, you know, in, in this case, in messaging, a messaging system, where I can send you a message to start a contract. And to renegotiate, and to do various things in the speech acts of a negotiation. So each speech act is I make an offer is an is a speech act in that terminology. And so I was I got two as an intern for him, I was working to implement that in inter Lisper, I think it was, and, you know, and I had already been, you know, talking with folks, and that was my student project, I was still working with our spark. But of course, I've been talking with folks at Parc about email, you know, because, you know, I had email back in, you know, the 70s over it in late 70s, early 80s, at Aerospace Corporation, and then, you know, and then Stanford and George Burke. So, you know, you could see how much people used email. And this workflow system with speech acts really restricted what you could communicate with people about, and it was clearly an issue. And I was saying, Yeah, you know, I mean, but they really wanted to enforce you to kind of implement, you know, stay within the workflow. And that, that experiment convinced me long term of the realization that, you know, if you get 99% of the interaction between humans built into a structure of interaction and software, you know, that means almost every conversation has more than 100 bits of interaction, and one of them won't be supported. And so what's happened is, even though you've gotten most of the requirements enforced in your workflow, you will piss everybody off. Unless you've got a mechanism to escape so that humans could could step out of your workflow if you you know, and, and then as work for all rolled out over over the decades, you know, I saw this kind of thing happening where the people who were in charge of it were sure the flow they wanted was just this. And so they would enforce that. And it would break the ad hoc processes that people used or to engage with exceptions, or, you know, like, that works great. Except, you know, for this one, we've got a million dollar deal. If only we could get it out today, and your workflow doesn't let us get it out today. So, you know, maybe we toss it. So anyway, we ran into that same issue, that was hugely important, because I saw the same pattern show up in the first smart contract in 1989. So this was a few years later, where, where it was very much reproducing a system that enabled negotiation, and it tried to be too enforcing of how it is that it expected participants to interact. And that just wasn't you know, and that that made it very complicated made it very problematic for humans to participate in this thing. And I got to bring that experience that I had were you know, building this this AI system for Terry to the first basically the first production smart contract. So that was, you know, a later part
Tim Bourguignon 19:21
of defeating is going full circle with you doing smart contracts right now started there, that somewhere along the way, and coming back to it.
Dean Tribble 19:29
You know, this is a long, long time thing, but Okay, so you know, it's worth introducing now because we mentioned it. So to us to move. smart contracts are just the I say just software that's enforcing a contract like arrangement between third parties. So this software, this speed check stuff was enabling strangers to interact where it enforces No, you have to make an offer in order to get their attention. And then they can counteroffer. And you can accept, and those are all the actions that can be taken. And that's enforced by the software you're using. And once that's agreed to then maybe money transfers, though this was ARPANET, so nothing can happen. But you know, but but the later American information exchange that first production smart contract, it was, it was less rigid than that, because of what I learned from the speech Expo. But it was very much you know, now an agreement that comes together. And so money actually transfers, not because I swiped a credit card and decided to pay you but because I went through this process, and part of that ends up with a transfer of money. And so the system enforced and orchestrated this sort of cross business workflow. And that's what smart contract is, right? It's, it's in you know, the key thing is that enable strangers to cooperate. And so you know, and so this, this, this speed check stuff was for workgroups, but it was, you know, but it's but this was the transition from I want to make robots work to software, enabling humans to cooperate better software, enabling humans to be more productive, and a lot of the Xerox PARC stuff was showed the difference in productivity of, you know, command line you eyes versus Windows in mice, you know, it's just, you know, it's all about computers, enabling this next generation of productivity, you know, and enabling, giving humans leverage to be able to do more with the same, you know, the same brain, the same education, the same effort. And that just has been sort of the theme ever since,
Tim Bourguignon 21:28
there's always a fine line between extending which you can do in making air quotes the real world, and just just bringing you the the missing link toward the digital, the digital, the tools, and constraining you in a way to do it. That is just not an extension anymore. It's like a core set. But the line is really fine there. How do you find this line in the world of smart contracts, then?
Dean Tribble 21:52
So I'm not sure the line is that fine, we're in the sort of the the three categories of I can make what you're doing now easier, or I can discover a new thing you can do, because software that you weren't able to do before that makes your job easier. But you know, you know, instead of picking up the phone, you could now send email, right? That was a big transition, you know, people ask, what was the use case of the internet? Well, you know, that's a big one of them. pointed, well, you know, what was the value prop of the internet, but clearly, it was valuable. But, but but the ability to, but what people do not realize is the ability to switch from synchronous messaging, where I call you on the phone, and you have to be there to asynchronous messaging where I can send a message to you, and you get back to me when it's convenient, or when it's workable, or I can send to multiple people. And then we coordinate as a group, that was a sea change, that was a big change in potential human interactions that changed how the world worked, you know, and it kind of came in quietly, but gradually, you know, it's not that anyone had to be convinced that it was different. It all took off when it just sort of became kind of the standard mode of operating. Right. And so we've seen mechanisms like that multiple times. And yeah, I mean, the realizing something can have that impact, and the right and helping to make it have that impact or not, are, you know, those are quite different, it's gonna be very hard to have something have that impact. I mean, is it you know, web three is, is in that state. Now, you sort of, well, some friend of mine said, you know, the marketing is, is the art of making the chicken and the egg happen at the same time. Oftentimes, you have to this is clearly better if people work this way, but you have to let them realize it and give them a solution at the same time and you know, and grow your business in that space. Wildlife startup companies is their job is driving that kind of innovation.
Tim Bourguignon 23:44
Stay with us. We'll be right back.
Tim Bourguignon 23:47
Hello imposters. If you work in tech want to work in tech or our tech curious in any way you'll want to listen to this. We've launched a community of professionals who come together to share information and advice about jobs, roles, careers, and the journeys we all take throughout our lives as the designers, builders, fixers investigators, explainers and protectors of the world's technology. We call it the imposter syndrome network. And all are welcome. So find the impostor syndrome network podcast wherever you listen to find podcasts, and look for the isn community on your favorite social platform. Hashtag impostor network.
Tim Bourguignon 24:29
Indeed, indeed, and in this process, you will kill many ideas and try many ideas that won't work and find this maybe not so fine line, but still this balance between between helping and bringing new capabilities there.
Dean Tribble 24:43
One of the there was a long thing. So in the after, after Xerox PARC, I went to well, there's a bunch of stuff that happened, where we started doing large scale distributed system stuff in the in the Vulcan project, and I met Mark Miller, who I've worked with now and multiple companies and met Chris Hubbard in the summer Well thought group, and I've worked with him in multiple companies, he's here to work as well, you know, so so a few other folks like that. But but a lot of it, that's where this this idea of of distributed systems came in, you know, partly again, that he got Smith back when I was a kid, his vision of lots of these machines magically connecting to each other, blah, blah, blah. But actually seeing it happened at Parc was just, you know, amazing
Tim Bourguignon 25:24
that I believe you, it's amazing how these old again, I should be making because old papers like the papers from the United Nations Conference in the 60s, are still so valuable today, you can go back to them and read them. Maybe you change a couple of words with with serverless and cloud and stuff like this, and they apply completely, and you still have exactly the same ideas. You
Dean Tribble 25:46
know, I've occasionally used the mantra architecture is simple, right? You know, the, if you're, if you're caught up in details, you're not really talking about the architecture of your software system, it's, you know, it's one of those things where, you know, look, everything else aside, it's either you're calling them synchronously, and you wait for an answer, and it comes back, or you're calling them asynchronously, and you don't wait for an answer. And you can wave your hands about all the different mechanisms. My question is, which one is it? And that's, you know, and that's a yes or no question or, you know, sink racing question. Right. You know, and, and then we can look at the details. Right, can you while you're calling synchronously, can you be reentered? Or Can't you? And, you know, I hear a lot, you know, dilly dallying and hemming and hawing. But the answer is real bully, and you can either be reentered while you're doing this, or you can't, you know, and, and if you have something novel here, then you can be really, you should understand what that novelty is, and you should be able to articulate it, but otherwise, it's a or b, right? You know, or maybe there's three options, but it's one of those things where it's amazing how much sort of crap that are real architectural thinking can cut through, and, you know, and that's and, and when a lot of these early papers were coming out, they were trying to figure out sort of these basic problems, and those problems survive, right, you know, the, the original actors work continues to be a useful tool for thinking about asynchronous systems, a lot of the derivative stuff, you know, it's just detail is not very interesting. The important stuff are sort of the core ideas,
Tim Bourguignon 27:12
right? How do you do you live on the web nowadays without rolling your eyes every single day? Again, this one? I've seen it at least a dozen times.
Dean Tribble 27:23
That's right. Yeah. So I had a good teacher at that norm Hardy was the architect of time net, which was the largest private packet switch network or an architect of it before the internet, that's, you know, X 25 networks is what everyone used for, you know, for stuff within it. And you know, Genie network and all the facts, networks and all this. And so and we observe even observed at the time, you get this recapitulation of ideas from the mainframe area, and then the mini computer area, and then the microcomputer area, and then the mobile era or the laptop era, in the month owner, every single one of those people would reinvent things, you know, I mean, cloud computing was time sharing, thank you. Right, you know, they did a lot and learned a lot about how to do time sharing, and, and identified core architectural pricing issues. Like if you're pricing based on the availability of your, your, your compute power, then the service that's providing you where you're bidding up the price of the service that's providing missing, they have some incentive not to add more machines, because then the price will drop. So their costs go up and the price drops, that seems bad for their business. So, you know, is that problem likely to be something that you know, if cerium and its gas auctions might faced, same basic problem, same basic architecture? And so, the thing is, he saw us you know, so so we did you know, after, after a GORUCK, I went to Xanadu, I went to agora x I went to a few others, after after, after Xerox PARC, Xanadu where hypertext was invented, went to a GoreTex, where we had in the 90s, where he had early smart contracts and large scale distributed system stuff. And he was you know, he we met him in 1989 or something, and discovered how much of the problems we had been wrestling with for the last several years get solved while Canada here's what we did, like but but that just solves it that's like the answers like he would see these problems and had had this this this both brilliance you know, he could you like ask the problem. He would think for a moment, he'd map it into the concepts he had in his head, and then he'd come back with an answer that was out of left field where you go, Oh, Barbara from spark was similar where he mapped everything into weird, you know, non modular LIS constructs that he had in his head in interlace V and the ancient Angeles and he then come back with an answer that was just sort of, you know, getting out of left field and brilliant, but but nor So Norm Hardy really brought that historical expertise and humility, where every time he would go, you know, it's a recapitulation of a lot of the same ideas. But the environment is just a little bit different. And it's those differences that are important. So let's think about what why know the different for this area that might be relevant. So instead, I've got a large pile of cool ideas to mine to solve modern problems. And many times they're very similar. I mean, you know, Ethereum is a blockchain. You know, I'm, you know, I'm in the blockchain space, if you're into blockchain, for people who don't know, it's the latest proof of stake chain, now, I make that snarky as they finally transitioned to proof of stake, which was an amazing effort. But when they first designed this, they made it synchronous calls and read with reentrancy. You know, wave your hands about everything else, and you know, dance around to try and distract from that. But fundamentally, it has synchronous calls with reentrancy. And you'll Brian Warner, who's, you know, one of our engineers now was on the security review team, at the time, for theory have been pointed out that that's known to be a problem. And that will have that will have security hazards, but they couldn't fix it. You know, and, and who knows, maybe if they complicated things in order to fix that they never would have gotten the success they did. But it's one of those things where it's just, it's insurmountably, bad insurmountably hard for humans to program in that environment over time. And so to me, that runs up against a coding wall, that, you know, as you get away from the few 1000 programmers that can actually build this stuff. Now, you just can't get a big ramp into millions of developers, because they cannot succeed at that, at that programming mode. Lets you know, history has shown that in multiple situations. So that's one of those things where, you know, architecturally, you know, you that's kind of stuff that they understood in mainframe days, you know, I learned a bunch of that from norm as he's looking at these things, it just cuts right through to the, you know, what's the core of this and can really come up with, with with sort of the hardcore answer from the physics of computation? In some sense.
Tim Bourguignon 31:55
This is awesome. You served it on a silver platter. So I have, I have to ask this question in the sassy way. So which, which will, you're reinventing now?
Dean Tribble 32:08
Very nice. Okay. 1988, Mark had worked on Xanadu, which was were Ted Nelson Vista type projects before 1988. And there's a vision for many, many years. And he is his books, literary machine and computer led, illustrated, you know, describe the vision of hypertext is long before the web, right. And so 19, Ada, Mark, left Parc to go there. And he invited me over to follow him. So I left PARC, I left Stanford and went to to be an a software engineer at Zen where, you know, I mean, you're working on hypertext, I mean, once someone explains the idea of hypertext, imagine hearing about the web before the web existed, and you have the opportunity to work on this, right. Yeah, I want to I want to, and they had awesome database, you know, they have awesome algorithmic database technology that hadn't been seen anywhere before, or since there's still some very cool ideas in there that have been open source and should be one. But anyway, we were working in in the Vulcan group, we were working with concurrent logic programming languages, booty Shapiro from Weitzman Institute in Israel was, you know, one of the leading experts and is just, you know, an amazing brain driving that stuff for doing distributed systems. Where, you know, you could you could view, you know, a computation in this in this map as if you could express it in current concurrent logic programming language, you could run it very, very, in parallel very much concurrently. And you can easily distributed across multiple machines, you know, the logic actions of I resolve a variable and you see the value, well, that looks a lot like a message send if you squint at it correctly. And so we ended up seeing all of these mechanisms to reproduce a bunch of actors like ideas in concurrent logic programming languages, were they were a more comfortable, nicer programming thing that had these new principal, you know, models out of them because it was a large programming language. Now, it turns out, there were weird ways it did not mesh with actors ideas, because of determinism and non determinism, stuff like that. No, you know, don't need to go into the details. But I was always chewing on that, because I was always curious. So when I left Park, I started working on my own programming language called jewel, geo Ueli. I know, that's not how you pronounce it, and to which, which, which, you know, it was just going to be a hobby project. So it had to be perfect. It had to achieve a long list of requirements that I had, that were all relatively impossible, but you know, it's just a fun background project, so why not? And And out of that, I accidentally stumbled upon a new architecturally different place to stand where there was actual languages here, lots of programming languages here and jewel was in the middle, you know, and it was, you know, when you so it's sort of this synchronization is when you send a message when I send a message do I do I take care variable and instantiate to a first message and a new variable, which is the remainder, or do I just send the message on the reference, and then I can send another message, right? And actors, I can just send a message on a reference. And, you know, we're an object, you know, JavaScript, you know, a Java, C sharp all these object languages, I have a reference, I send messages to the object on the other end by reusing the reference. So in actor language, you reuse the reference in concurrent logic programming languages, you don't reuse the reference you consume it, making it a message and the rest of these things. And then on the receiving side was the same thing. Do I just get messages coming in, like in Java, JavaScript actors, etc? Or do I get a pair of the message and the rest of the stream the rest of the stream of messages, so you know, the particular details don't matter. But fundamentally, actor's language is picked reuse, in both categories of send and receive, and logic programming languages picked consumed in both categories. And I realized that reusing on sending was a pain in the ass. And reusing on on on receiving was a huge leverage point that actors did not have, what does that language look like? And so I started exploring it. And it turned out to be really interesting. And it took advantage of all the async messaging you got naturally from reuse of concurrent logic programming languages. So you did not get that async. Naturally, in the actor model, though, actors had lots of concurrency. And so that was really nice. Okay, so now we get to Xanadu, where Mark left docks bark to go to Xanadu, which is where hypertext was invented. You know, before we got there, though, Mark had worked there earlier, but But it got funded by Autodesk Corporation, which at the time was the number two software company in the world, you know, by size. So John Walker at Autodesk funded Xanadu, to get hypertext finally out there. So you know, imagine, you know, I, as a kid, you know, in college had an opportunity to work on the web, and got the division of it explained by the people who had come up with the original idea. And I could work on it before it was out there. Right. And so it's just, you know, an awesome opportunity, how can I write, so I left Xerox PARC, I left Stanford and went to be an engineer at Xanadu, and it ended up with this challenge of we've got clients and servers, they got to send messages. And we knew that messaging on Ethernet, you know, 10, megabit ethernet, 100 megabit ethernet, turns out, it doesn't much matter, because latency matters, you can get about 200 requests per second from client to server. And that just wasn't enough. But all this async messaging that we had done at Xerox PARC, and that I had been exploring further in the Java programming language, right resulted in letting you pipeline messages. So instead of send a message, wait for an answer, I could send a message, immediately have a result, send a message, it immediately have a result, etc, right. And so that meant I could stream messages out stream results back and still understand what was going on. And it still looked mostly synchronous, so it looked pretty reasonable to a normal programmer, even though you were pipelining messages to another chain. So this idea was the birth of promises that you see now in JavaScript in C Sharp in rust. The basic idea of promises, you know, comes out of this control logic programming, combined with actors into Jul. And then we were realizing it in C++. Well, because that's what we were letting people program ciphertext engine. And so we had promises and C++ for you know, the non blocking async messaging. And there were ideas of promises and futures and various that were floating around. But there are key architectural things, you have to decide when I send a message do I block? Can I you know, fundamentally in any system? Is there something if I've got two threads of activity A and B? Is there something a can do to prevent B from proceeding until a goes and if so it's walking, if not, then they're non blocking with the factory. This is one of those things where it's non blocking. That's the core ideas behind promises in JavaScript. And it led directly from jewel to the programming language to JavaScript, to C sharp to rust, right? This is this is a this is a pretty well documented lineage coming from myself and Mark Miller. So Mark, and I invented the core asynchronous promises, that is what people are using. And that's where and it was driven by not a synchronous coordination, but pipeline, asynchronous messaging, and the asynchronous coordination where I can say get a promise, do a block of code when that promise resolves? That's sort of the lesser use case that isn't. That is the primary one currently supported in JavaScript and C sharp and so forth. But they're able to support async messaging. So it's the right library. Okay, so back to the original question. So as Warwick is building smart contracts, that thing that I said about being able to enable software to enforce the terms of cooperation in hardened JavaScript, which is a JavaScript that's inspired by these earlier, secure programming languages, and secure operating system ideas, so you can actual write, you know, real sandboxes in standard JavaScript that can do asynchronous messaging, using promises. And so and you know, and every time you do the next round of that, you know, I've done several rounds of it. We did this in at Sun labs, where some Then where we kind of got learned a lot, did it at Microsoft, I went to Microsoft, and eventually ended up working on the Midori operating system, which was all async process, communicating with promises, build up a lot of experience and expertise there. And then we came to Microsoft and are trying to work and did it here to be able to enable, you know, millions of software developers to a build smart contracts, because, you know, having easy ways to allow software to enable cooperation among strangers in all the different ways humans want to cooperate, you've got to enable all the different programmers out there to be able to program this stuff, and not have it be some weird language that only a few 1000 developers know. And so, you know, meet them where they're at programming JavaScript, a hardened version of it. And then for communication between machines between blockchains between contracts on the same machine, this pipeline, async messaging in JavaScript using promises, we have recreated and, you know, several of the problems, you know, we've solved previously, and we go, okay, we didn't like that solution, can we solve the differently to make it work better in this environment? Or can we simplify it so that some of these, you know, rich challenges you were perfectly happy with, for systems programming don't appear for application programmers, or all this sort of stuff. And so it's a little bit different every time.
Tim Bourguignon 41:12
This is amazing how you look back and pick up the pieces. So you okay, I grabbed this piece of information there, I grabbed that one, I combined them here. And then it stopped making making sense of how you how you ended up where you are today. This wasn't a history lesson. And it's already actually the end of our time box. I wish we could talk for two more hours and not even scratched the surface. It's been fantastic. And really, there's so much more to your story. It's painful to stop now easier. Maybe I'm struggling with the advice I usually ask and I want to get there. See, we've seen that we talked about all those old papers and learning from the past and solve problems and making air quotes. But how should somebody nowadays a programmer starting nowadays, start Happy Ending dues problems that actually have been solved again and again, but are a bit different? And are just a vast amount of knowledge? That is kind of hard to get into? What would what would be your advice to start dipping your toes in there?
Dean Tribble 42:12
That's a really hard question. And it's a really good one. Because, yeah, because some of those papers, they said, are extremely readable, because they couldn't assume much shared background, because there just wasn't pre computer science curriculums, right, it seems to me, like there shouldn't be a curriculum of those papers, there are places that have like crypto canon, for example, or that will have canon, you know, here's a set of papers that are sort of the Canon for this area of expertise, that might be a place to start, but it feels like you know, CACM the community, you know, the ACM, the American computing, machinery, whatever it is, you know, they ought to do that if they haven't already. And, you know, they have the lecture, you know, the Turing Award series lectures, many of which are, you know, you know, people who did something brilliant now introducing their their next big idea or explaining the core elements of their idea or whatever, but but it's a really good question. And sadly, I don't think I have a good answer for you. There are some good programming learning. Books are resources that do focus on sort of the core ideas, so instead of learn how to program in JavaScript, and then it sort of starts telling you how to use jQuery, so you can whip together a web page quickly, you know, instead, structured interpretation of computer programs in JavaScript is probably better, because that's how to think about software, how to think about how computers work, and express it in JavaScript, where, you know, programmers should not be looking looking to be a programmer of a particular language, but rather, you know, the, the requirements of programming are fundamental and are largely, they're not entirely independent of the language languages can provide some new abstractions. But you know, fundamentally, there's a conditional or choose operation, where you can choose A or B. And fundamentally, there's a given a collection of things, do something for all of them, you know, when when you're looking at a new language, you can orient yourself by sort of some of those core concepts, and then be able to write something and learning language quickly. So programmers need to get that level of internalization of the concepts of computation, so that they're in order to be a good programmer, and that sort of the architectural level. And you know, what's the dependency? Not? Did I say import that file? Right? If I'm having two strings, they have to be the same in two files. That's a dependency and now you just didn't report it. Right. But But understanding you know, internalizing the notion of a dependency, it's an example of an architectural thing. You just You just have to have to learn,
Tim Bourguignon 44:43
you need to do and you do the book you mentioned was that was it structure interpretation of computer programs
Dean Tribble 44:47
of computer programs, but the first one was for scheme, done a revised version in JavaScript that just read does it in JavaScript, so it's, you know, language 15 million people know, you know, but But do they know that level probably not,
Tim Bourguignon 45:01
I need to get this one I have the winning scheme, but not that one you'd have a script will be probably more readable
Dean Tribble 45:05
to me crazy because by the second chapter, you're you know, you're writing an interpreter in this language for another language. I mean, it's great. But but but to the extent that once you see the power of abstraction and leverage in a programming language, it's just a whole different level of programmers, you level up to the next level of program.
Tim Bourguignon 45:24
You're doing the dean, it's been fantastic, thank you very much, where we would be the best place to find you online and continue scratching the surface with your story or ask him a question about us and somebody else.
Dean Tribble 45:36
So. So I am on Twitter, though not very often at Dean Tribble on Twitter. And I need to ramp up the amount that I actually say things there refer back to some of these things at a gorrik. at TSA, AGR I see is the current company that has a lot of this technology, you know, and and maybe the right thing is, you know, GitHub slash agora, where we have software, open source software that does all this stuff, you know, and GitHub slash endo Jas, where it's a related thing that is the core, you know, hardened JavaScript, which provides, you know, the security model, the async, messaging, all these kinds of things, and you can find these from each other. But those are really, you know, core technology. One of the key things about what we're doing now is yes, it's a blockchain, yes, it will enable a whole new level of of, of stuff, but it's also all open source. And we and you can use it for other things. And that's on purpose. I don't, you know, build awesome stuff in Microsoft do this sort of thing and an operating system context and nobody can use it. That didn't do any good.
Tim Bourguignon 46:41
Then thank you for that. open sourcing for us. Anything else? Before we call it today?
Dean Tribble 46:46
Yes, I'll add one thing given that there's this market downturn in blockchain as to what the value of blockchain is and why we're doing a blockchain wide work is doing the blockchain. So I've talked about smart contracts net, that was a trillion dollar market cap before blockchain. So smart contracts is not about blockchain would be the gold standard of blockchain is multiple computers in different jurisdictions, in different administrative management zones, right managed by different people coming to consensus about what happened in execution of the choice of DNS $100, you know, state DNS $100. In his account actions, Dean put a bid in and then withdrew it, when the auction while the auction closed, and sort of the consequences and the ordering, either Dean got his money back, or he won the auction. And you can't have both because otherwise the money would be duplicated. And you know, that's easy to think about software wise when you bought one computer. But it turns out doing that with with with 100 computers is really, really hard. And so there's this, there's this core nugget of enormous value that blockchain has, has brought to the world that people are sort of distracted by all of the, you know, the high flying prices and volatility and all sort of stuff. But that core value of improving how we get this, this consensus among computers, that provides an execution substrate with a level of integrity to its execution, that vastly outstrips anything anyone has ever done in software, it is really a next level up where there's no you know, you just like you don't trust Intel to do their their floating point right and not stick a back door. And that's okay, there are three different different floating providers that are all voting on the answer, right? You know, and it's just a very different world of computation. That is a big step forward. It's also advanced zero knowledge technology, which is crypto magic and formal methods that are valuable across the board not just for blockchain or crypto, but for software and control systems in general. And so it's one of those things where it's very easy for people to get distracted but for all those people interested in software out there, there's some core value prop that is worth an enormous amount and it's worth this up and down market the same way that when the internet came out you know, we had sock puppets for pet stores and and you know this vast up and down as the market found its value prop and found its product market fit and you know, we're in that phase now, but the core value is enormous.
Tim Bourguignon 49:07
It doesn't need it's still hard to grasp but we're slowly seeing the good examples showing up and yeah, and it's starting to not settle down but but isolate a bit less
Dean Tribble 49:19
like like with the internet crash and you know, late 90s just like oh, you know cuz I lived in the mirror like finally all the tourists went home and I can get some work done. Right. You know, right now we have this discretion earring, relatively speaking in blockchain space, and finally all the tourists, right, only we can get some work time.
Tim Bourguignon 49:35
Dean, thank you so much. I had such a great time. And I'm sure the audience will have as well.
Dean Tribble 49:42
Thank you. It was great fun. And thank you for asking your provoking questions.
Tim Bourguignon 49:48
And this has been another episode of developer's journey, and we'll see each other next week. Bye bye. Thanks a lot for tuning in. I hope you have enjoyed this week's episode. If you liked the show Please share, rate and review. It helps more listeners discover those stories. You can find the links to all the platforms the show appears on, on our website, Dev journey dot info, slash subscribe. Creating the show every week takes a lot of time, energy, and of course money. Will you please help me continue bringing out those inspiring stories every week by pledging a small monthly donation, you'll find our patreon link at Deaf journey dot info slash donate. And finally, don't hesitate to reach out and tell me how this week story is shaping your future. You can find me on Twitter at @timothep ti m o th e p porker email info at Dev journey dot info talk to you soon