 Richard, where did .NET come from? Let's talk about that. Hi, welcome to Visual Studio Tillbox. I'm your host, Robert Green, and joining me, Richard Campbell. Hello, friend. Hey, Richard. Good to see you, man. We just saw each other last week. We did. Yeah, down in San Francisco. And then you said, or I said, you should come on the show. And then it occurred to me that you've never actually been on this show. No, and you've been on mine, although I was not co-host at the time. Show 43. That's the .NET rocks we're talking about, by the way. You were in the original 50. The first 50 shows, that's like December of 2013, and the co-host was Mark Dunn. All right, and then Mark stepped away at the end of the first 50. And the second co-host was Rory Blythe. Cool. And so Rory, and then Rory joined Microsoft. Yeah. And then, you know, Microsoft kind of eats up a lot of your energy. Yes, it does. So I came on board with .NET Rocks at show 100. OK. And as a recording of this, we're at show 1594. Sweet. And this show is like, I think we're at about 270 or so. So you're in rare. So I don't have to feel as bad about waiting 15 years. You should be back, because I think you work on great stuff. But, you know, you've been through everything, right? Like you used to be a Fox guy. I did. And when I was on .NET Rocks, it was on Visual Studio Tools for Office. Right. Or the official name, the Microsoft Visual Studio Tools for the Microsoft Office system. Yes. Because naming is hard. Yes. So in addition to co-hosting .NET Rocks, you are working on the definitive history of .NET. Yeah, I kind of fell into it. And our mutual friend Beth Massie reached out to me back in 2017. And there was a 15-year ship party. Yes. So it had been 15 years since .NET had shipped. And they were throwing a big party. And she asked me to help out. Which means it was about 20 years since it was invented. Yeah. Something like that. Was it five years before it actually shipped? That's a fascinating question. Because the more I explore it, the more I realize, there was no intent to make .NET. It emerged. It emerged from a bunch of different problems being worked on, and then eventually people find each other. That, to me, was fascinating, that the runtime was one thing. This whole problem of you had the C++ stack, and you had the Visual Basic stack, and other languages, and how Windows features surfaced in that. As new versions of Windows coming out. And you think about back in the 90s, when Microsoft was putting out literally two lines of Windows, the NT line and the 9X line. And it was every couple of years. And so they would make improvements to the operating system. And as developers, we kind of wanted access to those. And each runtime took effort to implement those features, and took time, and the interpretation buried. Yes. And so the idea of a common runtime was trying to mitigate a bunch of that pain. Mm-hm. The other aspect of it, I find fascinating, is what became C-sharp. Because up until then, Microsoft had never invented a language. Microsoft took other existing languages, basic and so on, and did their own implementation of it, quite successfully. One would argue that Gates' original vision was uncoupling the language from the machine. If you go back into the 70s when Microsoft started, and even the 80s, where computers are iterating so rapidly that the software included with the machine was so bound to that machine, when the next machine came out, you sort of started over. Microsoft always had this angle of your programming skills using Microsoft versions of these languages work across these machines. So you're more productive as a developer. But Microsoft had a phenomenal version of Java. The J++ was wildly successful. One would argue, do successful. Plus, as the dominance that Windows had at the time, as Microsoft started tuning J++ to optimize for Windows, that became a problem for some microsystems. And so there was a pushback in the form of a cease and desist. And ultimately, they ceased and desisted. But that group of people that worked on the J++ tooling, and it's, I mean, some of our market, not just Anders Halsberg, who's extraordinary, but also, I've had, and Patrick de Sade, who was one of the key people behind the JVM implementation that Microsoft did, also heavily involved. He was the advocate for garbage collection for the CLR as well. In a company that was largely a reference counting company. And so again, it's these different pieces of, okay, well, we can't work on Java anymore. We need an up-pure object-oriented language. And we have a potential of a runtime. And those things come together. And then throw the web in. Because it was kind of a thing. J++ had one of the coolest t-shirts ever. It was a box of J++ spilled open with coffee beans. And it said, you know, our Java's the best. And then there was the legal disclaimer about what Java we were talking about. That's just, I think I still have that shirt. It's a little worn and ragged. And I'm not, I don't think I'm allowed to wear it in public, but I still have it. But also, there's lots of other projects that went on in those late stages of the 90s that was really an exploration of what do enterprise developers need? What will make them more productive? What will build software quickly and reliably in the constraints of the typical enterprise? Which is a different set of problems. And .NET came out in the internet revolution when it wasn't just, you know, com worked well, across machines or in a network. Now you have this web-based world and then you have Java's the enterprise language that's going to kill Microsoft. I mean, a number of times something was going to kill us and yet here we are. And I don't get all the murder parts of this, right? It's like, yeah, you know, if there was one right way, we'd all be doing it. There's many ways to be successful. Yes, I mean, if you've learned anything is that you can become a market leader, but it's an unbelievably competitive market, right? Sure. The iPhone didn't kill anything in or it's not gonna kill anything. No. Internet Explorer didn't kill anything. Nothing, code never dies. No, it really doesn't. Things get matured. Matured as a verb means we're not gonna really work on it anymore. But you look at the demand for Java developers today, you know, I don't know how much Greenfield Java there is, but the Brownfield Java is an epic space. It's a tremendous amount of work and the demands continue to expand. So it's an ongoing effort one way or the other, but as I dug into this story and certainly all of those early stage charts are really fun, you know, I kind of look at this as four acts, right? So there's that preliminary emergence of we need to make a thing. And then you have the second act which really comes with ship data 2002 for version one, then 1.1 and even up to two in 2005. As I think the versions where you actually made the thing you meant to make, right? This idea of a development environment that's efficient in the enterprise, it's heavily integrated, can work on the web and work on the desktop, like you look at 2.0, there's lots of people who still believe like that, we nailed it, like there was the one, it was robust, it was reliable, you could run it on a web server well, you could run it on a desktop well, like it was great. And then the third act is hard. You know, the third act is a tough time at Microsoft with Vista and a tough time around the emergence of mobile and how we're gonna deal with that. So talk a little bit about how the operating system affects how I think about .NET as a developer, right? Because unless I'm writing code that calls into operating system functions, right? And we talk about, well, we released a new version of Windows, it's backwards compatible, everything that runs in the previous version will run on this version. So I'm working on my application, I'm upgraded to Vista, which I may or may not, I've enjoyed that experience, but abstracting from that, I've still got Visual Studio, I've still got my application. What difference does that make? And I mean, we talk about one of the strengths Microsoft's always had, it's that that upgrade path was pretty painless. But it was also I think a frustration on the Windows side because often that upgrade met you never took advantage of the new features. You almost had no visibility into them. That's true because in marketing, and I was in tools marketing at the time, we had to include taking advantage of Windows features like jumpless and whatnot. And to be honest, it felt kind of paying the tax, right? Yeah. Oh, now let me shift gears entirely and show you a cool demo of something you may or may not be interested in that takes advantage of the feature in Windows and people would look at that and some people would say, oh, cool, I want that. Others would look at that and go, oh, cool, I don't think I'll ever do that. And others would look at it and go, why are you doing that? And one of the challenges there is as soon as you start talking about features like that, you're talking about changing people's workflows and people don't like that. They kind of want to keep working the way they want to work until you get a major milestone, like I need this to work on my tablet, I need this to work on my phone. And they're now prepared to make that jump in workflow and you got to kind of grab all those bits and look where. Or I need this to work on Linux. Yeah, well, if the operating system still matters, I would argue maybe this is jumping to the end of the story as I'm still gathering this history, is don't we hit a point where the operating system just doesn't matter anymore? And I think the cloud is a big part of that. It's not just the programming environment, the programming environment was ultimately influenced by the demands of people. It's that operating systems are abstracted enough away from us, we're starting to care about them just about as much as we care about the BIOS in our operating, in our machine or the microcode in the CPU. Like they're just expected to work. And so bit by bit, I think OSs have become part of the plumbing. Yes, but at the same time, if you think about Windows as an app, it takes advantage of new Windows features, right? It does. Like timelines and whatnot. And that stuff is available for you to take advantage of in your applications. We tend to think, oh, there's the apps that I use that are built by Microsoft. Oh, I expect them to take advantage of all the new features in Windows. Forgetting the fact that those are just apps calling it the API is the same way you could as well. And I think it's one of the challenges you have with an operating system today is what's operating system and what's app? I mean, I appreciate that Windows had over the decades consistently taken what used to be an add-on and turned it into part of the operating system. I mean, a clear example, that would be networking. I mean, once upon a time, you bought PCs that had no networking. And when you wanted networking, it was a separate product that you paid for. Windows for work groups. Windows for work groups. Now, I was a network certified installer. That was like Windows addition. Exactly. Yes. But eventually recognize that networking is plumbing. It should be part of the system. It's just included. Once upon a time, installing a sound card and configuring it was a thing, then it was just part of the operating system and part of the hardware. So, bit by bit, the operating system surface area grew. But at the same time, we also decorated the operating system with a lot of stuff. And you can call it part of the OS, but is it really or is it just more apps? And yeah, you want those things to interplay and see what's valuable. But it made the operating system as large as it is. So, is the .NET runtime part of the operating system? Well, that's a great question. I mean, one of the things we know for sure is that Microsoft tends to maintain support for a long time. The VB6 runtime, last updated in 1999, is still included in Windows 10. Right. Because it ships with Windows. So, it ships in the box. In the box. Not that there's boxes anymore. Because ships in the box and therefore. But it still speaks to a philosophy of, you don't break people's stuff. Right. You try and find a way forward. And when you do break people's stuff, your answer is, oops, we better fix that. And I'm, you know, I would hope you never break things, but we happen to know you do once in a while. Like stuff happens, but the reaction is all, is not working as intended. It's, oh, that's a problem. We're going to fix that. Working as intended is the software keeps running. One way or the other. But adding that surface area, I think is a very challenging part of the overall equation. So when, and when I talk about the operating system becoming less relevant, I'm talking about the plumbing parts of the operating system. Right. That networking is networking. It's all TCPIP today, right? Didn't used to be. Yep. You know, we used to have a debate about that. And virtualization is part of the operating system. So there's a couple of ways to, to think about the act of programming. One is that you type in a particular language, which may be a new language and maybe a language that looks like a language that you're familiar with, but it's basically, you type words and commands, and then there is a runtime that executes that, right? And that's all plumbing. And whether it's com or .NET or whatever comes after that, I assume there's always some type of runtime environment. I assume there's always a language that I either know or can learn to do the exact same thing, right? Every app we've ever written, you can think about it as a line of business developer. It does the exact same thing. There's data that you're managing. There's a UI which displays it and then there's code in between to marry the two, right? So no matter what you're doing, it's the exact same type of app only different because there's a different runtime, different language. So. The missions don't vary that much. And you're always interacting with underlying software that you didn't have to write. How far that abstraction goes up or down is a separate question. Right. To the extent that when we moved to .NET and we did and many people moved from VB to C sharp took advantage of all this new abilities. Yeah. To what extent do you think .NET changed how that happened or did I just do the exact same things with a different set of commands with a different runtime and what's the difference? Well, in Marshall McLuhan's great quote is first we shape the tools, then the tools shape us, right? And if you actually look at the progression of .NET you see those tools ultimately shaping us too. So right off the bat, when you think about moving to .NET and all the struggles that was surrendering ownership of memory because you don't want on it. It's a problem, right? Easy to create stuff, we'll do the cleanup for you. So a whole class of memory leaks went away. A lot of respects to say that concept went away when we stopped having responsibility for memory. Abstracting away from CPU architectures. The whole thing about just in time compilation is that it was able to say, what am I running on? Okay, let's run on that. So that problem went away and I only became aware having done long interviews with a bunch of the CLR guys about how many other processor architectures they implemented in the CLR that we largely never saw. They had a plan for Itanium. We were going to be able to simply compile to Itanium in a .NET. We ended up not needing it because Itanium didn't go anywhere. But that work got done. For the brief period that we really cared about the ARM chip set, we had to compile to ARM. That option existed. So it's funny that the power of .NET that we pretty much got in 2002 was essentially so transparent to us we almost immediately forgot about it once we stopped fighting with it. But there's subtler things. Having talked to folks like Dawn Simon, Anders Halsberg, and Mads Torgensen, the work that was done at the very beginning of .NET to support generics. And they were absolutely informed by the struggle that the Java world had had not thought early enough about how they were going to be able to do those kinds of functions. And so that they, while they didn't get it really implemented until two and we didn't get linked until three and three, five, they were thinking about that before they shipped in 2002. And that set of thoughts introduced a whole class of programming that it was even hard to explain back then. Now, one of the upsides for me being part of .NET Rocks is I remember knowing that Link was coming a year in advance. And so starting to, not that I could tell everyone, hey, this thing is coming. They want to have their launch the way they want to have their launch but that I could start preparing people. That we could start talking about lambdas and generics and mechanisms you could use around that and what advantages they were. So when the great announcement landed, folks knew they knew what to do. Oh, I see, I know how to do that. I've learned about this already. Now I see value there. This is a level of abstraction and programming where we spend fewer, fewer time typing about plumbing and more time talking about the business value that our software adds, right? What is a Link expression except a very summarized form of an important business activity in some form? And more and more that close plumbing pieces get pushed down. They're part of our base class libraries. They're part of the framework and this tooling simply means that the code that I see every day and the code that I actually type is the business value that I'm adding. So the fact that things like that are runtime or .NET features that are implemented in various languages and sometimes in both and sometimes in one or the other. And we've gone back and forth on that, right? There wasn't going to be language parity then there was going to be language parity. Now we've decided that we don't literally need 100% language parity but it's all basically runtime features which means that any of the languages are then capable of taking that on and having it part of the language. Yeah, for better or worse, it compiles all to IL. Right. And I think the real clever trick is if you look at IL, it is inherently object oriented. And here we are in F sharp writing functional expressions. And if you look at the IL that generates and I'm not encouraging that because it's hard on your brain, it's tough to do a great functional translation. They're doing it and it's quite efficient. And it's interesting that the effects of functional programming have influence C sharp programmers too that you can write quite functional C sharp as well. It sort of speaks to the flexibility of CLR. It's interesting to consider the idea that there is a fundamental bias in everything we do in .NET because of the way the runtime ultimately consumes the code. Right. So we have had, there's obviously the languages that we create here at Microsoft. We've had third party .NET languages, COBOL.NET, right, from the very beginning. There were 22 languages. Yes, there were. And of those 22, how many do you think succeeded? Succeeded meaning, reasonable amount of usage and enough justification to keep working on it. A few, like if you go to the marketplace, Fujitsu's still supporting COBOL. It's $700. You can buy it if you want. IBM's still supporting Fortran. There's a Fortran .NET. I think it's actually a 2017 right now. There was Scala, did that one? Scala didn't survive. So one of the things, again, I've discovered in the story and hopefully this will be in the book, is that part of making that list of 22 was reaching out to different aspects of software development to bring in those languages. So some of those languages came from significant language development shops. Like IBM and Fujitsu and so forth. And some of them came from academia. And so really the goal then was a group of graduate students doing an implementation against an environment they hadn't really experienced before. But once it was done, that was kind of it. So it was in the box in 2002, but I think especially in the case of the academics, many of them didn't proceed after that. So that doesn't say plus or minus on them. There was a Haskell implementation in 2002, which is interesting. Because we're sort of circling back on that. Now we recently did a show talking about programming in traditional Haskell against with VS Code rather than Visual Studio and using that as a form of services that I can run on the back end against the .NET application. And you could presumably take any language today and create a .NET version of it. Could you create a go.NET if you were so inclined? Absolutely. One of the first times I ran across Don Syme when he belonged before F-Sharp. And he's been involved with Microsoft Research. In Microsoft Research, he's been involved with generics, although again, I found that out later. First time I ran across him in my capacity building .NET Rocks episodes was a paper he did sort of exclaiming to language researchers saying, look, every time you want to experiment with a language, you need an editor and a debugger and a runtime and so forth, like just dude in .NET, you get all these things for free. And then that, those initial thoughts and the experiments you're doing eventually evolved to what would be called F-Sharp. The extraordinary thing with F-Sharp is that it jumped out of MSR and into the actual mainstream engineering languages team to become a product. But you're totally right. This is a great land to experiment with language. And then how many different versions of the runtime have there been? There's been mono. Yes. There's obviously the .NET that we make. Were there others? Well, even when you talk about the .NET that we make, there were fragmentations of runtime within Microsoft. The Windows team ran a version of the framework versus the Web team running version of the framework. You could talk about the micro framework for the period that had impact. If you think back to Silverlight, there was a version of the CLI that ran on the Mac. Yeah. And there was a version of Silverlight that ran Win Phone 7. The fragmentation of the runtime, the base class libraries, the framework, and XAML got extreme. There was a point where we ended up doing shows about how hard you can learn XAML, but which XAML you learned. Exactly. You know, it got very fragmented and that came from people wanting to experiment. Like this is the downside to those experimentation is if they succeed in any way, you start having language differentiation and implementation differences. Certainly that was a challenge with mono. You know, mono after two was very selective of what got added. So it was never a parody with the traditional .NET framework. Right. Until the standards came along. Originally when those guys were at Novell, right? Yeah. Well, further back to that, and eventually that it would Novell. Okay. The first time I run across Miguel Diacasa in the gathering of the history is a talk he does at O'Reilly. In 2001, after .NET is announced and the ECMO specifications are published but before the product ships. And he says, I'm taking these ECMO specifications, I'm trying to do an implementation in Linux and people think he's crazy. But the experiment continues and does bear fruit ultimately. It's fascinating to realize that the hip new blazer actually depends on mono. Really? Because mono is written in C++. Okay. And ultimately the LVVM compiling stream into WebAssembly needs C++. Interesting. And Roslin's written in C sharp. Okay. So it's not that they couldn't use the Roslin engine, like they just had to be some interesting tricks back there. But Steve Sanderson's original implementation in 2017 that I saw at NBC in June, just over a year ago now, which is amazing that so much has happened. He was using a different open source implementation of C sharp in C++ that he found on GitHub. But as that started to iterate, Miguel got involved and they switched to mono because it was more completely was actually part of that standard. So it was a richer version. It's still experimental, but it's interesting when you realize there is value to these different incarnations. Right. As long as you can stick with standard. I think standard was a brilliant insight that we were better off writing a set of specifications we could all agree to and build independently to versus basically creating a gatekeeper through which everyone had to pass. It's just not scalable. Right. So mono beget Xamarin as well as Unity. Yes. And it's also a fascinating piece of the story is right at the time when Microsoft, you think about, when I think about the most difficult days of Microsoft, the 2010, 2011, 2012 period when the iPad ships. And then jobs, yeah. I remember. Yes. The first time I saw one of those, Mike I am our good friend, Mike I am comes to my house and he's got an iPad. Yes. And he's sitting at the dining room table and maybe 15 feet away is my tablet PC. One of the motion computing ones perhaps. Right. And I'm thinking to myself, dang. Yeah. Very differently. We could have had this first. I don't know that it was to be true because I mean, Apple's advantage was no legacy. Right. And they were aiming at a different space. And we, the tablet PC based on Windows meant that it had to be a business machine that ran Excel. Well, just the basic overhead of the runtime that is Windows, you know, it's not a small thing. I don't mean, you know, this isn't a criticism of leadership or anything. We were aiming at a different market but technology wise, right? The ability to have this small portable thing. It was extraordinary. I think it saved the laptop because at that time, the lap, we were trying to make a $500 laptop and they were terrible. They were so cheap, they were doing everything to pare down the price. And then along comes this $800 tablet that is gorgeous. And you can, now you can't even build a $800 laptop because it's not as nice as the iPad. So suddenly the base price of the laptop bounced about $1,200. And for $1,200 you build a pretty nice machine. And so some ways that I think it helped that but the hugest impact of the iPad, I think it's two-fold. One is Microsoft now gears up to try and build a version of Windows that's gonna compete in that space and that is not a trivial issue. And then Jobs puts out his thoughts on Flash Letter and basically says iOS is not gonna run plugins anymore through Safari. There was a workaround. There was another browser that you could install on the iPad that would run Flash. And it would murder the battery of the Flash of the iPad because that's what Flash does. But I think the real reason that he wanted to get rid of that is it was gonna make the iPad look terrible. He wasn't wrong about the plugin problems. He wasn't wrong about data vector for malware and so forth. And the white listing strategy was a good strategy that we're gonna validate software before it's installed in your machine. As opposed to black listing strategy, put on whatever you want and I have monitoring software that's gonna fix it. But that's April of 2010 that that letter comes out. And at that point, Silverlight's got a problem. Now, for us out in the world, working in Silverlight, especially version three, like we were having a good time. We didn't know that, uh-oh, like, but internally the work was going on, that this is a crisis. And it sort of, that surfaces by the end of 2010. That's when all of that sort of comes out and the situation sort of appears and you have this battle of what languages make you, what is the true lingua franca in the heterogeneous world of operating systems. Recognizing iOS and Android and Windows and Linux are all legitimate operating systems just for different form factors of what are very personal computers. You know, you can't tell me, a smartphone's not a personal computer. It is a computer. It is not a computer, it's incredibly personal. This is a computer that I refer to as my phone to distinguish it from my surface. And I in fact spend more time on this doing computing things. And when I get a phone call, I view it as an interruption. Totally, and it's like the last thing you want on that. Which cracks me up because it's a phone to cry out loud. But it is the most personal computers. It's the only personal computer that your concern might give you cancer. That's pretty personal. So in that diversity of operating systems to step back as an architect and say, how do I program efficiently across all of them? That was, I think, a very significant crisis outside of Microsoft. The focus on JavaScript made a lot of sense and this is where things like when JS start to appear. But at that very same moment in 2011 is when not only has mono touch done well and that is the mono for iOS, but they ship mono for Android. And so at the same moment that Microsoft's saying, maybe C Sharp can't be everywhere, Miguel Diacasa says, would you like iOS and Android? How about that? And then Novell implodes. And so along comes Attachmate buys up the remains of Novell and says, this mono thing's not important. You could stop all of that. And Miguel, again, too, is credit, grabs that Friedman and they form Xamarin and in some serious negotiation, get those bits away from Attachmate and make this new company that says, you love C Sharp, go ahead. And it's brilliant. It's brilliant. It's very challenging. Of course it is challenging, but if you know C Sharp and you either know or can figure out XAML, which of course you can, then you know everything you need to know to get started building mobile apps that run on iOS and Android. Well, I believe that more today, but in 2011, 2012, you know what it felt like to me? It felt more like. Right, that was before they had Xamarin Forms. Yeah, before Xamarin Forms came along. If you knew. You had to learn the platform. You could take your business logic and write it on a different platform, but you had to learn the UI and then you had to learn underline. You had to learn under the platform. To a much larger extent. Well, and I hate to compare it to web forms, but the same kinds of traps. You know, web forms is original intent going back to 2002 was to take a group of WinForm developers and give them a similar experience on the web by abstracting the web's behavior from them. And that had consequences. I mean, it made a very smooth path for those developers to remain productive. But as we started to explore into the web world, pretty quickly web forms hit some rough patches. And so, you know, I made a lot of money cleaning up web forms apps. And generally speaking, I could open the conversation with congratulations, you have a good problem. Enough people are using your app that you care about the resources it consumes and the speed that it runs at. If nobody was using it, it would work great. But there's so many people using it now, we've got to think about it a different way. And I think you were running into exactly the same challenges here where we have to remind ourselves as programmers that our programming environment is not just language and it's not just tools. It is the runtons. And it is the library sets. All of those things matter. You know, for better or worse, .NET took a lot of conversation we used to have in the 90s off the table. You no longer were selecting a library. It's pre-selected for you. It's the framework. We're no longer even selecting base class libraries. They're pre-selected for you. And as soon as you jumped out of that pool, a lot of those questions got back on the table again. And we, in some ways, we'd forgotten or we may have never known. If you grew up writing software in .NET, there was a bunch of questions you just weren't used to answering because it was obvious there was only one answer. And so when the world diversified on us, when these platforms expanded, we had to learn some new things. Yeah, and you got to the point where you didn't have to, you didn't really spend that much time thinking about what was part of the base class library and what was part of the C-Sharp and VB language. It didn't matter because you're just typing words. And whether that word lives in VB or .NET, that's interesting. It kind of tells you where to go, look it up in the docs. But at the end of the day, who cares? It's just a word-eyed type. And so we get back to your statement about, you take your business launch, you're going to be able to port it to another place. It's like, as long as it's only code, if in the midst of that you have a call that happens to append on a framework piece that actually calls to a Win32 call, you're going to have a problem with that call. And you, again, didn't need to think about it when you were living in the homogeneous world of it's windows all the way down. And in the heterogeneous world of this set of platforms, those conversations are- And you learned that, you certainly learned that when you, if you started doing Silverlight, you certainly learned that if you started doing anything on phone that there's a sandbox. You learned the concept of the sandbox. And a restricted feature set. XAML was much more simplified. Which is basically the universe of things that you can do. And a lot of them made sense. And a lot of them, you may have wondered why, but it's just a fact, Jack. It was sort of, we're dealing with some reality for you. Maybe we're still trying to protect you from some pieces as much as you can. But there are limits to what any of that stuff can do. Right. And in some cases, it was easier to jump all the way out and go, I'm just going to go native and learn all of those things again, you know? I don't know. I don't know, man. Have you ever, you've seen Objective C. Oh, yeah. It's not easier. But remember that Objective C was never meant for public consumption, right? Job said, if you're going to program on the iPhone, you're going to program a Safari. And what he was anticipating was HTML5 in 2007. He was years ahead of where the actual standard implementations were. And the only reason we ended up with Objective C is the phone got jailbroken. That the hackers wouldn't wait. We're going to program the way we want to program. And to sort of not lose control of his platform, they released their internal tools, which is why they were so terrible. They were meant to only be internal tools. And then the App Store became a necessity, you know, with maybe a billion-dollar business now. But back then, this was just them trying to keep control of the product and emerged a field, you know, that everybody now had to have an App Store. You know, Swift is far better, far, far better. It's still not my favorite language. But I can respect a cleanly written fresh language that is terse and clear, right? I got no complaints about that. But that's... But I love the fact that I don't have to learn that because I already know C-Sharp. Sure. And... As long as you're willing to learn the ins and outs of the way iOS should behave and... Of course. Of course. ...wherever you're going to hit those edges, then you can be successful. Right. And even if I decided to write native Mac UI and native Android UI, I still love the fact that I don't have to learn a new language. Right. Well, I also like being in a project. It's a project that, you know, when you talk about broader strengths of strategy, the idea of my project that goes to iOS and Android is literally the same project. When I write that feature, and it's 80% common code and 20% platform-specific code, but when we hit, when it hits the CI pipeline, it's going to both devices. Yep. So I've also seen plenty of organizations where the iOS team... There are all three devices. Yeah, three or four, how many devices make you happy? When the iOS... Well, if you're doing Xamarin development, even if you're not going to release the app on Windows, Right. You should have the Windows 10 project because it's the easiest way to test it. Sure. Well, it's certainly a quicker iteration around. You don't need a device. You don't need an emulator. You're already on Windows for no other reason than to make it easier to test you should do the Windows 10 project. No, I'm not going to argue with you. It's completely reasonable. But I've also seen plenty of organizations when they're working in native and they've got a strong iOS team and their iOS team is out running their Android team and new features appearing on the iOS device first and it's making customers angry. Right. And so I think part of creating a common pipeline for all mobile features that's going to build to all of those devices is that you maintain feature parity across the devices. Right. And I think that in the broader scape of not just I want to program my thing, but in the how am I taking care of providing value to my customers, that strategy is actually stronger. Right. And then you don't have to write the exact same code, the exact same features multiple times. Exactly. Right? Yeah. The SkyDrive, back when it was SkyDrive. Pulling out these old names. Next, we're going to talk about Metro. Oh, God, purposefully wrote the iOS and the Android, the Windows versions, all 100% natively for the best experience. Yeah. Although now I think there's Amaranabs, now that it's OneDrive. I think OneDrive is the Amaranabs. Yeah, I don't know the answer to that, but I appreciate that. But again, it's like how you, if in the broader scheme of actually taking care of my customer, maintaining feature parity is incredibly important. Mm-hmm. And so whatever tooling can do to help me that, to the other thing that I found I really appreciate about Xamarin as we spent time with it, absorbing the Android variations. Mm-hmm. Now it's not as bad as it used to be, but back in like the Froyo era, where you, and even when we were first playing with Xamarin, Froyo was still hanging around and it was like IE6. It was this old version that missed a ton of features, but a whole lot of cheap phones ran it. And so it just wouldn't go away. And the fact that Xamarin would absorb a lot of that, you wrote far less Android version-specific code, I thought it became a hugely high value proposition. So what role does, what does .NET Core fit into this? So there's an interesting period as the cloud emerges and as Scott Guthrie moves over to the cloud and the web team went with him. So while Win8 was gestating, and it was a big part of the .NET team that was involved in all of that and they were trying to make Win8 what it could be, there was this sort of isolated group off on the side and they were focused on Azure. They really weren't focused on operating systems. And a lot of the early experimentation into other ways of doing momentations should come from that. The open source movement internally to Microsoft been going on for some time. My best evidence of the sort of the first stages of open source coming into Microsoft back in 2007. NVC was really meant to be open source all along and it ended up a codeplex. Yeah. So we had these early activities already going on. But it's not, and then the same thing, you have the web team working on stuff to really support Azure and the evolution of Azure. The first incarnations of Azure, 2020, 2009, 2010, the funny part now of looking back on it because it was a struggle to use was they were proposing serverless. Web roles and app roles, right? Very off the bat. Now admittedly you paid for it as VMs, but the architecture was very serverless. We just weren't ready for it and it had its issues. But as Guthrie gets involved and Azure starts to transform, we start to have more of the websites, models and those sorts of things. It's this team that works a lot of that and that's where those early bits start to come from. It's not until sort of a post-Win8 world and Win10s being worked on, so now you're 2013, 2014, and Sachin Adella moves from the Azure team to the CEO role and Scott takes his position that you start getting all of those pieces together and saying, can we really do this? This makes sense. And so that that spawns up the .NET foundation and VS Code, those bits actually come first that we're starting to have more routine work by Microsoft folks in the open source community on a regular basis. The core doesn't actually appear until 2016, although it was clearly being worked on as far back as 2014 as Project K. So as a runtime, what role does it play in the world of development you see? Well, it's still early days for the traditional, for a .NET developer that's been working on .NET since the initial incarnation, so one, 1.12, especially if you were doing desktop work, the .NET course is still not on your radar in some respects. If you're a web dev, or more importantly, a modern services developer, so you've embraced web API and you've sort of liked building in that space and you've always had pressure from your organization that we'd rather not be running Windows on all of these things, then that opened the door for you. It's like, well, what do we need? What moves across? And .NET Core 2, which was the third version of .NET Core, just like the standard framework, because version numbers are hard, was really had enough of the feature set that you started really saying, okay, I can take work I've done and move it there, it makes sense to build forward, it's not gonna hurt. So it runs on Linux, it also runs on Mac, but importantly, it runs on Linux servers. So if you are now told we're getting rid of our Windows servers or we're gonna run Linux servers, you get to not be completely out of luck. Well, it's really, for running in VMs and we're paying licenses and our compute costs are relevant, the number of transactions per dollar, you can make some real improvements there when you look at Nginx and running in Linux VMs. It depends on your architecture. Of course, all of this is being disrupted by containers again too. So if you're at the edge of all of this, you're already pushing on what's next. But if you go back, back to 2016. Well, containers, I mean, it's still true that a Windows container using .NET is about, relatively speaking, is about this big and the .NET core container can be about this big. Much smaller. And also .NET cores is dramatically faster, ASP core dramatically faster, right? Depends on what it's running on. I mean, they've done some great optimizations there, but you're also working on a narrower feature set. I got nothing to complain about. I built a lot of .NET standard websites that ran pretty well. It is easier to make lightweight fast websites in a Linux stack with core, because it's just a smaller surface area for you to tune against. The battle of the Windows container is nowhere near done. Like Windows containers are only just starting to get good. The announcements out of Ignite this year, now we can sort of circle back. For most part, when I find folks that are using containers for anything, they're using Linux containers. And they might be using .NET core there, but I think that's where the win is. I'm looking forward to late this year and sometime next year, seeing what .NET 3 looks like and based on the announcements at build, where we're going to start getting new versions of desktop-related SDKs that are meant to work against core. They're not part of core, because core is cross-platform, and there doesn't seem to be any conversation right now about a win forms for Linux, because that'd be weird. Isn't that Xamarin forms? Yeah. But interestingly, you started trying to rationalize XAML into a standard to sort of talk about what does that really look like, and you got to look across that in the first year. The first thing you'd need to do is rationalize XAML into a standard, right? Yeah, XAML was so many. My favorite line when Silverlight was new, when it was WPFE, we had Rocky Lottkern. And we're talking about how WPFE seemed to be taking off where WPF never had. And he said, the reason is that web developers are used to lousy tools. That we never had a designer for XAML like we had a designer for win forms. And so this iteration of I write a little code in XAML, and then I flip to an emulator view of it back and forth, web devs get that. Sure. Desktop folks are like, this is archaic. What are we doing? Like, what a waste of time. But now all these years later, when you're totally used to writing XAML by hand, right? Which we're in a different place now. The question is, if a designer was invented, would you use it? That was pretty good. Would I use it? I'm betting no. I don't know. Yeah, I'm betting no. And I tell you why, because you're proud of the organization of your XAML. And no tool ever do a good enough job. Ever, ever, ever, ever, ever. See, front page dream weaver. I don't know. Like now, the machine-generated HTML, same problem. I think the- It depends on how well it works. Well, yeah, that's it. But it'll be a younger generation of devs. Says the man who thinks right click publishes a great invention. But it'll be a younger generation of devs. So Einstein writes the general relativity theory. And all of his contemporaries, all the senior guys, they don't like it. It's pretty weird. They're arguing over details on it and so forth. But the younger physicists are all over it. This is great. This helps all these problems. So we can explore astrophysics in another level and so forth. And a reporter goes to Einstein and says, you know, you've got acceptance from this group. You don't have access to that group. You know, what's it gonna take? And Einstein says, first the old physicists have to die. Right. And so we could go to design model of XAML. That's really great. But first the old developers will have to die. Yeah. Like the folks who got good at that other technique are going to resist it, right? Change is hard and they're productive as they are and they will find reasons not to use it. And then my experience with Microsoft over too many years now is you'll let them, right? That they will continue to be able to work the way they want to work. And the other guys will work the other way. And if those other guys can out compete them, bully for them. It's also, I think, much harder to do a good XAML designer. Hugely hard. Than everyone else to do a good windforms designer. Well. Windforms was absolute positioning. Yeah. I want this button here. Period. End of story, right? I don't think it's only that. So how hard is that? It was also. That was one of the things. It's certainly one of the things. But the other aspect of windforms is that we had strict design guidelines. File goes here. Help goes there. Toolbar goes here. And we've just never had that for XAML because XAML, arguably XAML punted. It's like, what would you like to do? How about a carousel? Like you have all of these choices. And so if you were really going to go down the designer path for XAML in a serious way, you would have to start thinking in guidelines that you're going to force people to fall into the pit of success. Maybe there's three or four or a dozen different templates, but you're going to follow certain metaphors. But we did come out with the metro guidance, right? There's UI guidance that came out starting in Windows 8. And there's fluid design. And people now have guidance. We have more guidance. I wouldn't say we have guidance. I'm going to qualify that. There are guidances. But there's the ultimate manifestation of guidance as tooling. So if we really have guidance nailed, we will have a set of tools that basically get you to follow that guide, perhaps even against your will. I don't think we're there yet. I think we're better. But there's a possibility there. Is it late? Might be a little late. Might be a little late. That's always a good question. There's almost a history of XAML that I can do. One of the problems I've got with this book now, and I'm 70, 80 hours of interviews and research in it, and I feel like I'm less than halfway. And I still, you know, there's a lot of stuff up here. It's not going to be one book. I'm going to write the book that everybody wants, right? That sort of overarching history, sort of the politics of motion and so forth, like definitely going to do that. But when I talk to people about the history of .NET, they see it through their lens. Of course. If they're a web dev, they talk about the web dev stuff. That's like writing the book on World War II. Yeah. You can't do it. And I'm not going to. I'm going to start with one. And if it's desired, like a history of XAML is not a bad idea. A history of Microsoft web dev, not a bad idea. It's a companion to the overarching story. But, you know, I've been gathering up screen shots of all the old sample apps from the earlier versions of .NET. And I could almost do a coffee table book on that. The pictorial history of Fitch and Mather and Adventure Works and North Wind. I will do, if you could do a coffee table book, I'd love to do it. We'll do it here if you want. Come on this show and we can run. Run them all? Yeah, run them all. I love it. Think about that. It'd be hilarious. Yes. There's still, there's folks out there that made videos that were like running every version of Windows. What if we could do it every version of the .NET sample apps? And then what we will have is, you know, folks can play along. You get a point if you remember that app. Right. And then, you know, if you remember all of them, well, you're just a fan person and you're old. And if you haven't seen any of them, you know, then we'll come up with pithy ways of describing. I am not opposed. I mean, I'm enjoying gathering this stuff. I'm finding insights in them. There's multiple ways to tell a story. So I am not confined to any particular media, timeline, or architecture. I will try them out of the sport. Well, I know we're supposed to keep episodes to 30 minutes, but we're at 50 now. So I think this is a good place to stop in a moment. Hopefully you guys enjoyed that, kind of a whirlwind overview of a history. It's kind of just two old guys sitting around chatting. One we've been in and still enjoying. Yeah. And at the moment, show no signs of quitting. No. Thanks so much. Good to spend time with you, friend. Hope you enjoyed that. And we'll see you next time on Visual Studio Toolbox.