Podcasts about liskov

Fredrik talks to Dejan Milicic about software development - understanding, methods, and stories. We start by talking about encapsulation of knowledge and the essential software in organizations. Almost every organization should - it can be argued - be developing software that solves their unique problems, and yet so many outsource so much of their knowledge encapsulation. Oh, and we can never completely encapsulate our knowledge in code either, so all the more reason to keep people who actually know what the code does and why around. Dejan tells us about his way to Ravendb and a developer relations role - and how you can craft your own job, stepping suitably outside of your comfort zone along the way. We also talk about shortening attention spans, daring to dig down a bit and find out about the context of things. Like the second sentence of some oft-repeated quote. Prohibit bad things, but help automate doing good things and avoid doing the bad things completely. Dejan shares some database backstories - why would someone want to build one more database? Specifically, what lead to the creation of Ravendb? And the very strong opinions which have been built into it. Avoiding falling into marketing-driven development. After that, we drift into talking about processes and how we work. Every organization is unique - which strongly speaks against adapting the “best practices” and methodologies of others. Or keeping things completely the same for too long. Innovation is also about doing what other people are not doing. Why is concurrency still hard? The free lunch has been over for twenty years! Functional programming and immutability offer ways forward, why aren’t these concepts spreading even more and faster? We get right back to understanding more context when Dejan discusses how few of us seem to have understood, just for example, the L in SOLID. Dive deeper, read more, and you will find new things and come up with new ideas. Finally, Dejan would like to see software development becoming just a little bit more mathematical. So that things can be established, verified and built on in a different way. Thank you Cloudnet for sponsoring our VPS! Comments, questions or tips? We a re @kodsnack, @tobiashieta, @oferlund and @bjoreman on Twitter, have a page on Facebook and can be emailed at info@kodsnack.se if you want to write longer. We read everything we receive. If you enjoy Kodsnack we would love a review in iTunes! You can also support the podcast by buying us a coffee (or two!) through Ko-fi. Links Dejan Ravendb Informatics Domain-driven design Event sourcing Data is worthless - said in episode 601 Developer relations Nosql databases Jack of all trades Jimmy - who introduced Fredrik to Dejan at Øredev 2024 Hibernate Relational databases Oren Eini - creator of Ravendb Antipatterns n+1 Couchbase Scrum Agile software development The Toyota approach The Scrum guide Unison programming language - VC funded Dr. Dobb’s journal The free lunch is over Concurrency SOLID Liskov substitution principle Repositories on top Unitofwork are not a good idea - by Rob Conery Elm Titles A mathematician turned software developer Coding, but without deadline Saturated with software development Encapsulation of knowledge A bit surreal Accept people as they are There’s a second line Professional depression Prevented, not diagnosed The pipeline kind of thinking Frustration-driven development (You shouldn’t be) Punished for being successful The largest company of his or her life so far Optimized for maintaining the status quo Wash away all the context Manager of one The proverbial Jira Substantial content Methods of moving forward

Люди убеждены, что следование правилам SOLID сделает их код действительно хорошим... но так ли это?Спасибо всем кто нас слушает. Ждем Ваши комментарии.Бесплатный открытый курс "Rust для DotNet разработчиков": https://www.youtube.com/playlist?list=PLbxr_aGL4q3S2iE00WFPNTzKAARURZW1ZShownotes: 00:00:00 Вступление00:03:30 Что такое CUPID?00:13:00 SOLID как философия00:20:00 Single-responsibility principle00:27:00 В чем вред философии SOLID?00:32:15 Open–closed principle00:37:50 Liskov substitution principle00:49:00 SOLID - это религия00:59:00 Interface segregation principle01:08:10 Dependency inversion principleСсылки:- https://dannorth.net/cupid-for-joyful-coding/#composable : CUPID- https://en.wikipedia.org/wiki/SOLID : Вся "секретная"" информация есть в Википедии - https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html : Дядюшка Боб рассказыват, что значит Single ResposibilityВидео: https://youtube.com/live/uRyHlQ0ITAQСлушайте все выпуски: https://dotnetmore.mave.digitalYouTube: https://www.youtube.com/playlist?list=PLbxr_aGL4q3R6kfpa7Q8biS11T56cNMf5Обсуждайте:- Telegram: https://t.me/dotnetmore_chatСледите за новостями:– Twitter: https://twitter.com/dotnetmore– Telegram channel: https://t.me/dotnetmoreCopyright: https://creativecommons.org/licenses/by-sa/4.0/

Подивитись відео на YouTube 00:00:00 - Вова знайшов цікаву статтю в коментарях на Доу. Про спільний словниковий запас на співбесідах.00:06:28 - Фігня ваш SOLID було сказано на PubConf.00:10:45 - Що не так з Single Responsibility Principle. І що замість нього.00:25:55 - Що не так з Open-Closed Principle. І що замість нього.00:34:22 - Що не так з Liskov's Substitution Principle. І що замість нього.00:39:34 - Interface Segragation Principle і як на нього можна по різному дивитися.00:44:41 - Головне зло. Що не так з Dependency Inversion Principle.https://dannorth.net/cupid-the-back-story/Коментарі та побажання можна залишити в нашому телеграм чаті.Наш патреон, на якому тепер можна отримати trial на 7 днів та слухати випуски з пре-шоу, яке часто довше ніж сам випуск :)

В цьому випуску 00:00:00 - Вова знайшов цікаву статтю в коментарях на Доу. Про спільний словниковий запас на співбесідах.00:06:28 - Фігня ваш SOLID було сказано на PubConf.00:10:45 - Що не так з Single Responsibility Principle. І що замість нього.00:25:55 - Що не так з Open-Closed Principle. І що замість нього.00:34:22 - Що не так з Liskov's Substitution Principle. І що замість нього.00:39:34 - Interface Segragation Principle і як на нього можна по різному дивитися.00:44:41 - Головне зло. Що не так з Dependency Inversion Principle.Згадано в випускуПідтримай нас на Patreon

00:00:00 - Вова знайшов цікаву статтю в коментарях на Доу. Про спільний словниковий запас на співбесідах.00:06:28 - Фігня ваш SOLID було сказано на PubConf.00:10:45 - Що не так з Single Responsibility Principle. І що замість нього.00:25:55 - Що не так з Open-Closed Principle. І що замість нього.00:34:22 - Що не так з Liskov's Substitution Principle. І що замість нього.00:39:34 - Interface Segragation Principle і як на нього можна по різному дивитися.00:44:41 - Головне зло. Що не так з Dependency Inversion Principle.Коментарі та побажання можна залишити в нашому телеграм чаті.Наш патреон, на якому тепер можна отримати trial на 7 днів та слухати випуски з пре-шоу, яке часто довше ніж сам випуск :) - https://www.patreon.com/androidstory Тут для вас є ще більше нашого контенту Hosted on Acast. See acast.com/privacy for more information.

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:

اصل لیسکوف از اصول SOLIDProgramming principles - SOLID - Liskov Substitution Principle (LSP) در این ویدیو، به بررسی اصل لیسکوف از اصول SOLID می‌پردازیم. اصل لیسکوف یکی از اصول مهم و کلیدی در مهندسی نرم‌افزار است که توسط باربارا لیسکف مطرح شده است. این اصل در مورد تعامل بین کلاس‌ها و ارث‌بری به عنوان یکی از اصول اساسی معماری نرم‌افزار صحبت می‌کند.در این ویدیو، به توضیح اهمیت اصل لیسکوف در ایجاد ساختاری مناسب برای کلاس‌ها و ارث‌بری می‌پردازیم. همچنین، به توضیح نقش اصل لیسکوف در افزایش قابلیت گسترش و انعطاف‌پذیری سیستم می‌پردازیم.ما مثال‌های عملی از اصل لیسکوف در کد می‌آوریم تا بهتر درک کنید که چگونه این اصل می‌تواند بهبودهای عمده‌ای را در طراحی نرم‌افزار به ارمغان بیاورد و به پیچیدگی کد پیشگیری کند.پیشنهاد می‌کنیم این ویدیو را با دقت تماشا کنید تا اصل لیسکوف را بهتر درک کنید و بتوانید این اصل را در کاربرد‌های واقعی در کدنویسی خود به کار ببرید.---------------------------------------------------------------لینک کانال در سایر شبکه های اجتماعیYouTube:https://www.youtube.com/c/Ardiland1---------------------------------------------------------------Telegram:https://t.me/ardiland_tm---------------------------------------------------------------Instagram:https://www.instagram.com/ardiland_ig/---------------------------------------------------------------Twitter:https://twitter.com/Ardiland3---------------------------------------------------------------GitHub:https://github.com/ardalanebrahimi---------------------------------------------------------------LinkedIn:https://www.linkedin.com/in/ardalan-ebrahimi---------------------------------------------------------------

Professor Barbara Liskov spoke with us about the Liskov substitution principle, data abstraction, software crisis, and winning a Turing Award. See Professor Liskov's page at MIT, including her incredible CV.

How much do you know about computers? Like...really know? How about computing history? Sean Haas joins us in this episode to talk about why knowing the steps we've taken in computing history can help us inform our next steps. If you want to hear more about computing history from Sean you can check out his podcast. The twitter for that is @adventofcomp If you want to hear more episodes check out our website at https://tabsandspaces.io Tweet at us @tabsnspacesHQ Or join us for a chat on our discord server https://discord.gg/depv5npMTj Don't have discord? Shoot us an email at tabsandspacesHQ@gmail.com Contact us for free stickers as well! Show Intro music Unity by Fatrat: https://www.youtube.com/watch?v=n8X9_MgEdCg

PHP Internals News: Episode 99: Allow Null and False as Standalone Types London, UK Thursday, March 10th 2022, 09:04 GMT In this episode of "PHP Internals News" I talk with George Peter Banyard (Website, Twitter, GitHub, GitLab) about the "Allow Null and False as Standalone Types" RFC that he has proposed. The RSS feed for this podcast is https://derickrethans.nl/feed-phpinternalsnews.xml, you can download this episode's MP3 file, and it's available on Spotify and iTunes. There is a dedicated website: https://phpinternals.news Transcript Derick Rethans 0:15 Hi, I'm Derick. Welcome to PHP internals news, a podcast dedicated to explain the latest developments in the PHP language. This is episode 99. Today I'm talking with George Peter Banyard, about the Allow null and false at standalone types RFC that he's proposing. Hello, George Peter, would you please introduce yourself? George Peter Banyard 0:36 Hello, my name is George Peter Banyard. I work on the PHP language, and I'm an Imperial student in maths in my free time. Derick Rethans 0:44 Are you're trying to say you're a student in your free time or contribute to PHP in your free time? George Peter Banyard 0:49 I feel like at this time, it's like, both are true at the same time. Derick Rethans 0:53 Let's hop into this RFC. It is titled allow null and false as standalone types. What is the problem that it is trying to solve? George Peter Banyard 1:02 This is the second iteration of this RFC. So the first one was to just allow null initially, and null is the unit type In type theory parlance of PHP, ie the type which only has one value. So null is a type and a value. And the main issue is that when for leads more with like inhabitants, and like the Liskov substitution principle. If you have like a method, like the parent method, which can be told like either null or an object, and your implementation in a child class always returns null, for various reasons, maybe because it doesn't support this feature, or whatever is out, or... If your child method only returns null, currently, you can't document, that you can't type this properly, you can document it in a doc comment or something like that. But due to how PHP type handling works, you need to specify at least like another type with null in the union. Basically resort to always saying like mimicking the parent signature, when you could be more specific. This was the main use case I initially went into. Derick Rethans 2:08 If I understand correctly, you can't just have an inherited method that has hinted as to just return null? George Peter Banyard 2:14 Exactly. If you always return null, maybe because you always work or something like that, then you must still declare the return type as like null or exception, which is not a concrete because you say what, like why never fail. And like static analysers, if they can figure it out that you're using a child class, they can't maybe like do some assumptions or work further down that like what you're doing is redundant or things like that. So that's one of the main reasons I initially went with it. And I didn't add false initially, because it was like, well, false, it's not really a type properly. It's, it's what's called a value type. False is one value from the Boolean type. And I was like, Well, okay, we're just going to limit it to like, being the type theory purist, limited to proper types, where null is a proper type, although it's a bit sometimes misunderstood, I feel in the PHP community at large. And then people were like, well, if we add null, then by the only type-ish thing, which you can use in a type declaration, or whatever, which can't be used in a return type on its own, is false. And it's just weird. So why not add it in full. So that was the second thing as to why I added it. Some of PHP internal's functions being terribly designed because they were designed back in the early noughties, return null on success and false on failure, which you can't probably type at the moment. Currently, we need to type them as like Boolean or null, but true can never be returned in this case. And there are some other some other people have reached out to me it's like, well, yeah, but I always return false in this case. Or I also return always true in this case, although true, we have this weird asymmetry that we have false as a value type and not true. Derick Rethans 3:49 What was the reason for having false but not true? George Peter Banyard 3:53 When the union type RFC got discussed and passed for PHP 8.0, false was added, because a lot of traditional behaviour of PHP internal functions, was to return false on failure, instead of the technically more correct thing would be to return null. Because loads of functions return a false on failure, and saying that like in returns, these types, or a Boolean would be basically lying because you could never have true, false was included in it. With the restrictions that you can only use false as the complement with other types. So you need to do for example, array, or false, you couldn't just use false. Derick Rethans 4:37 Would it also mean that you can define a return type of a method that inherited a method that returns a bool, as false? George Peter Banyard 4:48 Yes, that would be now possible with the amended proposal. Yeah, which goes back to this weird a symmetry, we're probably. Adding true to make a complete would be a future RFC to do. Derick Rethans 5:00 Now, we've talked about return types. But I guess the reverse applies to arguments? George Peter Banyard 5:06 Arguments and property types also would, would be allowed to, like declare themselves as like null or false. The usefulness here is way more limited. Because if you declare an argument to be of type null, then basically you can only ever pass a null to it. And then therefore, the type doesn't do anything. Derick Rethans 5:26 But in an inherited method, you could then widen it. George Peter Banyard 5:31 Yes, exactly. You could always say: Well, this argument exists, it's always null. If you extend like your class or message, then you can add other types. But in theory, you can already do that by adding like an argument at the end of the message, because that's LSP compliant. The case for, and properties of those, because they are typing, they're in like their beads. Kind of debatable why you would do that. But it's just that like, well, if you accept types at one point, just restricting them like somewhere else gets very weird. At this point is more like look at the human review, or like use static analysis for the analyser to tell you like this argument is redundant and just remove it or this property doesn't make any sense. Because if it can only ever be null, why does it even exist in the first place? Derick Rethans 6:13 Right now, you can already use false in union types, but why not with null or false? George Peter Banyard 6:19 That goes back to the when a union type RFC got introduced. Null got added as a keyword. Before you could only use the question mark, before a type to make the type nullable. If you have a more complex union type, to not use the question mark in front of it. Therefore, the null keyword got added as a proper type. And because the logic was, Well, you shouldn't ever be able to return just null. Because then that function is kind of equivalent to void. Because of that, it was said that like, Well, okay, null and false basically have like kind of the same status is that like, if you just want to use null on its own, you're doing something kind of weird. And if you're returning more than false, like that signature is very strange. I think when that was discussed, nobody knew initially that an actual PHP function within one of the extensions, like in core had such a weird signature. Which mainly, we just started discovering that after this got, like accepted and we could like actually start properly typing the internal functions, and then you discover these weird edge cases where sounds like, that's a bit strange, can't properly document it. We just need to make like a note on the PHP documentation side. And like the type signature kind of lies to you. PHP's type hierarchy is a bit strange, void kind of lives on its own. So if the function is marked as void, it must always like any child inheritance, or whatever needs to be void. And when you type return in the function body, you need to always use return with like a semicolon afterwards, you can't even return null. Although, under the hood, PHP will always return a value when you call a function, even if the function is void, which will be null. Derick Rethans 7:58 The RFC also talks about question mark null, what is that supposed to be? Is that null or null? George Peter Banyard 8:03 PHP has this limited type redundancy checks at compile time. It will basically check if you're duplicating types. So if you write for example, int or int, even if it's capitalized differently, PHP was like, okay, just specifying twice the same type in this union. This is redundant. And then it will throw a compile error, we're basically saying, maybe you're just doing a mistake, maybe you meant something else. In the same vein, basically the question mark, gets like, translated into like, any seeing pipe null. And so if you write null with a question mark in front of it, it's just saying like, well, you're doing null or null, which is basically redundant. Therefore, you'll get like a compile time error telling you like. Derick Rethans 8:41 That seems sensible to me. What's been the feedback so far? George Peter Banyard 8:45 The most feedback, I think I've got it when I first proposed it in October. And at the time, it was like, Yeah, this is useful. And it's kind of needed because well, having always more type expressiveness is I think, good in general. But the main feedback at the time was like, Well, why not include false? The other feedback I got was basically, well, for consistency, what shouldn't you also add true? Yes, I do agree with this. I frankly, find it very strange that we landed in this situation where we only have one of these value types, either true and false, or none of them would make more sense to me. But that's expanding the scope. And it's kind of not this is not really concerned with this specific detail. Probably next, another RFC to do, for either myself or somebody else. It's just like propose true as a value type. Derick Rethans 9:33 Is the implementation of this RFC complicated? George Peter Banyard 9:36 It's very simple. It basically removes checks, because currently in the compile step, which checks for like type signatures, it needs to check that like, Well, are you declaring false or are you declaring null, and these checks get removed, so it makes the code a bit more streamlined. Oh, there's one change in reflection. For backwards compatibility reason, because of the fact of the question mark, any union type which is composed of a only two types, where one of them is null,will get converted in reflection to use the question mark notation, which is kind of a bit weird because it then gets converted into like a name type instead of a union type in reflection. But that's there, because of backwards compatibility reasons. I am breaking this into the more sensible reflection type. If you have a type of null and false, then you'll get a reflection union type instead of a named. From my understanding from reading the reflection code, the intention was always probably in PHP 9, to remove this distinction. So if you get a named type, it's only a single type instead of a possible nullable type. And any nullable types get converted into like a reflection union type when you have like null and the other type. Maybe this is a good test case to see if your code breaks. Derick Rethans 10:50 I would probably call that a BC break though. George Peter Banyard 10:53 This only happens if you do false union null. You can't use false currently on its own. And I think like, if you get false, as a named argument type, with like a question mark in front of it. Because it would be completely new, and you would never deal with it. It's like, well, this can also break because false can be in the Union type. If your library or the tool supports union types with the reflection thing, it will automatically know how to deal with false because it needs to know how to deal with it. And null. So that was kind of also the logic. It's like, well, okay, like if the tool supports that, which it needs to, then if you put this case into that bracket, it will work. It makes kind of the reflection code a bit more complicated at the moment. The whole fact that we need to juggle between like figuring out like, should we use the old like the backwards compatible thing reflection of like using a name type instead of the Union type, if there's a null and depending on the type, makes a reflection code unwindy and everything. And we have like a special function in C, which is basically just like, okay, which object do I need to create, depending on this type signature? Derick Rethans 11:53 When do you think you'll be putting this up for a vote? George Peter Banyard 11:56 I suppose I could put it up for vote immediately now. I am planning on maybe putting this on to vote at the end of the week or something like that. Derick Rethans 12:04 Well, thank you for taking the time today to talk about this RFC. George Peter Banyard 12:09 Thank you for having me on the podcast. Derick Rethans 12:13 Thank you for listening to this installment of PHP internals news, a podcast dedicated to demystifying development of the PHP language. I maintain a Patreon account for supporters of this podcast, as well as the Xdebug debugging tool. You can sign up for Patreon at https://drck.me/patreon. If you have comments or suggestions, feel free to email them to derick@phpinternals.news. Thank you for listening, and I'll see you next time. Show Notes RFC: Allow Null and False as Standalone Types Credits Music: Chipper Doodle v2 — Kevin MacLeod (incompetech.com) — Creative Commons: By Attribution 3.0

We all have some ideas about what works in software engineering and what doesn't. But without real evidence and data that is just an opinion. Empirical software engineering tries to answer the question of what can be proven to work in software development. In this episode, Hillel Wayne and Laurent Bossavit will talk about what we know about software development, what we don't know - and the myths about it i.e. what we think we know but really don't. Links Laurent's Book “The Leprechauns of Software Development” Derek M. Jones: Evidence-based Software Engineering: based on the publicly available data Hillel's talk “What We Know We Don't Know” Hillel's consulting Additional Links How students learn Reframing the Liskov substitution principle through the lens of testing Executable Examples for Programming Problem Comprehension What we know It Will Never Work in Theory: Short summaries of recent results in empirical software engineering research Fixing Faults in C and Java Source Code: Abbreviated vs. Full-word Identifier Names Recurring opinions or productive improvements—what agile teams actually discuss in retrospectives Andy Oram, Greg Wilson: Making Software Code Reviews Expectations, Outcomes, and Challenges Of Modern Code Review Characteristics of Useful Code Reviews: An Empirical Study at Microsoft Criticism of existing reasearch Hillel about “This is How Science Happens” - criticism of a code minin paper Hillel's newsletter: I **ing hate Science Hillel about “Are We Really Engineers?”

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

PHP Internals News: Episode 93: Never For Parameter Types London, UK Thursday, August 19th 2021, 09:21 BST In this episode of "PHP Internals News" I chat with Jordan LeDoux (GitHub) about the "Never For Parameter Types" RFC. The RSS feed for this podcast is https://derickrethans.nl/feed-phpinternalsnews.xml, you can download this episode's MP3 file, and it's available on Spotify and iTunes. There is a dedicated website: https://phpinternals.news Transcript Derick Rethans 0:14 Hi, I'm Derick. Welcome to PHP internals news, a podcast dedicated to explaining the latest developments in the PHP language. This is Episode 93. It's been quiet over the last month, so it didn't really have a chance to talk about upcoming RFCs mostly because there were none. However, PHP eight one's feature freeze has happened now, a new RFCs are being targeted for the next version of PHP eight two. Today I'm talking with Jordan LeDoux, about the Never For Parameter Types RFC, the first one targeting this upcoming PHP version. Jordan, would you please introduce yourself? Jordan LeDoux 0:50 Certainly. And thanks for having me. My name is Jordan. I've worked as a developer for about 15 years now. Most of my career has been spent working in PHP. Although professionally, I've had experience working in C#, Python, TypeScript, mostly in the form of JavaScript, but a little bit of Node and, you know, a variety of other languages that I haven't spent enough time in to really be proficient in any real way. But recently, I decided to do something that I have thought about doing for many years, but never actually jumped into which is exploring the PHP engine itself and how I could possibly contribute to it. Derick Rethans 1:32 And here we are, but your first our thing. Jordan LeDoux 1:35 Yeah, it's exciting. Derick Rethans 1:36 What is this RFC about, what does it propose? Jordan LeDoux 1:39 Well, this RFC proposes allowing the never type, which was added in 8.1 as a return value, to parameters for functions and methods on objects. The main idea behind that is that when never was proposed as a return type, it was meant to signal that the function would never return. Not that it returns void, which of course, void signifies which is returning no value or returning, returning without any specified information. And never return signifies that the function will never return, which is a concept that exists in many other languages. And for that purpose in other languages, what's usually used is something called a bottom type. And that's what never ended up being. And I'm proposing that we extend the use of that bottom type to other areas where the type may be helpful. Derick Rethans 2:38 So a bottom type, that might be a new term for many people, it will certainly for me when I looked at the never RFC for as return types. Can you sort of explain what a bottom type is, especially thinking about object oriented theory with something that we'd like to call the Liskov Substitution Principle? And also, how does it apply to argument types? Jordan LeDoux 2:59 Let's start with the Liskov Substitution. The general idea behind Liskov Substitution is that if A is a subtype of B, then anywhere that A exists, you should be able to substitute B. It has to do with when you have a class hierarchy in in an object oriented language, that that class hierarchy guarantees certain things about substitutionality, like whether or not something can be substituted for something else. That affects language design in ways that a lot of programmers are kind of intuitively familiar with, but maybe not familiar with the theory and the ideas behind it more concretely. But LSP is the principle in SOLID, that's the L and SOLID. And it represents a portion of the whole idea of object oriented programming in PHP. Part of being able to substitute one object for another, based on their class hierarchy, and what they implement, and what they provide is there part of their ability to be substituted is whether or not they can fulfil the same kind of contractual requirements of typing. And with Liskov, that means that preconditions can never be strengthened, and post conditions can never be weakened. So a precondition would be a parameter type requirement. If you require that a parameters accepts an object, for instance, in PHP, you can't strengthen that requirement beyond just any object to a particular object. But you can weaken it from an object to an object or an integer with with unions. That's an example of the precondition side of it. The post condition side of it is that you can't, you can't weaken it. So if you have have, you know, if you have a return type of int, you can't have an inherited implementation return int or float, because that broadens the possible return types. They go in opposite directions. And one of them is covariance and one of them is contravariance. Derick Rethans 5:18 I can never remember which one is which. Jordan LeDoux 5:21 Yeah, basically contravariance go up the tree and covariance go down the tree. If you're thinking about widening, or sorry, narrowing. If you're thinking about narrowing, then covariance go down the implementation tree and contravariance go up the implementation tree. Derick Rethans 5:40 Okay, so how does the bottom type fit in here? Jordan LeDoux 5:43 The bottom type in any type system represents like the base type that all types originate from. And the best way in my mind to think about it is kind of just integer math. It's a thing that every programmer is going to be familiar with. And it fits, it fits all right. So you can think of the bottom type as zero integers, a lot of people would think of null as zero if they're thinking about a type system, but null is more like negative one. It's like the entire negative side of the integer system. We could say that the string type is one, and the integer type is two. And the float type is three, and maybe int or float, the union of them is five, which would be the two numbers added together. And if you describe type systems this way, then you can say, hey, if I take any type and add the value that represents the other type, then I get my result type. So if I take zero, the bottom type, and I add one, the string type, what I end up with is one, still the string type. So the bottom type is whatever type system or whatever, whatever type, when you add any other type to it, you get the type you added to it and nothing else, you just get your original thing. That's why it's called the union identity for the type system. The top type in PHP is mixed. And that's the opposite side of it. It's just like zero is the additive identity. One is the multiplicative identity. If you multiply anything by one, you're going to get what you originally had. And if you add anything to zero, you'll get what you originally had. So mixed ends up being, or the top type in general, ends up being the intersection identity, and the bottom type, or never, in PHP's case, ends up being the union identity. And all this is like deep type theory, but most programmers don't have to interact with it. It's more something that affects language design usually. Derick Rethans 7:48 Could you think of mixed as being infinity? Jordan LeDoux 7:50 That's actually with my with my crude integer analogy, yeah, it would be like all types, all possible types are added together. Derick Rethans 7:59 That makes sense then. Okay, so we have explained what the bottom type is, but, and never being the bottom type. So why is it useful to use the bottom type, or never, as this RFC proposes, as a method argument type for parameters? Jordan LeDoux 8:14 The largest benefit has to do with what we were talking about when it comes to covariance versus contravariance. You know, can you strengthen the requirements? Or can you weaken the requirements? When you inherit a method in a system that preserves Liskov Substitution, the parameters can be widened, they can accept more things. If I had an interface that said, it has one parameter, and that parameter is typed as int, then in any implementation, I could say, okay, but actually, the parameter type is int or float, I'm going to accept both. And I could do that in the implementation. But I would have to accept int, because that's part of the contract. That's part of the interface. So I have to accept whatever type is in the interface. I can just additionally add things on top of that. If I make my original definition, my root definition, the bottom type, then I can add any type to it. And I will just get that type. From never, if I had an interface with, you know, a method foo, and it has one argument, and that argument is typed never, I can re-type that argument as int, or I could re-type that argument as string, and all of them would be valid inheritances. Derick Rethans 9:38 So it's a way of getting around having at least one concrete type like int in an interface. Jordan LeDoux 9:44 Right. And in fact, never is a concrete type. It's a concrete type, that means this code can never be called. For return type, it means this type will never return. But if you're, if what you're trying to do is call it then you can never call it. Derick Rethans 10:01 Which is then why never actually makes sense as a type name, because one of my further questions is going to be how does never as a name make sense? But you've now explained it in such a way that it actually does make sense. So there we go. Jordan LeDoux 10:15 One of the questions that did come up in the internals discussion on this so far, has been a round that choosing never, and because a lot of the examples for use cases are around inheritance, it makes some kind of intuitive sense, if you're describing the inheritance behaviour, to name it something like any or anything, or you know, something about its how permissive it is in its inheritance definition. But the type should really describe the code that it's actually written in. You know, getting outside the idea of an interface or an abstract or something like that. If you have a function, and that function types it as never, or whatever you name, the bottom type. There's no data that can satisfy that. Because any data will have some type other than never. It'll have string, or int, or something. Even null has the null type. You can't provide any data to a function that requires never that will satisfy its type requirement. So that code can never be called. It's really when you start considering how does this affect inheritance that you start getting into this concept of Oh, maybe a different word makes sense. But then that doesn't really reflect the opposite side on the return side, when you're talking about covariance instead of contravariance. And that's why the bottom type for most languages is something like never, or nothing, or nil, something along those lines. Derick Rethans 11:48 So if you type an argument to a method as never, the engine will, of course, enforce that you can't call it with any data because it wouldn't satisfy. But would it also automatically make a method abstract so that inheritance inheriting classes have to widen it or not? Jordan LeDoux 12:04 So that was part of my original idea behind the RFC, was forcing something that implements it or something that inherits it, to widen it. However, there were a lot of good arguments about why that may not be a good idea. One is that in PHP, an empty type isn't an empty type, it's mixed, not widening, would actually just be saying the type is mixed, which is valid, you can go from the bottom type to the top type in a contravariant way, that's a totally valid way to do it. The problem is that PHP has a weakly enforced typing system. Like that's only a problem in this context, it's actually a very powerful feature of the language in a lot of other contexts. So we don't necessarily want to get rid of that. In addition to that, the actual mixed type as a literal that can be used in the language was only added in 8.0. It would kind of represent a much larger backwards compatibility break to require it to be explicitly widened. That was part of my original concept for a lot of the reasons that you were just talking about. But for PHP, specifically, it would probably present more problems than it would provide kind of solutions and utility. I've kind of been convinced off that point a little bit by the arguments of others. Derick Rethans 13:22 Would it be possible to instantiate a class that has a method with its argument typed as never? Jordan LeDoux 13:28 Yes, as long as he never called that argument directly.Using a never type in a constructor would definitely be a definitely be a No, no, that would result in a type error. As soon as you try to instantiate the class. Derick Rethans 13:41 It would basically make the constructor private. Jordan LeDoux 13:43 Yeah, you would get a slightly less useful error. Derick Rethans 13:47 Yes. Jordan LeDoux 13:48 Then you do if you make the constructor private, and then try and call it. Derick Rethans 13:53 It makes no sense to do it. The RFC slightly touches on generics. And it goes in a way talking about why this is sort of slightly like generics. Could you explain the interaction between these two concepts? Jordan LeDoux 14:07 Generics is a feature obviously, that a lot of PHP developers want. And it's also a very complicated feature to do. Way outside of what I was willing to consider for, for my first, my first attempt at something useful. One of the most common ways that generics are used, is within an inheritance structure to allow something similar to type widening, particularly for parameters. Being able to say, I want the type to be able to be widened, but I don't know exactly how it will be widened. That's something that generics offer. Generics offer many other features as well and many other capabilities. But that particular one is something that this can do. It comes with a cost though, because this isn't generics. It is not really the right way to do that. It can be done without generating compile errors now, if you use never, that's the main difference. You still would encounter errors in static analysis and IDE hints, for instance. The IDE, he wouldn't be able to tell if you typed against a interface that had never as a parameter type, it wouldn't be able to tell what sorts of types the implementers have. Because that's not really the point of accepting an interface as a type for a parameter, or for a function call, or something like that. The point is that any implementer of this will be an acceptable type. But that means that from a static analysis perspective, it won't know what the type requirements are, because it won't know what concrete implementations are being provided in the code. So obviously, this is a limitation. And this limitation does not exist in a in an actual generics implementation of some kind. I do view it as an improvement personally. And the main reason is that before, if you tried to do something like this, then the errors that you generated and the problems that you caused, were in your code, in its actual execution. Now, the errors and the problems that you need to solve are going to be in your static analysis or in your IDE. And that's, that's something that's a lot safer for the code in general. It can present some maintainability challenges, it can be annoying for developers to deal with, all of that's absolutely true. And it doesn't provide all the things that you would want from being able to do that. It moves the where the safety problems are from being in code execution, where it can cause real problems into code writing, which is where you have the opportunity to kind of think about it, reason about it and catch it. Derick Rethans 16:54 From what I understand is that if you have a class doing implementing some kind of generics, then you'd often expect that where this generic type is used in either argument parameter, or return value, that'd be the same for all the methods, whereas with never, you can of course not enforce it, that it isn't being the same type being used, in all the other places where you would otherwise expect or enforce with generics to be the same type. So I reckon that's one of the differences. I think that was a better explanation that what I read from the RFC. Jordan LeDoux 17:25 That was a explanation and in argument that I wasn't forced to actually articulate until I presented it to other people, because I went through several days of research before even writing the RFC. And sometimes when you do that, particularly for you know, for programming related things, you just absorb the information and you kind of forget about what did I, which things were new, like which things that I just learned, and which things that I already know. You just integrate it all into your new programming knowledge. And so that was definitely something that when I wrote the first draft of the RFC, I didn't, didn't articulate particularly well, because I it just made sense in my head. And I had forgotten: Hey, this is something I didn't know a week ago, I should probably explain it to others. Derick Rethans 18:10 That's why we have the RFC process, right? So that other people also voice the opinion, and perhaps all the slightly confused language that make perfect sense to the author, but not necessarily to other people that read it, right? Jordan LeDoux 18:23 Yes. Derick Rethans 18:24 The RFC kindly mentioned that there's no backwards incompatible changes. So that's always good news, that makes it a little bit easy to accept. What was sort of the biggest pushback against the RFC? Jordan LeDoux 18:36 Initially, actually, the most pushback that I got, when I presented it, was a round choosing never as the name, which I thought would, in my mind, I thought would be something that was barely discussed, actually. But I mean, that again, just like you said, that's why this process exists. So that everybody can actually understand, you know, the things that go into it. I did do the research into that prior, but I couldn't find a single language that had more than one bottom type. The concept of more than one bottom type itself, if you if you go back to the integers concept, that'd be like having what positive zero and negative zero or something like that. It's a concept that just intuitively when you, when you understand how the type system itself works, you feel like okay, so there's probably something wrong from a design perspective, if you have more than one bottom type. It's very easy to not be able to see that intuitively. If you don't go in and take a really deep look at how the type system works or, or how types in general work and what they mean and stuff like that. That was the biggest pushback that I got initially. That mostly just involved explaining the things that I just said about like, why is that the case? Why does that make sense? What are some examples of other languages? Just going into that kind of information. The biggest blocker at the moment, really is about, does it make sense to provide never as a parameter type? If you can't use that statically? If you can't use it in a static analysis situation, then does it make sense to ever use it? And if it doesn't make sense to ever use it, then even if it provides contravariance, is it worth adding? And that's the main discussion that's being had right now, that's not entirely resolved. I think that there is still value in doing that. I think that that argument would carry a lot more weight with me personally, if PHP had a better way of handling the situations where that might happen. That's a much larger undertaking, which I would be interested in, but is also not really not really something that would be as kind from a backward compatibility standpoint. Derick Rethans 20:54 Which we are quite keen on. Jordan LeDoux 20:57 Right, exactly. I don't personally see a way that this type of functionality could be provided, that could satisfy that concern, and not also invalidate enormous amounts of code that currently exist. You kind of have to choose one or the other from my understanding. I will be very pleased if somebody is able to provide me a way to, even if it's a lot of work, provide me a way that that can be accomplished without breaking a lot of code. That was one of my goals is I don't want this, I want this to be an addition to what currently exists, not not something that breaks the current typing that we have, or the way that PHP developers currently interact with the type system or anything like that. That's the current discussion. And I think the thing that is most unresolved. Derick Rethans 21:46 I think you'll have a hard time trying to introduce breaking changes into the language. And I also think rightfully so. Jordan LeDoux 21:54 Yeah, it's it's a good safeguard. And it's a good principle to have in general, I think. I think the way that I described it is that this type of breaking change, the type that would be necessary, wouldn't really be like the type of breaking change you expect in a major version, it would more be like a parallel language syntax. It'd be more like rewriting PHP into a different language with very similar semantics, but very different idea of what the language means underneath. Because fundamentally, in order to do that, typing could no longer be optional anywhere. It would have to be every variable, every piece of data, every function, would have to have an explicit type that the developer is able to control and modify and mutate as they want. I don't even know if type juggling would be possible with the kind of change that would be necessary. And that's, that's half of what PHP consider PHP, so. Derick Rethans 22:55 Definitely not requiring types and places. Because I think, as I said, I think you'll have a hard time convincing people to go that way. Jordan LeDoux 23:02 Which is the reason I didn't consider going that way, really, so. Derick Rethans 23:06 Would you have anything else to add that I'm, that we missed discussing this RFC? Jordan LeDoux 23:10 This RFC is really interesting to me personally, just from an intellectual perspective. I think that for a lot of users, there's not a lot of use cases where you would use it in your own programs. If you did, it would end up being in like the very core base systems, and only in a few places. In those places, it might really shine, it might be something that's absolutely incredible. Most places in most programs you would never be using, well, you would never be using this type. It's much more critical for some of the internal features things like array access, that interface, and the typing that it requires for parameters. The typing for that's pretty broken. This could be a way that we could fix that possibly, and a couple of the other internal engine features that are implemented through interfaces and things like that would also probably be helped quite a bit by this. Derick Rethans 24:10 Thank you very much for taking the time today to talk about the Never For Parameter Types RFC. Jordan LeDoux 24:16 Thank you for having me. Derick Rethans 24:20 Thank you for listening to this installment of PHP internals news, a podcast dedicated to demystifying the development of a PHP language. I maintain a Patreon account for supporters of this podcast as well as the Xdebug debugging tool, you can sign up for Patreon at https://drck.me/patreon. If you have comments or suggestions, feel free to email them to derick@phpinternals.news. Thank you for listening and I'll see you next time. Show Notes RFC: Never For Parameter Types Credits Music: Chipper Doodle v2 — Kevin MacLeod (incompetech.com) — Creative Commons: By Attribution 3.0

In this episode, I sit down with board certified psychiatrist Dr. David Liskov, MD FAPA and discuss the importance of mental health, and breaking the stigma that is attached to getting the help we might need.  Dr. Liskov is a practicing psychiatrist and mental health expert from northeastern Pennsylvania. He has over 39 years experience in the medical field, and over 20 years in mental health. He has worked as a medical director for First Hospital in Kingston, Pennsylvania, clinical associate professor in the Department of Psychiatry for the Commonwealth Medical college in Scranton, Pennsylvania, Medical director of Behavioral Medicine Unit for Mercy Special Care Hospital in Nanticoke, Pennsylvania, and myriad other consulting positions as well has his private practice. **DISCLAIMER: This is NOT personal medical advice. If you are in crisis, please call 911. If you are not in crisis but wish to seek help, please contact your personal physician for a referral or your local or state website for more resources. Below are listed resources for Pennsylvania and New York as well as the link to the National Suicide Prevention Lifeline website.  NATIONAL SUICIDE PREVENTION LIFELINE 24 hour NUMBER: 800-273-8255 Pennsylvania Mental Health Resources New York Mental Health Resources National Suicide Prevention Lifeline Music by Colin Bell

In this episode we welcome back Tony and Klaus to talk about the [SOLID](https://en.wikipedia.org/wiki/SOLID) Principles, and how they relate (or not), to C++. Tony is about to give a keynote at C++ Now about his take on the SOLID Principles. Klaus has been giving a talk on applying SOLID to C++ and even Phil has recently given a talk on a similar topic. Perhaps somebody should have mentioned this to Tony before! Along the way we get plenty of SOLID advice, discover what the single responsibility is that Tony's objects have, what COLID is, who is going to argue against Liskov, and who is just there for the jokes. The answer, of course, is: it depends.

PHP Internals News: Episode 81: noreturn type London, UK Thursday, April 15th 2021, 09:09 BST In this episode of "PHP Internals News" I chat with Matthew Brown (Twitter) and Ondřej Mirtes (Twitter) about the "noreturn type" RFC. The RSS feed for this podcast is https://derickrethans.nl/feed-phpinternalsnews.xml, you can download this episode's MP3 file, and it's available on Spotify and iTunes. There is a dedicated website: https://phpinternals.news Transcript Derick Rethans 0:15 Hi I'm Derick. Welcome to PHP internals news, a podcast dedicated to explaining the latest developments in the PHP language. This is episode 81. Today I'm talking with Matt Brown, the author of Psalm and Ondřej Mirtes, the author of PHPStan, about an RFC that I propose to alter the noreturn type. Matt, would you please introduce yourself? Matthew Brown 0:37 Hi, I'm Matthew Brown, Matt, I live in New York, I'm from the UK. I work at a company called Vimeo, and I've been working with for the past six years on a static analysis tool called Psalm, which is my primary entry into the PHP world, and I, along with Ondřej authored this noreturn RFC. Derick Rethans 1:01 Alright Ondřej, would you please introduce yourself too? Ondřej Mirtes 1:04 Okay, I'm Ondřej Mirtes, and I'm from the Czech Republic, and I currently live in Prague or on the suburbs of Prague, and I've been developing software in PHP for about 15 years now. I've also been speaking at international conferences for the past five years before the world was still alright. In 2016, I released PHPStan, open source static analyser focused on finding bugs in PHP code basis. And somehow, I found a way to make a living doing that so now I'm full time open source developer, and also father to two little boys. Derick Rethans 1:35 Glad to have you both here. We're talking about something that clearly is going to play together with static analysers. Hence, I found this quite interesting to see to have two competitive projects, or are the competitive, or are the cooperative. Matthew Brown 1:56 I think half and half. Derick Rethans 1:57 Half and half. Okay. Ondřej Mirtes 1:59 Competition is a weird concept in open source where everything is released for free here that Derick Rethans 2:04 That's certainly true, but you said you're making your living out of it now so maybe there was something going on that I'm not aware of. In any case, we should probably chat about the RFC itself. What's the reason why you're wanting to add to the noreturn type? Ondřej Mirtes 2:18 I'm going to start with a little bit of a detour, because in recent PHP development, it has been a trend to add the abilities to express various types natively, in in the language syntax. These types, always originally appeared in PHP docs for documentation reasons, IDE auto completion, and later were also used, and were being related with static analysis tools. This trend of moving PHP doc types tonight this type started probably with PHP seven that added scalar type hint. PHP 7.1 added void, and nullable type hints, 7.2 added object type, 7.4 added typed properties. And finally, PHP, 8.0 added union types. Right now to PHP community, most likely waits for someone to implement the generics and intersection types, which are also widely adopted in PHP docs, but there's also a noreturn, a little bit more subtle concept, that would also benefit from being in the language. It marks functions and methods that always throw an exception, or always exit, or enter an infinite loop. Calling such function or method guarantees that nothing will be executed after it. This is useful for static analysis, because we can use it for type inference. I have an example, when you're accepting nullable object as a function parameter, you probably want to eliminate the null value before you can safely call a method on it. So, you will write if $object, three equal signs null, somehow handle this situation, and at the end of the if statement, you will return, or throw an exception. But instead of return, or throw, you might choose to call framework specific or a library specific function, that also always throws or exits the process. This will also tell the user, the IDE, and the static analyser, that below the if statement, the variable can no longer be null. For example, if you ever called mark test skipped in PHP unit, or if you call the abort function in Laravel, you've already used the function that would benefit from being marked with noreturn keyword. Derick Rethans 4:24 You mentioned that currently people use the docblock no it @noreturn for that. Why would it be better to have it in the language? Matthew Brown 4:31 Jumping off, Ondřej's point. PHP has this has this thing, right, you know things where the doc block, but PHP also, it's a language where developers are used to the language telling them if they did something wrong. So whereas other languages, you might need, like for example, JavaScript, they can be a bit more permissive. Developers when they write PHP code, they're used to getting errors instantly. They call a function with an object instead of a string, and expects a string, and it's marked in the signature as expecting a string, when they run that they get an error. And so that's just a kind of way that most PHP developers write cod. With a noreturn type, we sort of thought that there's a benefit to developer, having written a noreturn type, instantly getting an error if they actually do something that returns. So it follows that pattern that PHP has adopted, of, if I do something that violates a type that I've annotate, that I've explicitly added to the function, PHP should error. There's also a useful sort of side effect here, which is that when you add noreturn to a function, it's guaranteed that it will never return the context. If you call it, it will never not return because it will either whenever not throw an exception or exit, because if the noreturn is invalid, if it does actually do something where it's returning somehow, PHP will then throw a Type error. Cause it's supported by the language. If it wasn't supported by the language, you'd be able to use a function that called noreturn, and it wouldn't actually return. I mean obviously Ondřej and I are big fans of static analysis. The language itself isn't just to pat ourselves on the back and think, you know, we had the right idea when we were doing static analysis, it's because it can help PHP developers write code. Derick Rethans 6:16 The void return type can only being used in specific locations, I mean you can't type a property for examples void. Are the similar restrictions on where noreturn can be used? Ondřej Mirtes 6:27 Yeah, right now it can be used just as a return type. There might be some other possible usages, but they are not part of this RFC. For example the noreturn bottom type could be used as a parameter type to denote a function that shouldn't be called. So, this might be some relevant use case, but I've already had a feature request for PHP Stan, to actually support this type as a parameter type for callbacks that should never be called, but I don't remember why that person wanted this. Once we have generics, or at least the possibility to type what's in an array, we could also use the no return type for that. For example, array that contains noreturn, or never, would mean that the array is empty. And also during static analysis, the type inference engine also produces this type internally, basically to mark dead code. So for example if you ask better variable that can only ever contain an integer, if that variable can be a string, you're creating a condition that cannot be executed, that will be always false, and the resulting type of the variable inside that condition is the same type as noreturn or never. Derick Rethans 7:41 You mentioned never there we haven't spoken about yet, but we'll get back to that in a moment I'm sure. Is there any prior art for this? Matthew Brown 7:47 Yes, a number of languages have a noreturn type. Hack has specifically a noreturn type, Hack, if anyone listening doesn't know, hack is a language created as a sort of offshoot of PHP. Engineers at Facebook, when they were running into issues with PHP from about the moment they started using it in 2007/2008 as the site started growing, and performance really became an issue. And so eventually they created their own version, basically. And one of the benefits of working at Facebook is, you have lots and lots of smart engineers, and they added a lot of different typing functionality to this new language. And so one of the things I added was a noreturn type, as well as adding generics and many, many other things. Another language with prior art is type script. TypeScript has a never type, which is essentially the same. It's a bottom type as Ondřej was talking about. And a bottom type is the subtype of all subtypes. You have a class structure, you have exception, and then you have a child class of logic exception, and noreturn, is the subclass of subclasses of the child class, the thing right at the bottom of the type hierarchy, and so it can always be returned when you would expect some other thing. But basically, this is the understanding of what a bottom type is. I talked about interpreted languages to interpreted languages, but also many compiled languages, most recently Rust, that have the notion of a bottom type. It's a type, where you're guaranteed that program execution ends, in some way shape or form. Derick Rethans 9:23 You mentioned that noreturn is the bottom type, how does that play with variance that PHP implements? Matthew Brown 9:32 The concept of variance for return types is essentially, if a parent method returns something like a, an exception class, the child classes can either return an exception class, or they can return children for that same method of the exception. So let's say I have a method getException, that is described as returning an exception, the child methods in our child class, so child::getException can either return an exception, or they can also say they return a child class, so they can say, I actually return a logical exception, and this is valid according to Liskov substitution principle, which is to say: you're allowed to return a child type of whatever the overridden method was. So where this comes into play with noreturn is, noreturn is defined as is the bottom type is at the very bottom of all those class structures, you can always return a bottom type, basically And this makes sense if we just think about it, you're not breaking a contract, if your function always returns or exits; the variance rule to kind of follow that. Derick Rethans 10:43 How would that compare with void? Because void has some interesting variance rules as well right? Ondřej Mirtes 10:49 Actually, no or little similarities between void, and noreturn. Because when you are calling a void function or method, you expect it to do something, and then actually continue in the execution flow. Not expect to read the return value, but with noreturn, you call a method, and you don't expect it, the execution flow to continue. These are completely different, and I actually don't know how people can mistake one for the other. Derick Rethans 11:22 Yes, seems very, very different to me as well. The RFC talks about alternative ways of introducing noreturn. And one of the things that had mentioned, is using the attribute. Attributes, being introduced in PHP 8.0. Why did you decide not to implement it as an attribute or suggested as an attribute instead? Matthew Brown 11:43 Attributes I think are really cool. I think attributes have a place in the language, obviously they have a place as the RFC described, in place a docblocks, they can be reflected very quickly at runtime. And I also I'm interested in ideas like a deprecated attributes. And also I've just been kind of toying around in my head, the idea of a pure attribute, which could guarantee at runtime that a function with that attribute, was pure. It would never, for example, use a property, or it would never use like a static variable. We could guarantee purity of functions which would interest the pure functional programming people Derick Rethans 12:26 Could you explain what a pure function is? Matthew Brown 12:28 A pure function is a function that doesn't use any other data but the data you provide it. If I have a multiply function that takes two parameters, x and y, and it returns the multiplication of those things, you would call that function pure. There are many ways the function can become impure. One of the ways is it can have output, you can have IO output for example so if the body of the function you then echo the value of x, before returning, that function becomes impure because it's changed the environment that it operated in slightly. Additionally, if you metal memorize the value of x. So let's say you have x and y as inputs, and then in the first line, you take the value of a property elsewhere, and you add x to that value, and then you multiply that result, then that function is also impure, you're using data from outside the function to return this value. So the idea of a pure function is one which essentially can be modelled mathematically, and that's why some kind of purists, like the this idea because it allows things to be modelled mathematically, but more importantly, then it allows those functions to be tested very effectively. Some implements purity, so that you can add a docblock annotation to function and it will tell you that, whether or not the function is pure. This has extra benefits when writing really complex code. So the most complex code that Psalm has, which performs some boring computation, I've added these pure annotations everywhere. And what it does, it forces me to write the code in a way that avoid side effects. The hope is from my end that writing this very complicated code in a pure fashion, makes it easier to debug at some later date. Derick Rethans 14:20 Thanks for that. Matthew Brown 14:21 I think attributes are great and have these uses. I don't believe that attributes are useful to encode types, because PHP has a place where you can already represent types, you know, we've introduced into the language itself, the notion of typing, you know obviously many years ago. I think there is a benefit to where possible, keeping the types as types. There was a suggestion that noreturn could be an attribute instead, because it in some way it's it's really about behaviour. But it's still a type, and in the wider programming community, there is prior art for it to be considered a type. So there's basically no benefit to my mind so making it an attribute. And as well, the implementation as a type is very small, you know, it's less than, well under 100 lines of actual written PHP to implement this feature because it uses the existing checks that we already use. We also use for other return types, and to make an attribute we kind of take it out and very much expand the implementation. There are two good reasons there to not want to use an attribute. Ondřej Mirtes 15:31 There are not very useful combinations. If noreturn was an attribute, then what would you write as a return type. There are not many useful combinations of what it could be. Derick Rethans 15:44 And it also can't be used with any kind of variance rules any more. Matthew Brown 15:48 Or at least if it were to be used for variance rules then we would have to write that logic. You'd be like why are we writing this logic in this particular way, it wouldn't make sense. Derick Rethans 15:57 Because noreturn is a type, and not a behavioural thing. Makes perfect sense. Matthew Brown 16:03 But it's both a type and a behaviour. In the same way that when you actually say, this function returns a thing, PHP then does a behavioural or check to make sure that that function always returns. You could argue that every type is essentially a behaviour, because you're saying the behaviour of this function has to return a value. Derick Rethans 16:21 Earlier, one of you mentioned instead of noreturn, the never keyword. Is that the only alternative that that was discussed are the further ones? Ondřej Mirtes 16:32 Well there's noreturn and never and the RFC is now going through the voting process, so the secondary vote is about the name, and some languages also use nothing. It feels more natural to say that that function never returns, or using the noreturn keyword, then, saying that it returns nothing which blends closer to the void, void keyword Derick Rethans 16:58 Earlier you were mentioning that for future scope you wanted to use this new keyword that you're suggested to introduce also in all the locations where perhaps noreturn does not make sense. Ondřej Mirtes 17:08 Yes. Also. What no return has going for it is that it's unlikely to be used as a class name somewhere so making it, whereas if key word isn't an issue, but just as you said, it looks like a key word for a single purpose being written in a return type thing that it's quite obvious which one of us two like which keyword, because I like never more. And one reason is that it's a single word and it reads more naturally in the source code, and it's also looks more like a full fledged type and TypeScript, uses the same keyword. Derick Rethans 17:42 Why did you put noreturn in the RFC? Ondřej Mirtes 17:44 Because Matt likes it more. Matthew Brown 17:47 Yeah, I wrote the first draft of the RFC, I got first dibs, but this is a big point of contention with Ondřej and I, and we're almost at the point of not speaking to each other, because I'm on one side and he's on the other. And it looks at the moment like never will succeed. I think the TypeScript thing is a good point. When I wrote the RFC originally, I wasn't thinking that so many PHP developers write TypeScript. I hadn't really factored into my head. And I think, given that it does make more sense that never is used. Derick Rethans 18:21 Looking at how recurrent voting is going, never has 32 votes going for it, and no return has 14 votes going for it. Ondřej Mirtes 18:29 Just kidding. I can't wait to have a beer with him again, once the world is, is fine again. Derick Rethans 18:35 Me as well. Matthew Brown 18:36 He can't start inventing new words; like yeah ironically naming is hard right. Derick Rethans 18:41 Definitely the case. At the moment it's very clearly looks like that, the new keyword is going to be never, with 40 votes for introducing a keyword to begin with and 10 against, so that looks like a done deal. Would either of you have anything else to add? Ondřej Mirtes 18:57 Yeah, Derick, last time I refresh the wiki, I noticed that you haven't voted yet so what is going to be your vote? Derick Rethans 19:04 I intend not to vote until I've spoken to the people on the podcast. Matthew Brown 19:09 Great, great. Derick Rethans 19:10 I will make sure to vote. Having said that, thank you very much for taking the time today to talk to me about this RFC. Matthew Brown 19:17 Thank you. It was a pleasure. Ondřej Mirtes 19:19 Yeah, I've been following this podcast closer since the beginning, so I'm happy I was able to finally join, and have something to talk about here. Thank you. Derick Rethans 19:26 Thank you for listening to this instalment of PHP internals news, a podcast dedicated to demystifying the development of the PHP language. I maintain a Patreon account for supporters of this podcast as well as the Xdebug debugging tool. You can sign up for Patreon at https://drck.me/patreon. If you have comments or suggestions, feel free to email them to derick@phpinternals.news. Thank you for listening and I'll see you next time. Show Notes RFC: noreturn keyword Credits Music: Chipper Doodle v2 — Kevin MacLeod (incompetech.com) — Creative Commons: By Attribution 3.0

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!

Questa settimana vediamo per cosa sta la lettera "L" di SOLID, e quindi il "Liskov Substitution Principle".

In this week's episode, we go deep into Consensus Algorithms and HotStuff (https://developers.libra.org/docs/crates/consensus) with Ittai Abraham (https://twitter.com/ittaia) from VMware Research (https://research.vmware.com/). We chat about the evolution of consensus algorithms, BFT, and how these early ideas have become the backbone of blockchain tech. We cover PBFT, Tendermint and Ittai's research into SBFT, HotStuff, and the improvements he has been working on since HotStuff's incorporation into Facebook's Libra protocol. The papers and references we mention: * Early zkpodcast episode on consensus with Robert Habermeier (https://www.zeroknowledge.fm/15) * PBFT (Castro and Liskov) (http://pmg.csail.mit.edu/papers/osdi99.pdf) (see project here (http://www.pmg.csail.mit.edu/bft/)) * BASE (Castro, Rodrigues, and Liskov) (http://cygnus-x1.cs.duke.edu/courses/cps210/spring06/papers/base.pdf) (the forgotten companion of PBFT that suggests a clean State Machine abstraction) * Consensus in the Presence of Partial Synchrony (Dwork, Lynch Stockmeyer) (https://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf) * Consensus in the Presence of Partial Synchrony (Dwork, Lynch Stockmeyer) (https://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf) (this paper won the 2007 Dijkstra award) (https://www.microsoft.com/en-us/research/blog/microsoft-researchs-dwork-wins-2007-dijkstra-prize/) * Multiple leader BFT (Katz and Koo) (https://eprint.iacr.org/2006/065.pdf) Some of Ittai's work: * SBFT (with Golan, Grossman, Malkhi, Pinkas, Reiter, Seredinschi, Tamir, and Tomescu) (https://arxiv.org/pdf/1804.01626.pdf) * Hotstuff (with Yin, Malkhi, Reiter, and Golan) (https://arxiv.org/pdf/1803.05069.pdf) * Asynchronous BFT (with Malkhi and Spiegelman) (https://arxiv.org/pdf/1811.01332.pdf) * Sync Hotstuff (with Malkhi, Nayak, Ren, and Yin) (https://eprint.iacr.org/2019/270.pdf) * Optimal Good-case Latency for Byzantine Broadcast and State Machine Replication (with Nayak, Ren, and Xiang) (https://arxiv.org/abs/2003.13155) new! * On the Optimality of Optimistic Responsiveness (with Nayak ,Ren, and Shrestha) (https://eprint.iacr.org/2020/458.pdf) new! Ittai's group blog on cryptography and consensus: Decentralized Thoughts blog (https://decentralizedthoughts.github.io/) We also mention: * Tendermint (https://atrium.lib.uoguelph.ca/xmlui/bitstream/handle/10214/9769/Buchman_Ethan_201606_MAsc.pdf?sequence=7&isAllowed=y) (from 2016 not 2014) * Casper FFG (https://arxiv.org/pdf/1710.09437.pdf) * Thunderella (https://eprint.iacr.org/2017/913.pdf) * The AVA consensus (https://arxiv.org/pdf/1906.08936.pdf) Thank you to this week's sponsor Matter Labs (https://twitter.com/the_matter_labs). Matter Labs, the creator of the first zkRollup prototype, is also the team behind zkSync: a user-centric Ethereum scaling solution, secured by zero-knowledge proofs. zkSync testnet is live! You are welcome to try out its simple and intuitive user interface at zksync.io (https://zksync.io/). If you like what we do: Follow us on Twitter - @zeroknowledgefm (https://twitter.com/zeroknowledgefm) Join us on Telegram (https://t.me/joinchat/B_81tQ57-ThZg8yOSx5gjA) Give us feedback! https://forms.gle/iKMSrVtcAn6BByH6A Support our Gitcoin Grant (https://gitcoin.co/grants/329/zero-knowledge-podcast-2) Support us on the ZKPatreon (https://www.patreon.com/zeroknowledge) Or directly here: ETH: 0xC0FFEE1B5083230a5154F55f253B6b6ae8F29B1a BTC: 1cafekGa3podM4fBxPSQc6RCEXQNTK8Zz ZEC: t1R2bujRF3Hzte9ALHpMJvY8t5kb9ut9SpQ

1. Переніс подкаст на новий хостинг, Telegram 2. GitHub is now free for teams - переніс туди свій  Pet Project. Кінець для Bitbucket? 3. Інтерфейси в Go: dependency injections, Liskov substitution principle, приймай інтерфейс на вхід - повертай структуру, інтерфейс на стороні консюмера, не потрібно дублювати інтерфейсом свою структуру (це вам не Java) 4. Запитання від Junior Go Developers: чи потрібно тестувати приватні методи (про юніт та інтерейшн тести з коробки)? Як обробляти помилки в середині goroutines (про error channels)? Чому функція log.Fatal() практично зло в реальному проекті (про error handling)? 5. Ще раз про важливість code review і мій підхід до нього 6. Книга випуску Максим Дорофеев "Путь Джедая" 7. Шукаєте ментора? А він тут - на Patreon. Сайт подкасту https://sheremetat.name, де можна коментувати Допомога подкасту https://www.patreon.com/sheremetat Goodreads: https://www.goodreads.com/user/show/90037016-taras-sheremeta Telegram: https://t.me/tl_notes Twitter: https://twitter.com/sheremetat Facebook: https://www.facebook.com/sheremetat.podcast Music by https://audionautix.com

Professor Barbara Liskov spoke with us about the Liskov substitution principle, data abstraction, software crisis, and winning a Turing Award. See Professor Liskov’s page at MIT, including her incredible CV.

Construx Principal Consultant Steve Tockey and Mark Griffin discuss design patterns in a unique way by emphasizing the importance of understanding fundamental design principles when you’re using patterns.Of the top five reasons that software projects get into trouble, the most significant issue that is directly under the control of software developers is the complexity in the code base. Both industry data and Steve’s own engagement-derived data over 20 years of software consulting support this. As Steve McConnell has argued, the prime directive of the software professional is to manage complexity.Steve and Mark dive into specific kinds of code complexity—such as cyclomatic complexity, depth of decision nesting, fan out, and number of parameters—and describe the fundamental design principle related to complexity: minimize overall complexity by balancing local and global complexity. Without measuring complexity in your code base, you can’t actually effectively control it. By measuring it, you can achieve the balance of complexities that most significantly decreases your code’s overall complexity.Steve and Mark continue by listing the fundamental design principles Steve covers in his design patterns training so as to begin to address a key question: Why is understanding the fundamental design principles important if you’re using design patterns? The list of principles applies across a broader spectrum of software creation than the SOLID principles do. Steve’s list causes you to pay attention to software attributes that you wouldn’t pay attention to if you were using only the SOLID principles.Steve argues that you can’t deeply understand what a pattern is up to unless you understand why the pattern looks the way it does. Each software pattern is primarily driven by a fundamental design principle and can be influenced by other fundamental design principles. For example, the Strategy pattern is primarily driven by the encapsulation principle and is influenced by Liskov substitutability and cohesion and coupling. Understanding the connections between design patterns and design principles vastly deepens your understanding of the patterns and their applicability.The episode ends with a thorough discussion of another fundamental design principle: encapsulation, which is achieved only via Design by Contract. The difference between code syntax and code semantics enters the discussion to help explain how code contracts operate. You have to get beyond syntax to achieve higher quality code with fewer defects, which are semantic inconsistencies. Compilers are ruthless masters of syntax but can’t help with code semantics.Links to Steve Tockey’s books:How to Engineer Software: A Model-Based Approach (Wiley-IEEE Computer Society Press, 2019)Return on Software: Maximizing the Return on Your Software Investment (Addison-Wesley Professional, 2004)

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.

In this episode of Adventures in .NET the panel interviews Patrick Smacchia who is known for his static analyzer, NDepend. The panel discusses NDepend, Patrick explains a bit about what is and how it works along with his history in .NET. Patrick is here to explains SOLID, an acronym introduced by Robert C. Martin outlining principles for object-oriented programming.  These principles teach programmers to use object-oriented programming correctly. The panel considers what can go wrong when object-oriented programming is misused. They also explain that the most important thing when it comes to SOLID is to try your best, it is impossible to be perfect in anything. Patrick explains that when your code is SOLID is will be easily testable and maintainable.  The five principles are Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion. Of all the principles, Single Responsibility is unique. Patrick explains that this principle is all about organization and advises developers to be very careful when using this principle in your domain. The domain is where it is most important to have SOLID code and it needs to be 100% covered by testing. The panel shares that this is the principle that they try the hardest to follow.   The definition given by Patrick for Single Responsibility is that a class should have a single responsibility or a class should have only one reason to change. Patrick warns the listeners that this is a very complex concept that is difficult to explain. The panel explains that Single Responsibility is a way to accomplish a separation of concern. The panel outlines the benefits of following this principle while Patrick shares some examples and walk the listeners implementing this principle.  The next principle is Open-Closed. Patrick’s definition of this principle is modules should be open for extension but closed for modification. He and the panel dive deeper into what this means. He advises developers when designing a class to be very careful when choosing the point of variation and make sure you don’t change the code in your base class. Caleb shares the problems they experienced in one of his recent projects when this principle was not followed. Patrick explains why the solution is more often the interface rather than the base class.  Moving on to the next principle, the Liskov substitution. Patrick explains how this principle using the example of the ibird. The Liskov substitution principle is that objects in a program should be replaceable so that you can’t tell the difference. In the ibird example, you can not replace the ibird with any bird because if the ibird can fly but the replacement bird is an ostrich it cannot perform the necessary functions. Patrick explains how ilists are in opposition to the Liskov principle.   Next is the Interface Segregation Principle. Patrick explains how this relates to the Single Responsibility Principle. He also discusses how the Liskov Substitution and the Interface Segregation are two sides of the same coin when it comes to designing interfaces. The Interface Segregation explains that many smaller client-specific interfaces are better that one large interface with everything on it.  The final principle is Dependency Inversion. Patrick explains that this principle does not help you design your interface, it helps you organize dependencies into your code structure.   This principle advises developers to depend on abstractions. He explains how this principle relates to dependency injection. The panel considers the damage dependencies can cause in a codebase if improperly used. Patrick explains when a developer will want to use abstractions and when to use classes. He explains that these 5 principles will become natural and feel like common sense as developers gain experience. Switching gears, the panel moves on to discuss a blogpost Patrick wrote explaining 4 predictions he had for the future of .NET. He wrote the article because of the announcement that .NET core will become .NET 5. The future of .NET has a great impact on NDepend and Patrick wanted to give some perspective to the changes and how they might affect his company.   His first prediction is that .NET standards won’t evolve much. Patrick explains that the purpose of .NET Standards was to support all the .NET flavors and with only .NET to support that job will become much simpler. He also speculates on the reasons for Microsoft wanting only one .NET. Some of the reasons he lists are that Microsoft does not have an endless workforce and .NET core is open source and multiplatform.  Patrick’s second prediction greatly impacts NDepend. His prediction is that Visual Studios will run on .NET 5, explaining why he is so sure that they will switch Visual Studios over to .NET 5. Patrick believes that it may take a while for the switch to happen. The panel considers the future of Windows.  The third prediction Patrick makes is that .NET will propose a cross-platform UI framework. Microsoft did a poll asking developers about the need for a cross-platform UI framework. The panel speculates how this framework will happen. Patrick wonders at the possibility of WPF. The panel brings up the final prediction, that Blazor has a bright future, and wonder if Blazor could become that cross-platform UI framework.   Panelists Shawn Clabough Caleb Wells Guest Patrick Smacchia Sponsors My Ruby Story React Native Radio Adventures in Angular CacheFly Links www.ndepend.com  SOLID  4 Predictions for the Future of .NET   Satya Nadella reveals why Windows may not be the future of Microsoft’s business .NET 003: Blazor with Daniel Roth https://www.facebook.com/Adventures-in-NET-373059030062837/ https://twitter.com/dotNET_Podcast Picks Caleb Wells: https://www.packtpub.com/free-learning  Shawn Clabough: https://conemu.github.io/ 

In this episode of Adventures in .NET the panel interviews Patrick Smacchia who is known for his static analyzer, NDepend. The panel discusses NDepend, Patrick explains a bit about what is and how it works along with his history in .NET. Patrick is here to explains SOLID, an acronym introduced by Robert C. Martin outlining principles for object-oriented programming.  These principles teach programmers to use object-oriented programming correctly. The panel considers what can go wrong when object-oriented programming is misused. They also explain that the most important thing when it comes to SOLID is to try your best, it is impossible to be perfect in anything. Patrick explains that when your code is SOLID is will be easily testable and maintainable.  The five principles are Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion. Of all the principles, Single Responsibility is unique. Patrick explains that this principle is all about organization and advises developers to be very careful when using this principle in your domain. The domain is where it is most important to have SOLID code and it needs to be 100% covered by testing. The panel shares that this is the principle that they try the hardest to follow.   The definition given by Patrick for Single Responsibility is that a class should have a single responsibility or a class should have only one reason to change. Patrick warns the listeners that this is a very complex concept that is difficult to explain. The panel explains that Single Responsibility is a way to accomplish a separation of concern. The panel outlines the benefits of following this principle while Patrick shares some examples and walk the listeners implementing this principle.  The next principle is Open-Closed. Patrick’s definition of this principle is modules should be open for extension but closed for modification. He and the panel dive deeper into what this means. He advises developers when designing a class to be very careful when choosing the point of variation and make sure you don’t change the code in your base class. Caleb shares the problems they experienced in one of his recent projects when this principle was not followed. Patrick explains why the solution is more often the interface rather than the base class.  Moving on to the next principle, the Liskov substitution. Patrick explains how this principle using the example of the ibird. The Liskov substitution principle is that objects in a program should be replaceable so that you can’t tell the difference. In the ibird example, you can not replace the ibird with any bird because if the ibird can fly but the replacement bird is an ostrich it cannot perform the necessary functions. Patrick explains how ilists are in opposition to the Liskov principle.   Next is the Interface Segregation Principle. Patrick explains how this relates to the Single Responsibility Principle. He also discusses how the Liskov Substitution and the Interface Segregation are two sides of the same coin when it comes to designing interfaces. The Interface Segregation explains that many smaller client-specific interfaces are better that one large interface with everything on it.  The final principle is Dependency Inversion. Patrick explains that this principle does not help you design your interface, it helps you organize dependencies into your code structure.   This principle advises developers to depend on abstractions. He explains how this principle relates to dependency injection. The panel considers the damage dependencies can cause in a codebase if improperly used. Patrick explains when a developer will want to use abstractions and when to use classes. He explains that these 5 principles will become natural and feel like common sense as developers gain experience. Switching gears, the panel moves on to discuss a blogpost Patrick wrote explaining 4 predictions he had for the future of .NET. He wrote the article because of the announcement that .NET core will become .NET 5. The future of .NET has a great impact on NDepend and Patrick wanted to give some perspective to the changes and how they might affect his company.   His first prediction is that .NET standards won’t evolve much. Patrick explains that the purpose of .NET Standards was to support all the .NET flavors and with only .NET to support that job will become much simpler. He also speculates on the reasons for Microsoft wanting only one .NET. Some of the reasons he lists are that Microsoft does not have an endless workforce and .NET core is open source and multiplatform.  Patrick’s second prediction greatly impacts NDepend. His prediction is that Visual Studios will run on .NET 5, explaining why he is so sure that they will switch Visual Studios over to .NET 5. Patrick believes that it may take a while for the switch to happen. The panel considers the future of Windows.  The third prediction Patrick makes is that .NET will propose a cross-platform UI framework. Microsoft did a poll asking developers about the need for a cross-platform UI framework. The panel speculates how this framework will happen. Patrick wonders at the possibility of WPF. The panel brings up the final prediction, that Blazor has a bright future, and wonder if Blazor could become that cross-platform UI framework.   Panelists Shawn Clabough Caleb Wells Guest Patrick Smacchia Sponsors My Ruby Story React Native Radio Adventures in Angular CacheFly Links www.ndepend.com  SOLID  4 Predictions for the Future of .NET   Satya Nadella reveals why Windows may not be the future of Microsoft’s business .NET 003: Blazor with Daniel Roth https://www.facebook.com/Adventures-in-NET-373059030062837/ https://twitter.com/dotNET_Podcast Picks Caleb Wells: https://www.packtpub.com/free-learning  Shawn Clabough: https://conemu.github.io/ 

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.

Bu bölümde Barış'ın yokluğunu fırsat bilip SOLID konuştuk, arada dedikodusunu da yaptık. Single responsibility, Open/closed principle, Liskov substitution, Interface segregation ve Dependency inversion nedir ? Neden lazım ?

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.

PHP Internals News: Episode 10: LSP and Operator Precedence London, UK Thursday, May 16th 2019, 09:10 BST In this tenth episode of "PHP Internals News" we talk to Nikita Popov (Twitter, GitHub) about a few RFCs that are related to LSP and operator precedence. The RSS feed for this podcast is https://phpinternals.news/feed.rss, you can download this episode's MP3 file, and it's available on Spotify and iTunes. There is a dedicated website: https://phpinternals.news Show Notes RFC: Always generate fatal error for incompatible method signatures Associativity RFC: Deprecate left-associative ternary operator RFC: Change the precedence of the concatenation operator Credits Music: Chipper Doodle v2 — Kevin MacLeod (incompetech.com) — Creative Commons: By Attribution 3.0

Anglický termín code smells nám zní o malinko lépe než tvrdé české smrady v kódu, každopádně se jim chceme vyvarovat bez ohledu na jazyk a národnost. Pozvali jsme si proto Martina Dybala, aby nám osvětlil principy a doporučené postupy, kterak zachovat zdrojový kód udržovatelný, testovatelný a s minimem "WTF/min". SOLID principy: - Single responsibility - Open/closed - Liskov substitution - Interface segregation - Dependency inversion Na vaše komentáře, přání, připomínky apod. se těšíme na info@dotnetpodcast.cz. Odkazy: - Clean Code (kniha): https://www.goodreads.com/book/show/3735293-clean-code - Framework Design Guidelines: https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/ - StyleCop: https://github.com/StyleCop/StyleCop - SonarQube: https://www.sonarqube.org/ - TechEd - DevCon 2019: https://www.teched.cz/cs/ - Global Azure Bootcamp - Brno: https://www.geekcore.cz/events/6187 - Global Azure Bootcamp - Praha: https://www.geekcore.cz/events/6188 Twittery atd.: - https://twitter.com/Martin_Dybal (Martin D.) - https://twitter.com/deeedx (Martin Š.) - https://twitter.com/madrvojt (Vojta) Pokud nechcete, aby vám unikla nová epizoda, odebírejte RSS: https://bit.ly/netcz-podcast-rss, sledujte nás na Twitteru: https://twitter.com/dotnetcezet nebo na Apple Podcasts a také na Spotify. Hudba pochází od Little Glass Men: https://freemusicarchive.org/music/Little_Glass_Men/

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.

This week, Chris and Soroush talk about null, the billion dollar mistake. They talk about its past, its present and maybe even its future. Nice!enum Brain {     case small     case medium     case large     case galaxy     case universe }Liskov Substitution PrincipleNull References: The Billion Dollar MistakePython on Google App EnginePEP 484: Type HintsThe Definitive Reference To Why Maybe Is Better Than NullThat One Optional PropertyThe algebra (and calculus!) of algebraic data typesPoint-Free episode 4: Algebraic Data TypesOptional definitionSubEthaEdit

Nación Lumpen capítulo 0: Llamadme raro, pero programar es divertido En esta primera entrega hablamos sobre formación entre algunos de los miembro de Nación Lumpen, nuestra lista de correo de apasionados del desarrollo. Participantes: Álvaro Castellanos, @AlvaroCaste Álvaro Polo, @apoloval Mateu Adsuara, @demonh3x Sebastián Ortega, @_sortega Música: Organic City https://soundcloud.com/msoundcollage Enlaces: * Peopleware, http://www.amazon.com/Peopleware-Productive-Projects-Teams-Edition/dp/0321934113 * Apprenticeship patterns, http://www.amazon.com/Apprenticeship-Patterns-Guidance-Aspiring-Craftsman/dp/0596518382/ref=sr_1_1?s=books&ie=UTF8&qid=1435531386&sr=1-1&keywords=apprenticeship+patterns * La definición de Kata de Dave Thomas, el tipo que introdujo el término entre nosotros. http://codekata.com/ * Principio de sustitución de Liskov: http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple * Modelo de actores: http://c2.com/cgi/wiki?ActorsModel * Design patterns http://www.amazon.es/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612/ref=sr_1_2?ie=UTF8&qid=1435769534&sr=8-2&keywords=design+patterns * Los hobbies tecnológicos de Álvaro Polo: ** Un emulador y ensamblador correspondiente para SimProc, un microprocesador que yo mismo he inventado: https://github.com/apoloval/simproc ** Una utilidad para procesar paquetes CAS de MSX: https://github.com/apoloval/mcp ** Un Hello World usando ensamblador para MSX: https://github.com/apoloval/msx-sandbox ** Librerías Arduino para construir un simulador de Airbus A320: https://github.com/apoloval/oac-arduino ** Un componente para Flight Simulator que permite exportar datos: https://github.com/apoloval/flightvars ** Un framework de simulación de sistemas de aviónica: https://github.com/apoloval/gwaihir ** Un pequeño framework para desarrollar videojuegos de estrategia: https://github.com/apoloval/grog ** Otro framework para videojuegos: https://github.com/apoloval/Karen ** Un aborto de microkernel escrito en C++: https://github.com/apoloval/alderaan

Nación Lumpen capítulo 0: Llamadme raro, pero programar es divertidoEn esta primera entrega hablamos sobre formación entre algunos de los miembro de Nación Lumpen, nuestra lista de correo de apasionados del desarrollo.Participantes:Álvaro Castellanos, @AlvaroCasteÁlvaro Polo, @apolovalMateu Adsuara, @demonh3xSebastián Ortega, @_sortegaMúsica: Organic City https://soundcloud.com/msoundcollageEnlaces:* Peopleware, http://www.amazon.com/Peopleware-Productive-Projects-Teams-Edition/dp/0321934113* Apprenticeship patterns, http://www.amazon.com/Apprenticeship-Patterns-Guidance-Aspiring-Craftsman/dp/0596518382/ref=sr_1_1?s=books&ie=UTF8&qid=1435531386&sr=1-1&keywords=apprenticeship+patterns* La definición de Kata de Dave Thomas, el tipo que introdujo el término entre nosotros. http://codekata.com/* Principio de sustitución de Liskov: http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple* Modelo de actores: http://c2.com/cgi/wiki?ActorsModel* Design patterns http://www.amazon.es/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612/ref=sr_1_2?ie=UTF8&qid=1435769534&sr=8-2&keywords=design+patterns* Los hobbies tecnológicos de Álvaro Polo:** Un emulador y ensamblador correspondiente para SimProc, un microprocesador que yo mismo he inventado: https://github.com/apoloval/simproc** Una utilidad para procesar paquetes CAS de MSX: https://github.com/apoloval/mcp** Un Hello World usando ensamblador para MSX: https://github.com/apoloval/msx-sandbox** Librerías Arduino para construir un simulador de Airbus A320: https://github.com/apoloval/oac-arduino** Un componente para Flight Simulator que permite exportar datos: https://github.com/apoloval/flightvars** Un framework de simulación de sistemas de aviónica: https://github.com/apoloval/gwaihir** Un pequeño framework para desarrollar videojuegos de estrategia: https://github.com/apoloval/grog** Otro framework para videojuegos: https://github.com/apoloval/Karen** Un aborto de microkernel escrito en C++: https://github.com/apoloval/alderaan

This week we have a three developer podcast with discussion on a host of topics. We kick off with how Fraser has enjoyed building his first bonus slot game, written entirely in JavaScript and HTML5. Preprocessors are a huge part of the JavaScript ecosystem at this time, with so many to choose from we discuss a couple of the more popular ones. This leads on to Photoshop discussion, ReactJS, the cool features present in ES6 and how you can use them today with transpilers. Following this we move on to the SOLID principles, the overuse of inheritance, technical debt and the concept of Over-DRY vs. Software Value. This then takes us on to a strange ‘rubber duck’ example Edd conjured up to help try and explain the Liskov substitution and Interface segregation principles. Finally, we discuss Edd’s media server setup and how he has got it to a staged that he is finally happy with it.