Podcast appearances and mentions of barbara liskov

Liskov Substitution Principle: Das L in SOLID von Barbara LiskovHeutzutage wird die Informatik und Softwareentwicklung leider primär von Männern dominiert. Doch schaut man ein paar Jahrzehnte zurück, haben viele Frauen maßgeblich die heutige Software-Entwicklung geprägt. Eine Frau war Barbara Liskov. Liskov? Das kennt man doch irgendwoher? Genau. Sie ist unter anderem die Namensgeberin für das L in den SOLID-Prinzipien (die ersten 5 Prinzipien des objektorientierten Designs).Als zweite Frau überhaupt hat Barbara Liskov 2008 den berühmten Turing Award erhalten. In dieser Episode besprechen wir ihr Lebenswerk.Bonus: Barbara Liskov war an den Sprachkonstrukten Exceptions, yield, multiple assignments und multiple returns beteiligt.**** Diese Episode wird gesponsert von https://www.workshops.deOb öffentliche Schulungen, die du einfach buchen kannst oder maßgeschneiderte Schulungen für dein Unternehmen – Workshops.de bietet deutschsprachige Kurse in den Bereichen Angular, React, VueJS, Spring Boot, Typescript, Docker, Security, Data Science und den Grundlagen von HTML, CSS und JavaScript an.Alle Infos unter https://www.workshops.de****Das schnelle Feedback zur Episode:

A lot of recent work going in PyTorch is all about adding new and interesting Tensor subclasses, and this all leads up to the question of, what exactly is OK to make a tensor subclass? One answer to this question comes from an old principle from Barbara Liskov called the Liskov substitution principle, which informally can be stated as S is a subtype of T if anywhere you have T, it can be replaced with S without altering "desirable" properties of this program. In this podcast I'll talk about LSP and how it relates to the design of Tensor subclasses and a hypothetical "abstract Tensor specification" which really doesn't exist but which sort of implicitly exists in the corpus of existing PyTorch programs.Further reading:This is a cool interview with Barbara Liskov that I quote in the podcast https://www.youtube.com/watch?v=-Z-17h3jG0AMax Balandat talking about linear operators in PyTorch https://github.com/pytorch/pytorch/issues/28341At the end I talk a little bit about multiple dispatch; an earlier discussion about this topic is in this podcast https://pytorch-dev-podcast.simplecast.com/episodes/multiple-dispatch-in-torch-function

For those of you who have been waiting for the next letter of the SOLID series, we are happy to finally discuss the 'L' in SOLID, which is the Liskov substitution principle, or as we like to call it, the LSP. If you're like us and the LSP conjures up an image of a long-gone mathematician, think again. It is actually a principle developed by Barbara Liskov, an American computer scientist. In this episode, we get into a simple definition of the LSP, which is that objects should be replaceable with their sub-types, and this should not alter the functioning of the program. To clarify, we use an example of shapes in a program and how the principle would be applied. We also look at how the LSP relates to inheritance, and why inheritance should only be used in certain circumstances. Along with this, we touch on our feelings about interfaces and learn more about William's experience with TypeScript. Tune in today!

Barbara Liskov was already breaking new ground in 1968, when she became one of the first American women to earn a doctorate in the emerging discipline of computer science. After receiving that PhD at Stanford, she went on to design several influential programming languages, including CLU, an important precursor to Java. More recently, as an Institute Professor at MIT and head of the institute’s Programming Methodology Group, she has undertaken crucial research on distributed systems, information security and complex system failure issues. She is one of fewer than 100 individuals to receive an A.M. Turing Award from the Association of Computing Machinery. In a conversation with host Ann Miura-Ko, a lecturer in Stanford’s Department of Management Science and Engineering and founding partner of the venture capital firm Floodgate, Liskov explores how she discovered the nascent field of computer science, how she recognized and surmounted a number of fundamental computing challenges, and shares her concerns and hopes about how computing will continue to transform our lives.

Barbara Liskov was already breaking new ground in 1968, when she became one of the first American women to earn a doctorate in the emerging discipline of computer science. After receiving that PhD at Stanford, she went on to design several influential programming languages, including CLU, an important precursor to Java. More recently, as an Institute Professor at MIT and head of the institute's Programming Methodology Group, she has undertaken crucial research on distributed systems, information security and complex system failure issues. She is one of fewer than 100 individuals to receive an A.M. Turing Award from the Association of Computing Machinery. In a conversation with host Ann Miura-Ko, a lecturer in Stanford's Department of Management Science and Engineering and founding partner of the venture capital firm Floodgate, Liskov explores how she discovered the nascent field of computer science, how she recognized and surmounted a number of fundamental computing challenges, and shares her concerns and hopes about how computing will continue to transform our lives.

Barbara Liskov was already breaking new ground in 1968, when she became one of the first American women to earn a doctorate in the emerging discipline of computer science. After receiving that PhD at Stanford, she went on to design several influential programming languages, including CLU, an important precursor to Java. More recently, as an Institute Professor at MIT and head of the institute’s Programming Methodology Group, she has undertaken crucial research on distributed systems, information security and complex system failure issues. She is one of fewer than 100 individuals to receive an A.M. Turing Award from the Association of Computing Machinery. In a conversation with host Ann Miura-Ko, a lecturer in Stanford’s Department of Management Science and Engineering and founding partner of the venture capital firm Floodgate, Liskov explores how she discovered the nascent field of computer science, how she recognized and surmounted a number of fundamental computing challenges, and shares her concerns and hopes about how computing will continue to transform our lives.

A new season of the Entrepreneurial Thought Leaders starts on October 9th! Guests this season include Arlan Hamilton, founder and managing partner of Backstage Capital; Barbara Liskov, Institute Professor at MIT’s Computer Science & Artificial Intelligence Lab; Srin Madipalli, accessibility and product manager at Airbnb; Sarah Nahm, co-founder and CEO of Lever; and Aileen Lee, founder of Cowboy Ventures and All Raise. Be sure to subscribe to the podcast to get new episodes delivered straight to you every Wednesday!

Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis. This is episode 53, on the Liskov Substitution principle. Liskov Substitution Principle This week's tip is brought to you by devBetter.com. Sponsor - devBetter Group Career Coaching for Developers Need to level up your career? Looking for a mentor or a the support of some motivated, tech-savvy peers? devBetter is a group coaching program I started last year. We meet for weekly group Q&A sessions and have an ongoing private Slack channel the rest of the week. I offer advice, networking opportunities, coding exercises, marketing and branding tips, and occasional assignments to help members improve. Interested? Check it out at devBetter.com. Show Notes / Transcript We're in the middle of the SOLID principles this week, with the only one who is named after an individual. The Liskov Substitution Principle is named for professor Barbara Liskov, who teaches computer science at MIT. She gave a conference keynote some years ago in which she defined substitutability in object-oriented systems, essentially stating that one type could be considered substitutable for another if there were no situations in which the original type worked but the new one did not. The typical definition used today is that subtypes should always be substitutable for their base types. If this isn't the case, it likely means you have the wrong inheritance relationship, or your interface isn't cohesive enough, or there is some other code smell you should consider addressing through refactoring. So, although it isn't mentioned in the name, LSP is all about inheritance hierarchies. That's the first thing to remember. Many developers, myself included, learned about inheritance with the aid of the IS-A relationship. That is, you can consider using inheritance to model a problem if there are two related concepts and one IS-A more specific version of the other. You might have a Car class, with an SUV subclass. Or an Animal class with a Mammal subclass. These work because an SUV is a car and a mammal is an animal. Sometimes, though, you might have an IS-A relationship, but it's not sufficient and it leads you down the wrong OO design path. The classic geometry examples involve squares and rectangles and circles and ellipses. A square is a rectangle; a circle is an ellipse. But take care if you try and use inheritance to model them, since depending on how you do so you could introduce breaking changes into your application. Imagine if you have applications using your Rectangle type that assume they can independently set the height and width of the rectangle. Then someone introduces the Square type that inherits from Rectangle and implements height and width properties so that setting either one will set the other, too. This ensure the resulting type is always a square. But it also means that a method that takes in a rectangle and modifies its height and width to different values will break, because the first value set will be silently overwritten by the second. Another classic example involves birds. What if your base bird type includes methods like Fly and properties like Altitude? Then, someone introduces subtypes for Ostrich and Penguin. Trying to substitute these in to methods that expect certain behaviors from Fly and Altitude is likely to cause problems. The problem here is that the initial assumption that all birds can fly was inherently flawed. In business software, we don't usually worry about birds or squares, but we often model things like policies, accounts, orders, etc. and often there are different varieties of these concepts. You'll know when you're violating LSP when you see code that shouldn't care about the specific variety of something, but has to run a type check to do its work properly. A method takes in an Account, and then checks to see if Account Is PremiumAccount, for instance. This signals an LSP violation, and can usually be corrected with a refactoring that shifts behavior up or down the inheritance tree. Pretty much the only place where you might have a conditional on the specific type of an instance of a class is in a factory method that's responsible for creating that specific type. Otherwise, the Replace Conditional with Polymorphism refactoring is your friend. Use it to eliminate excessive conditional logic from your code by making proper use of inheritance in your object model. Obviously examples of these principles are tougher to describe in a podcast than in video, so to see them in action check out my courses on Pluralsight on the SOLID principles. I just produced a revised course for 2019, but my original SOLID principles of object-oriented design course is out there as well and uses different examples, so you might get benefit from seeing both of them. You'll find links to both in this episode's show notes. Show Resources and Links devBetter SOLID Principles for C# Developers SOLID Principles of Object Oriented Design -and the DRY Principle Refactoring Fundamentals That’s it for this week. If you want to hear more from me, go to ardalis.com/tips to sign up for a free tip in your inbox every Wednesday. I'm also streaming programming topics on twitch.tv/ardalis most Fridays at noon Eastern Time. Thank you for subscribing to Weekly Dev Tips, and I'll see you next week with another great developer tip.

Im fünften Wissenshäppchen geht es um das Liskov Substitution Principle. Inhalt Das LSP ist das dritte der fünf SOLID-Prinzipien. Es wurde 1987 von Barbara Liskov definiert, die ihm auch seinen Namen gab: Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it. Man könnte... Der Beitrag Liskov Substitution Principle (LSP) – Wissenshäppchen #5 erschien zuerst auf IT-Berufe-Podcast.

In this episode, Chris Martin of Type Classes and Joe LaSala of The Frontside talk about blockchain development. Do you have opinions on this show? Want to hear about a specific topic in the future? Reach out to us at contact@frontside.io or on Twitter at @thefrontside. This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. TRANSCRIPT: JOE: Hey, everybody. Welcome to Episode 104 of The Frontside Podcast. I'm Joe LaSala. I'm a developer here at the Frontside and I'm going to be hosting today's episode. Today we're going to be associating blockchains and other cryptographically secure technologies and everything that has to do with the web and the future of the web. We have with us Chris Martin and he's currently with Type Classes. What do you do over there, Chris? CHRIS: Our goal is to teach functional programming with Types, specifically with Haskell and a little bit Nix. We do subscription video service. JOE: There seems to be, I guess a bit of an overlap between people who are into functional programming and people who are involved in this new space that has opened up, this new web, I guess and that's something that I want to talk about based on a tweet that I saw you made recently. You mentioned that there's a big section of the Haskell community that is being drawn into whatever the hot ICO is at that moment there, something along those lines. CHRIS: Some of it are bitcoin people or something else but there's definitely a weird overlap that I can't fully explain. JOE: It seems like strange bedfellows, right? CHRIS: Well, there's a couple of things that make sense, which I think the distributed systems in cryptography are kind of these notoriously hard problems. I think when somebody wants to convince their boss that they really need to use Haskell for this problem, I think they can make a persuasive argument in this case. JOE: That's interesting. There's actually, a lot of technology around blockchains around bitcoins, specifically being written in Haskell. I didn't know they were technologically overlapped like that. I guess I just thought they were two very kind of passionate communities but you're saying that a lot of the bitcoin startups that you might see coming out in any given week are actually being written with an eye towards functional programming. Is that accurate? CHRIS: I don't know about bitcoin along this bit but I think some of the people who are working for banks and trying to develop their own sort of novel internal blockchains and stuff, I think those are the people who see this. Although in the case of banks, we don't necessarily see what's coming out of them, so we can't verify whether they're actually shipping things or not. JOE: Yeah. That means there's a lot to touch on there. I would agree with you on your initial sentiment, also just to extend to say that I think personally that both communities are really evangelical. Functional programmers, people who are into functional programming, for me it hasn't clicked yet and I know that it will come into my heart. I've asked functional programming to kind of where things are starting to fall into line where I'm certain to see the world in that way but for people who have seen the light fully, I'm sure believers once monads and functors kind of enter the conversation. They don't leave. It's similar like when bitcoin first started and everybody's running about the gold standard. Really, it's just nothing. It was hard to find resources on it that did the most of the amount of screaming. CHRIS: Yeah, you're absolutely right, that culturally, they're going to attract the same group of people or the people who are willing to adopt something that's not fully fleshed out yet, people who want to take what they believe and sit in this community and try and spread it to the rest of the world. I think it's the same kind of people. JOE: The early adoption, I think is something I can consider too. I guess it's a very risk-oriented group. CHRIS: Yeah, kind of. I mean, Haskell is pretty old, I guess but -- JOE: That's fair, yeah. CHRIS: -- Some of the changes that really make it, it great and usable lately are pretty [inaudible]. JOE: That's interesting. You mentioned this idea -- we kind of skipped over a little bit but thanks, having their own blockchains and that's something that I think that maybe people not actively following this space, which is I will say, a very hard space to keep up for those of us who are actively following it. But those who may just know blockchain through the name of an iced tea company changing or some sensational news article or what have you or just through bitcoin even, but I know that it's not the blockchain. It's not a singular blockchain. It's very easy to implement the fundamental structure. It's a linked list, essentially, with the kind of a cryptographic thing that keeps from breaking that link. Those links are inserting new history, I guess the further you go back. I guess people are even exploring different data structures like directed acyclic graphs and stuff and how that could be used to map other domains but the reality is it's a linked list and you can spend up as many of them as you want and you can mine blocks based on all this different criteria. Bitcoin is a proof of work associated with the minting of a new block and that's been a problem for them as they scale as a currency but it could be a history of anything and the minting of those blocks can be based on anything. You mentioned banks, the financial kind of sector is certainly interested in these smaller private chains but do you think there's a use for that consumer market as well? How do you think that your personal blockchain or set of blockchains might be a factor in the hobbyist of the futurist life? CHRIS: Oh, wow. That's a different question than I thought. [inaudible] where you're going with that -- JOE: Where do you think I was going? CHRIS: Well, we're talking about banks and so, the question is now everybody other than banks -- JOE: Well, it could be everybody, including banks too, however you want to take it. CHRIS: Yeah. There's a much harder question, I think of what in the world we're actually saying when we are talking about blockchain, right? The notion obviously has started with bitcoin but if what you want to do is bitcoin, then you should just be as in bitcoin, so what are we talking about similar bitcoin and the general phrase people have they like to throw in here is Byzantine fault tolerance. I'm talking about any kind of system that can have multiple participants. We're used to talking about clusters of computers and making systems that can work if one of them fails, if one of them just stops working but now, we're starting to talk about how do we make systems work if one of them gets hacked, then we still have some assurances that the whole system works together as a whole. JOE: Would you consider Byzantine fault tolerance to be the defining factor of a blockchain because I feel like there's the timestamping element that goes along with it. I feel like they're kind of part and parcel, right? CHRIS: Kind of but if you're not considering Byzantine faults, if you're only talking about systems where you have benign faults, which is a machine goes down sometimes, then timestamping isn't really a problem because we can just use NTP and we all have a pretty sensible idea of what time it is. JOE: Time specifically, even just like, I guess order. I always considered sequence to be a massive part of what a blockchain fundamentally was. You have the distributed aspect of the network that gives this sort of resilience to malicious intent but not only is it protected, I guess against demolition and malicious intent by this crowd strength but also just fundamentally through the cryptographic side of it, you can't go in and insert things that didn't happen. Once that order has been said, it's been written in stone, basically, right? Because the way I understood is there were papers coming out of Bell Labs in the early 90s and those two things set as approaches to this independently and it wasn't until the internet advance so we put them together and we're able to achieve Byzantine fault tolerance through that. Is that, I mean...? CHRIS: It does help a lot, I think to buck up and think about what the state of research was in the 90s because I think that's something that a lot of people in blockchain space kind of lose sight of. You have a whole lot of people writing papers now who didn't used to be academics until a couple of years ago. It was the early 90s where we started having faxes and we started having what later turned into what's kind of known as raft. Like you said, they solved the ordering problem. Even something as simple as what we call Lamport clocks which is you have sort of a virtual timestamps and as long as nobody's malicious, if you remove the timestamp forward, then we can all have something that resembles the deterministic forward flow of time. Then, that milestone that I was like to remind people of this in 1999 is when we had the paper practical Byzantine fault tolerance. JOE: That was '99. You're talking about the... was it Castro and --? CHRIS: Liskov, yeah. JOE: Okay. I didn't know it was '99. CHRIS: Interestingly, the same Liskov that the Liskov substitution principles named for, Barbara Liskov. It's also a distributed systems research. JOE: That's swell as well. I kind of heard the concept of Byzantine fault tolerance but I never read this paper. I'm also surprised to find that it didn't come out of that same period of the early 90s and it was as far as '99. I haven't read its entirety but I did fall asleep reading it last night. You mentioned this specifically, I guess, when we're talking today, as a paper that is important. It's the work that we're trying to do at... was it Hijro, I think? CHRIS: Yeah. JOE: Yeah, so what kind of work were you doing there and what is important to you, I guess about this paper specifically, when you look at all the research that went into priming the community for the space that we are now in? CHRIS: When I joined Hijro, I got kind of a difficult and nebulous mission, which was that everyone in and around that space that was trying to sell to banks was if you said the word blockchain, you could get your foot in the door because all the banks were looking at bitcoin and saying, "Well, look, this is clearly something that's going to be big and we don't want to be missing out, so we have to figure out how this applies to us." JOE: What year is this? They were working this in 2014-ish, is that right? CHRIS: '15 or '16, I think. The question was trying to figure out what aspect of it was actually what they wanted here. What Hijro is trying to sell them, the details aren't even important for this conversation but we need an interbank solution. We needed a ledger of accounts that 'we weren't a bank so we couldn't be the one holding everyone's money and keeping track of the flow of money in our network.' We were on something that the banks were truly in charge of but we didn't want to necessarily have our platform be owned by a particular bank. We wanted to be the sort of consortium of all of our partners. JOE: Consortium is a keystone word I think here, that we should definitely come back to that. CHRIS: Yeah and people talk about, if I use the word consortium blockchain, I think sometimes in contrast with the public blockchain, with the 'free anyone can join' blockchain. JOE: Yeah. I'm particularly fascinated by this concept. That is a term that is used. I can confirm this. But you're doing that pretty early then because I feel like that concept didn't make it out into, I guess the public understanding, until recently or maybe I'm just behind at times. CHRIS: Yeah, I guess so. I don't know. When I start working on this, I just spent a couple of months trying to read papers about what was in space and I guess, the only big name that was trying to do something like this was Tendermint. JOE: Tendermint? Interesting. CHRIS: You can pick out technologies like this because the magic number is always one-third. They can tolerate Byzantine failure up to one-third of the nodes. That was a theoretical result that was reached, just sort of the best you can do. Before BFT and then BFT is one of those solutions in that category and Tendermint does something similar. JOE: That, I guess is sort of the background to this paper and it's impacting your life. I guess, what is put forth in this paper is to solve for higher tolerance. Would that be the right way to put it? CHRIS: Did you say higher tolerance? JOE: Yes. You're talking about the Byzantine tolerance is 30%, right? With Tendermint? But you're saying that they're doing something similar to that's before in the paper? CHRIS: The most interesting thing to me, I think is probably, hopefully possible to convey concisely is the rationale behind the one-third number because that took a while for me to really appreciate but I think it really clicked when it did. One of the hardest intuitions to get people to break, I don't know, way of thinking to shift, I guess is convincing people that consensus is even a hard problem because I had this conversation a lot with people that'd say, "I've got this JavaScript library here, for instance that just lets me broadcast a message to all the nodes in a cluster, so why can I just do that?" Why can't we just use one at a time to do it and if I detected someone's trying to cheat, if I get two different messages from someone that are conflicting, maybe I can just ignore them. JOE: Not in finance. That's kind of ironic, I guess that you found it difficult to get people to come to a consensus about the importance of consensus. CHRIS: Right. The basic flow of all these things is we describe them as voting systems. We have voting rounds where each time, like you said the blockchain of the ledger or whatever it is, just a linked list, so the problem of using consensus build database is we're just going to iteratively try to vote or come to consensus on what the next block is. What the next ledger entry should be? Obviously, since we don't have a synchronized wall clock to go by, we have to assume messages can come in any order. We might all sort of speak up simultaneously and propose different blocks as the next one, at which point we have to start over and retry that. But furthermore, I can send different votes to different people if I'm trying to be malicious and that's where the tricky part comes on. The rationale for the one-third number, maybe I can just try to come around to that and say it directly then, is that when we take a vote for what the next block is going to be, we need the supermajority. We need two-thirds of the participants to have all said the same thing and the rationale for that is it's actually easier to think of it backwards. Rather than saying, two thirds of the total, what we say is, "If we're going to allow some fixed number of nodes to fail, to behave maliciously --" you know, we traditionally call that number 'F' in the paper, then what we say is we need 3F+1 total nodes to be participating. JOE: I didn't know that was sort of codified into how conflict is resolved on things like bitcoin during blockchain. It's inherent, I guess. CHRIS: No. This is the total opposite of what bitcoin and Ethereum are going to do. JOE: Because I always thought it was just going to be like a majority, I guess but what you are talking about is more like how the Senate would were to pass a resolution to the constitution, like it has to be an exceptional majority. I'm starting to understand why one-third, specifically. It's 3F+1, I guess. CHRIS: The reason is because for each vote, every time I look at the results of a vote, I have to be able to assume that some number that we called F, of the people that I've heard back from are trying to cheat me. It turns out I need to be sure that the majority of the votes that I've heard back are from people who are actually following the protocol correctly and not lying. We need to be tolerant to two kinds of failure. One is that a node simply goes down and we don't hear from them and we don't receive a vote from them and then the other kind of failure is the Byzantine failure, that they're not following protocol in some way. The reason I need 3F+1 nodes is because we need to be able to make progress, even if F of these number is we didn't hear from at all because they're down and then, I need 2F+1 votes because I need to take into account the possibility that some F of these votes were from cheaters and then we need to have more honest votes than lying votes. JOE: That's pretty profound. I definitely going to finish the rest of this paper while conscious later today. I guess we're a little off with regard to math at this point and it's when you said, you spent I guess a month or so just reading papers around the time you started with Hijro and I guess did you stop because I feel like I've read just more white papers than ever thought I would outside of the academic setting, just trying to keep pace with what's been going on, particularly with regard to the web. I don't if you're familiar with like IPFS but these sort of directed acyclic graph things are popping up all over the place and platforms are even now being built on this concept. I guess, Ethereum feels impractical in a lot of ways. These dime-a-dozen tutorials, when you started talking about the global computer that is Ethereum and the blockchain and it's going to change everything in the internet and you won't have to pay Comcast like some central authority or you just pay for each transactions. The reality of it is every time you do a write against a data store have, first of all, thousands of computers go and verify that and also, you don't want to store your information on a linked list. It's not feasible for storing large data structures and it becomes very expensive for the user and for the person, if you're maintaining a smart contract for the contract itself. These are volatile, all little points of value. It's impractical. CHRIS: It's definitely a cost that you don't want to incur. In all cases, just a confirmation time is a cost you don't want to incur. JOE: Absolutely. CHRIS: There is one nice thing that that you can do in some cases, which is that people is talking about the piggybacking on these blockchains like if I have a system and I just want some extra assurance to keep it honest, then I can do things like periodically publish a hash of my database onto something like bitcoin or Ethereum. JOE: Yeah. That actually happen with anyone in financial... They do publish stuff in the paper and this was before cryptographic ledgers but to basically prove that this was the state of something, I remembered seeing this somewhere, like there would be in financial news, like there'd be some crazy number or string at the top to verify what was on the string. CHRIS: Yes. Of course, the irony there is that you really don't need some kind of blockchain if you want to do that because the fact that we're doing that before the blockchain has existed and doubly, it's funny because the first block of the bitcoin blockchain, the genesis block includes in it, I think a New York Times headline, which was intended as proof that Satoshi or whoever didn't spend years mining bitcoin prior to releasing it. It's supposed to be a proof of the time of the first genesis actually was. It's funny that we are actually already had this verification system and what that demonstrates is sort of a principle of consensus that I like to talk about which is that as you increase the time scale, consensus becomes an easier and easier problem. I think the reason why something like newspaper headlines are reliable means of a timestamp is just mostly because they're big and slow, because there's only one every day. I think the whole challenge like you said of, how a lot of systems kind of boiled down to having the white paper for bitcoin refers it describes bitcoin as a distributed timestamp server, something along those lines. The reason why you need a new technology to do that, I think so that you could have timestamps that are every of couple minutes, rather than every 24 hours. JOE: That's a very interesting take on it. I guess, the more time there is, it is easier to reach a consensus. It's just interesting to think about. It's funny as humans like the longer time passes, the less reliable memory is, I guess, less reliable history as we conceive of it, I guess. It's different when you record something than the way that you hold in the brain that sometimes I wonder how much impact that's had on. It's a little ephemeral, I guess but it's interesting. CHRIS: Yeah. I guess my statement is limited to the on-scale where we can actually fit into memory. JOE: Right, that most of the times, it's the only relevant scale, I guess, like a blockchain doesn't have use outside of our use of it, inherent to it, so it's going to be seen through that lens, I guess of our use of it. I think it is kind of profound, a thing to think about that I definitely considered. You mentioned using blockchains as adding a little bit of... how do you put it? Like truthiness, I guess, we'll say. I know that's not how you put it but adding a little bit of security, maybe around something else but the reality is you can get away with that on a number of other levels. I think that's important and interesting to think about. There seems to be this trend now talking about a blockchain as part of a bigger picture or consortium blockchain or a consortia of blockchains, right? Because a consortia would be multiple and then a consortium would be... No, a consortium would be a single grouping, consortia would be multiple groups. Basically, going back to the problem you're trying to solve with Hijro, you have multiple banks and I believe eventually, I don't know if you work on it, there was a protocol that came out of that company to unify these blockchains, like a few of them. They demoed and everything. That, I think gives you some power with regard to access control but again, I guess, that's not a thing that you really need consensus for. So, where does it fit in? Aside from things like voting and transparent finance for maybe a political cause or in the case of bitcoin, just finance in general. In bitcoin, I feel like we got Mongo DB super hard in the sense that it just got applied to every domain and it applies to very, very few. CHRIS: My boss at Hijro, Lamar Wilson really like to say that people talked about blockchain like it was hot sauce and they sort of sprinkle it on everything to make it better. JOE: That's sad. CHRIS: I guess, two answer to that one. One of the places where it absolutely captivates people's imaginations too far and doesn't work and then places where it doesn't work, so I want to start with the first here because the biggest mistake that people make is that there was this notion of tokenization that came out of Ethereum, where anyone could make a smart contract that represented something and now, also that I can trade digitally. Just like it's money or some kind of digital asset, so people want to talk about putting your car, putting your house on the blockchain or selling it there. But it's just shocking how many times I had to remind people that if I make a smart contract that represents cars and I put my VIN number on it and I transfer you my car, at Ethereum contract in an exchange for a bitcoin, if I call the police and report my car stolen, they're not going to look at the Ethereum contract, right? JOE: Yeah. Man, you're really right. People don't think about that enough. If your car is in the blockchain, your car still on the block. CHRIS: What we had realize when we're selling solutions like this is that they're great for some reasons but you need actual legal agreements to underpin things when you actually make connection to the real world. The magic of bitcoin that can't really be replicated is that the coin actually didn't need a pinning to the real world because the thing bitcoin was running was itself. It just depended on hoping that people were going to find the coin and ledger valuable intrinsically and bitcoin never really purported to control things in the real world. JOE: I guess, definitely not in the paper. There are some place that can buy in from some very specific elements of society that sort of cemented its place as useful but we don't really need to go to that road, I guess. I don't know. You know, my roommate is a lawyer and we have this conversation often and I feel like if we go down law and cryptography, we're going to be talking for too long, where we are at currently. CHRIS: Right and that wasn't your question anyway. It was just what I respond to easiest because being a critic is always the easier thing to do. JOE: I can feel you there. CHRIS: One of the interesting things that I never even found too much about but I noticed this in a couple of passing references as I was reading stuff about Byzantine fault tolerance in general is that it seems to have some application in things like flight control systems and space ships because when you think about a computer that you're going to send into space, you have two things that Byzantine fault tolerance applies to directly. One is you need a lot of redundancy. You need these control systems, maybe you have a dozen things computing the same result because you can't replace the hardware when once you shot something to space. The second thing is once you've sent something outside the atmosphere, all of the sudden, you're being bombarded with a lot more cosmic rays than you were before. Now, you actually really do this idea that computers can fail, not just by stopping but by producing wrong results. All of a sudden, it becomes a lot more real because you actually have physics slipping a bit at your computers. JOE: I don't even think you have to go as far as space if you talk about just like a fleet of something, like self-trading cards. I suppose, in domain where there is an interplanetary file system, it's good to specify the planet we're talking about. Just having worked a little bit with robots in college, they lie all the time and they produce bad data constantly, so not even bad actors just incompetent actors, I guess could definitely... This is something that has to be, I guess on our minds as we move forward as the society that has more connected devices, which I think as much as I would love to have left this conversation off in outer space, I think bringing it around to the internet of things, which is sort of where this all began months and months ago is probably a good place to stop meandering through these cryptographic weeds. You can probably put a pin in this. I think we've been talking about for a while now, I guess and just kind of trying to see what it is and where the applications are. It's constantly changing and never clear, I think is the conclusion that I've come to. I don't know. I think, just kind of shooting the breeze about it is a fitting end to a series of Frontside engagements in this space, for the time being. CHRIS: I've seen several people try to tackle the space of how to stop relying on things like Google Drive to store our data because I think a lot of us have realized that we're tired of losing all of our family photos every time a hard drive dies but a lot of people are uncomfortable with trusting Google with everything. This to me seems like a perfect opportunity for people to start building redundant systems among their home and friends. JOE: Yeah, I completely agree. I'm actively trying to do exactly that right now. CHRIS: Oh, cool. And you don't necessarily want your cluster of machines that's running on all of your family's computers to be able to go down if your 10-year old get some virus, right? JOE: Right and also, there's definitely things that you want just within your home or even just within your section of the home. I guess you could layer chains, to kind of manage those interactions? CHRIS: Sure. I'm not exactly sure what you mean by layering chains. JOE: You could have consortia in this case. If you had like a hypervisor, almost like a control notice, essentially or some type of view from above of this situation, you could say, think of it as a family scenario. We have three different houses on this call that all belong to our immediate family and cousins and whatever and it's like, me and my siblings, we have information that we all want just within the siblings. We don't want Mom and Dad to know. We don't want the cousins to know, so you could basically use like a blockchain to kind of date access to data that is held within that consortium and then the consortia could communicate amongst each other. Only the pertinent information that they wanted to allow access to at that time and then, internally of course, you could have all these different mechanisms for how you actually store that data or how you actually serve it up. It's pretty complicated. CHRIS: Yeah, I think you made a lot of sense, though. JOE: Yeah, cool. I'm hoping so. There's been some work on it out of Microsoft, actually. CHRIS: On the files storage problem, specifically? JOE: I guess this is like with a smart home and kind of just teaching devices to cooperate and ask each other. If you had a section of connected devices that maybe were related to the workflow that a human being might go through to get groceries or something and then a section that's related to doing laundry or whatever, eventually, they would learn to communicate in the laundry grouping and could say, "Hey, grocery people. We're out of soup," or something like that. It's sort of almost happened organically, I guess. I had not actually felt like I found that paper. I've only found references to it. This is where I need to get something like academic access but that was interesting stuff. I don't know how I end up here, either. This has always happening when you're talking about this domain. Anyway -- CHRIS: People's ideas, it's just sort of generally inspiring concept so people is following you everywhere. JOE: Yeah, it's heartwarming. You know, with my ICT, I could look back and see exactly where I usually came from than [inaudible], the name of the farmer who grew with. I don't know. It'd be so much easier to fake most things, really when you think about it. On that note, I hope that this conversation was... I know that there was no JavaScript and I apologize for that but I hope that our audience finds it interesting on some level and I want to thank you for your time. Chris, it was really great talking to you and getting your take on these things as somebody who's been in the industry for a while. Definitely, some fascinating points to consider and definitely, I will finish that white paper, probably this evening because it's pretty cool. If anybody in the audience has anything they'd like to ask you about pertinent to this conversation or anything else, where is a good place to get a hold of you? CHRIS: For me, it's mostly Twitter. I'm @chris__martin. I'm also at Type Classes, if you want to talk to me about our new business. JOE: Cool. This has been Episode 104, I believe of The Frontside Podcast. Frontside, we're a consultancy based in Austin, Texas and we love writing elegant, sustainable code and just producing good stuff, really. I think that's what we're all about. I think, we can agree at least, that's a core tenet of what we do and if you would like us to produce some good stuff for you, feel free to get in touch with us. Also, feel free to reach out via email if you have any ideas for future topics or any feedback about this episode. I also want to thank Mandy for producing this episode. You can catch us next week, I believe for our talk with Brian Douglas on Probot and Robert will be hosting that one, as far as I know. Thank you all for your time and feel free to reach out. This has been The Frontside Podcast. I'm Joe LaSala. Chris Martin, thank you for joining us and have a good day, everybody.

VP of Infrastructure at Google Cloud Eric Brewer, talks to Melanie and Mark all about open source at Google Cloud, distributed systems, hybrid cloud, and more! Eric Brewer Eric Brewer is the main inventor of a wireless networking scheme called WiLDNet, which promises to bring low-cost connectivity to rural areas of the developing world. He is a tenured professor of Computer Science at UC Berkeley. In 1996, Brewer co-founded Inktomi Corporation (bought by Yahoo! in 2003) and became a paper billionaire during the dot-com bubble. Working with Bill Clinton, he helped to create USA.gov, which launched in 2000.[1] He is known for formulating the CAP Theorem about distributed network applications in the late 1990s.[2] Starting in May 2011 he has been on a sabbatical at Google as VP of Infrastructure.[3] Credits: Wikipedia Cool things of the week Google Cloud Next site Google Cloud Next London site Google Cloud Next Tokyo site Cloud SQL for PostgreSQL now generally available and ready for your production workloads blog Calling C functions from BigQuery with Web Assembly blog BigQuery beyond SQL and JS: Running C and Rust code at scale blog Kubernetes best practices: How and why to build small container images blog youtube Interview Nine faculty elected to American Academy of Arts and Sciences blog USA.gov site Eric Brewer research at google Kubernetes site 2014 Dockercon Keynote youtube 2017 Google Cloud Next Keynote youtube Istio site Extend the Kubernetes API with CustomResourceDefinitions docs Mentors Butler Lampson Barbara Liskov David Patterson Question of the week If I want to visualise the network traffic between pods/services within my Kubernetes cluster, is there an easy way to do this? Weavescope features installation Where can you find us next? Mark can be found streaming Agones development on Twitch, and will be presenting on Agones at Cloud Next. Melanie will be presenting at the internet2 Global Summit, May 9th in San Diego, and will also be talking at the Understand Risk Forum on May 17th, in Mexico City.

«Tenía una idea muy sólida de lo que era un buen y un mal programa. Quería hacer fácil el escribir buenos programas, y como no puedes impedir que la gente escriba malos programas, no quería ponérselo demasiado fácil». Así resume su contribución a la informática Barbara Liskov, premio Turing en 2008 y una de las […] Lee la entrada completa en La mujer que nos enseñó a programar bien.