ASOS - Discover Fashion Online (Customer Video Connect(); 2018)

Isis wants to be the number one fashion destination for 20-somethings around the world but we don't have shops people know about a sauce from the internet we have one minute where that digital platform is out we're not serving our customers because a sauce offers such a wide variety of products eighty-seven thousand at any one time with five thousand new ones added each week we've invested heavily in their recommendations platform we need to help our 18 million active customers discover the things they love we really like cosmos DB as a fully managed database service cosmos DB is used as model store the gateway from the offline to the online data science world's allows us to distribute the data models to be near the services wherever in the world they're deployed we like the immediate elasticity so we can store data models of any size we like the very low latency for random reads during peak sales periods we need extra compute power to cope with customer demands and manage our large data sets on Black Friday 2017 a sauce services backed by sequel Azure and a zero cosmos DB processed 750,000 orders the product API served more than a billion requests at a Black Friday through Cyber Monday bursting up to five and a half thousand requests a second with an average response time thirty nine milliseconds we had literally no problem throughout the entire weekend Azure has delivered as a rock-solid platform to create a and ever more compelling consumer experience [Music]

Application Insights The Tool You Never Knew You Needed

so we're gonna be talk about application insights today my name is Isaac Levin I'm an application development manager at Microsoft and what I do for my job is I work with customers so I work with customers to better the developer experience so one of the things that I like to talk about with my customers is how we can do better as it pertains to getting data from our applications to help us fix issues iterate faster and bring value to our customers so I have a website it's listed and I also have a Twitter and github if you'd like to follow me there I would greatly appreciate it so I'm gonna say this word a lot over the course of this talk so the word telemetry so what is the definition of the word telemetry so the Wikipedia / Webster you know definition is telemetry is a collection of measurements or other data at remote or inaccessible points and their automatic transmission to receiving equipment from monitoring that is a very long definition but how Isum s it for applications is all the data that our application creates that's not immediately related to things that the user sees on the screen so we know what we say that what kind of questions do we consider when we can think about telemetry and how we can do better by our customers I'm not gonna drain these obviously but you know one of the things that I like to see from a customer's perspective is how we can report on how our application functions and some of this data to provide insights that are going to better the business so you know we're here to talk about app insight so maybe we should talk about what is app insights so app insights in its purest form it's a REST API so it's a REST API that's hosted in Azure that allows you to collect telemetry related to your applications so it's a REST API and the data is stored behind the scenes in a no sequel data store so you send your JSON data from your application to the REST API it goes through a process to aggregate the data and make it available in that data store and obviously from a dotnet perspective since read Netcom you know is an existing SDK owned by Microsoft for application sites both for the web I believe that there's one for the desktop it's create was created by Orrin Novotny and for every other application that uses app that wants to use application sites there's either an SDK forward or you could create one yourself so when we talk about telemetry what kind of telemetry we were referring to so out-of-the-box application sites collects all of the telemetry that you see here so request response information third-party calls such as sequel or HTTP page views for browser-based applications and everything that you see here one thing to call out is wealth is really exciting about the release of dotnet core is that application insights now collects event counter data so for instance like garbage collection and more intricate performance data around dotnet core applications so that's available as of dotnet core 3 oh and one of the great things about application side since it's a no sequel solution you can basically use or pass any data that you like in tap insights and be able to report on it so you know think about you know domain data that you could use to be able to report on in some capacity I like to show this slide when I talk about application insights because it's really valuable think about what application is it at a holistic level way up top right so on the left hand side you have your web pages and your services and then all of your dependencies right web pages of client apps that would be like your static site or a front-end only app like a spa and web service obviously is any you know back-end type of service that's use and then dependencies or all the things I mentioned here mostly sequel and HTTP so all that data that gets sent into app insights and it gets massaged in a way that allows you to report on in a bunch of different capacities so you can build power bi reports or you can look at the data in Visual Studio and you also there's an arrest API that's available for application size they can you can get the raw data out and do with it whatever you like so the first thing you're probably thinking is okay this sounds interesting you know I imagine it costs a lot well what if I told you that the cost for applications that are actually in it scale are pretty pretty inexpensive right so you get five gigabytes per customer per month so what that means is that putting data into app insights and taking data out of app insight so you get five gigabytes of flattened jacent per month and if you need additional storage it's two dollars and thirty cents per gigabyte per month one thing to call out about the data retention as well is that application insights just recently changed the data retention so let's now configure a role in the portal so you have the ability to change how long you want that data to be stored for so we're moving on how do we actually get application insights turned on in our applications so for a.net developer you most more than likely the easiest way for us to do it is inside a visual studio you have other ways to do it especially if you're in the IT pro world you can install an extension on Azure app service or add your VM especially and if you have an application that's hosted on Prem you can still take you can still leverage application insights by using a status monitoring tool which instruments you know a nice application i as web server so when you configure it through Visual Studio all you have to do is right-click on your CS proj go to add add application insights telemetry it'll come up with a UI or wizard that looks like this right so it asks you to specify what your as your subscription is and what you want the resource to be but one thing to call out at the bottom is that you can just add the SDK to try local only so what that allows you to do is play around with that application insights and see if you actually are going to get the value out of it that you know is warranted by sliding it up in Azure so what that I'll do is it'll just add the SDK and the wiring for it and then in the situation where you do want to deploy to the cloud you would just kind of follow this you want this wizard again and create the resource inside of the azure portal so once you click register it goes through a couple of things that in the.net core world it's going to add some new get packages obviously and it's going to add a line to your startup so yes and we'll see what that looks like in a second but when you're all done it's going to give you a No percent and three green bars meaning that you're ready to go so I think this is a good time to actually show how easy it is to turn on application insights so what I'm going to do is I'm gonna go into my Windows terminal and what I'm going to do is I'm just going to create a new dotnet project so if I go dotnet new web app which is going to create a razor pages application I'm gonna call it no insights and then I'm going to specify the output folder as no insights so what that's going to do is that's going to scaffold out a razor page application and dotnet core 3 oh and I I should probably type a bit not as fast so Dada new web app note no insights so again this is gonna scaffold out razor page for us and what I'm gonna do is I'm going to hop in here and I'm going to open it up in visual studio and then I'm going to instrument app insights on this application so if I go inside here and you know one of the cool things I like using it the visual studio terminal I'm not a visual studio command line or PowerShell is I can actually just point it dev NV which is the executable that runs Visual Studio at my CS proj so I don't have to then hop out of my command line and go into Windows Explorer to find that particular file so what this is going to do is it's gonna load up Visual Studio for me and visually is not responding but it's it's back now so as you can see here this is just a really really basic application if I go into my dependencies there's nothing really fancy in here so there's some analyzers and some frameworks and we'll wait for this to be restored and available in Visual Studio and if you look inside of my startup all I do is all in my configure services I just had razor pages and then some static files right so once I actually want to light up application insights I just right click on it right click on the CS proj well maybe right-clicks not gonna work right now but if you right-click on the CS progeny you go down to ad and then you can actually specify ad application insights and then go through the process of setting up that wizard so it seems like Visual Studio is hanging so one of the things that I can do is I have a similar version of this talk actually available on YouTube that you can take a look at as well for whatever reason Visual Studio is just having a hard time and I don't want to have everybody look at Visual Studio lagging or whatever so we're gonna just move on to kind of how we can consume our application data using application science so what do I do with this data so you know one of the things that we have the ability to do in a pin sites is take a look at some of the rich reporting that exists inside of the azure portal so it this dashboard that you see here this is a one button click from your app insights resource so once you click that button it'll generate a dashboard for you that's going to give you a lot of really valuable information so you also have the ability to see application map which is a holistic at a high level all the dependencies and services instances that you have for your application running you also have the ability to look at profile information so in the situation where you have a low performant call you can take a look and see line by line execution by execution what's taking all the time to run and you know that gives you a ton of insight into ok where can I clean up this application code flow to be a bit more performant one thing that's great as well about looking at a pin size data in the azure portal is you have the ability to create these visualizations using metric Explorer so these are you can build them either using kql instead of log analytics which is the querying language for application insights data or you can just do it in a WYSIWYG sort of fashion also since application insights it does do some things behind the scenes once you send the data into it the data that you see it does take you know it can take a couple of minutes to get in there but if you need to see what's going on your application in real time you have live metric stream which is over the wider viewing of the telemetry that's being passed into your app insights resource and obviously in the world of reporting you know we have the ability to export our application insights telemetry into power bi and do all sorts of things with it this is just a default user report that's built out for you when you connect application insights to it so you have the ability to see some demographic information like where the users are coming from as well as what operating systems that are using I was going to show pulling this up individuals pulling up applications I did in Visual Studio one of the things that you can do is while you're debugging locally you can actually see all of the data that's being passed into the app insights resource at runtime while you're collecting all this and be able to see some of the details and operations that are flying around and then finally you know I mentioned one of the things that there is a file a data retention the application size doesn't hold on to your data forever so if you do value having long term storage of your application telemetry you have the ability to use what's called continuous export which frankly what it does is it exports the data into an azure blob storage container and from there you're able to do whatever you like with it for as long as you like so I think now we've took we took a look at how you light up an application that's kind of like a dotnet new what I want to show is a more baked solution so I have an application here which is a angular 8 application that uses the dotnet core 3 Web API back-end so as you can see here this is just a tour of Heroes and some of the heroes here some of the folks that were familiar with in the.net comp so if I take a look here I can fly around them but one thing that I see is that whenever I do a search I get an exception and I don't know why however if I wanted to just look at this at application insights I can fly over to live metrics stream right here and what this will do is this will actually pull up the over the wire viewing of what's going on with my application and I can actually jump around here and you'll see some of the things on the left-hand side start to light up so you'll see that there's dependencies information going on there's incoming requests and there's I can see the CPU utilization for my app service and the community member but one thing is well that's really valuable is I can actually see sample Channel Emma tree over the wire so if I do a search here for Scott for a Miss type name and it'll show oh there's a request that returned to 500 and I can see that exception here if I drill into this exception it says that it's an argument out of range and if I scroll it gives me line numbers right so that's really really valuable so in taking a look at some of the ways that we can help triage issues in production you know that's really really valuable and what's the data is actually in app insights I can click investigate in application map and it'll show at a holistic level all the things that are going on right so I have one central instance it's hitting a sequel database I really have some availability tests that are checking the application if I drill on the sequel side here I can take a look and do an investigation of some of the performance for some of these calls so the average duration for my sequel calls is actually very good at seventy-seven point one but if it was milliseconds but if that was too slow I can have the ability to drill in and then look at sample data for these particular sequel calls so if I click on one of these end-to-end transactions I can actually see the sequel query that gets executed on my database behind the scenes so obviously this is just a select but if you had a more complex database database call it would be all in there and that's one of the really valuable things that you can do with app insights is you can see kind of the end to end transaction so let's take a look at a particular example here so if I go into this back into that app insight resource and if I look at my failures I can see all the failures that have happened over a particular x time slice so as you can see here I have two types of exceptions a file not found in argument out of range I saw earlier when I looked at a live stream that I was getting some argument out of range exceptions when I do a search and what I can do is I can click on the operations and then view one of these particular end-to-end transaction details and I'll tell me what's going on so if I minimize all of this it'll see that it made a call and then there's an exception before you know it will hit the database and click on that it gives me a bunch of information about the exception which i think is really valuable but if I scroll away to the bottom I got a call stack and you know since I'm doing a lot of this all these I'm using async to do a lot of this some of the sometimes the call stack can be confusing to read so if I click just my code it'll actually show the code right so line 53 and my hero service in line 31 in my heroes controller so it gives me the ability to get a ton of value for when I'm triaging application issues in production and finally one of the great things about application insights that you can take view of is you can look at all this data great in tools but sometimes people just want to see the data so if I click on view and logs I can take any of these things top exception types for instance and view them in log analytics directly so like I said earlier log analytics is the storing mechanism for all application size data as well as all as your monitor data which application insights is a part of so as you can see here it's gonna load up a query and then it's gonna show me that particular data let me just maximize this and scroll all the way over all right so as you can see here I have 139 argument out of range in 24 files that's really really valuable but let's say for instance the business comes to me for with a particular request and they say hey Isaac I really want to get a slice over the last day where our users are from and I could easily say okay well I know that all requests are stored and maybe I want to summarize that account of all the unique clients or countries by that client or country so right and then they say and I can run this and then it gives me a table in the last 24 hours so 23,000 folks from the United States but also looks like we have people from Brazil and the Netherlands and Singapore viewing our application and they say well this is a data table I really don't like that way rather prefer is that rather prefer a chart and then you provided in this chart and they say well this is a bar chart and I drill are stacked column I'd really don't that you know in the past when we've been building reports for customers this process of just building reports takes a long time but they say I want to donut and then one-click and you have a donut for them so just think of how quickly you were able to provide that request to your user and they say well I don't really want to go to this particular page to see this report and you say okay that's fine I can just export it to power bi or if you want to look at the data yourself I can export to CSV for you so again we're talking about adding tools to our tool belt that are gonna make things more successful one thing is well like like I mentioned earlier with especially with dotnet cores you can collect extra performance data so I want to show you what that looks like so if I look at just the performance counters table or collection I'm sorry it's gonna show me all sorts of information right so I have exceptions thrown per second I have private bytes and system run time but then as you see here I have information about garbage collection so in the situation where your application isn't handling memory very well you can take a look and see what are the GC count values in particular situations what the thread pool count is and this gives you the ability to get even deeper into why our application isn't performing the way you want so that's how some of them what quick ways that we can take a look at telemetry in our application to be more successful so moving on to the final part of this talk one of the things that I think the application has a ton of value in is per you know thick our triaging production issues so I showed some of the cool things that you can do there but there's additional tools that exist inside of app insights and visuals to do enterprise that gives you even more tools to be successful so how many times have we been in a situation where somebody comes to our desert says there's an issue in production I don't care what you're doing fix it now right so what are the first things that we think of that can cause production issues right so I think of the primary things is there's change to the environment there's some data that's causing issues with code and you have scaling issues but really anything else can cause issues in production and when we look to actually try to fix these things what are some of the things that we actually do we can copy some form of production data to a local environment to test you know in some situations that's just not scalable especially for large applications you know in some in other scenarios we have the ability to look at a production staging environment which maybe has more telemetry turned on or we can actually you know spin up an environment to actually look at things a bit better we can read logs if we really don't like our lives we can read IAS logs and DB logs and what-have-you and then you know at the end of the day sometimes it's just really really valuable to see what's going on live so a lot of people will do something like this right they'll attach a debugger to production and there's a ton of reasons as to why you don't want to do that the biggest one is that if anybody wants to use your site they can't anymore so I'm gonna say that's not a good idea right we don't want to be in a position where we're affecting the experience of our users to fix an issue right we want to be able to create an environment where we can outside of the scope of that production application get more information and one of the ways that you can do that is using snapshot debugger so snapshot debugger like I said it's a tool inside of Visual Studio Enterprise that allows you to connect to a point in time exception for your application that's lit up with a pin sites so that doesn't mean that it's only an add your only feature so you can have a VM hosted on Prem and still take advantage of snapshot debugger so let's snap shot debugger actually look like so you have the when you go in through the azure portal you have the ability to look at the call stack as well as some of the local variables that existed for a particular point in time of the exception and one of the things that's important to call out here is you can actually download that snapshot so what I want to do is I want to show you what that looks like because I think it's really really awesome so if I open up whoops clicked on the wrong thing so if I go to one of these failures right one of these failures we saw earlier I'm going to drill into that and when we reset our intent transaction details for an exception we can take a look and there's a little button here that says open debug snapshot so what I can do is I can click on that and what's going to do is it's going to initialize a gateway and it's actually going to start to process what's going on so what actually is snapshot debugger so snapshot debugger is a process that runs side by side with your application and what it's doing is it's basically collecting information while your application is running and then it's taking the PD B's that are deployed to your production server and it's massaging them into a way that you can take a look at the exception so as you can see here on the left hand side I have a call stack and I'm gonna click into right here so it looks like I did a search for Scott and it threw an argument out of range exception so that's really really valuable but maybe the exception is a bit more complex one of the things that I have the ability to do is I can actually download that snapshot if I click download snapshot it's gonna start to download a file so that download can take some time so what I did is I actually downloaded one herb from earlier today about 45 minutes ago when you open up that file which add I accession file you get this very interesting message I always that you know think it's kind of cute that you know we get a warning that you know we got something from us a source intercept source and that source just happened to be a sure in this case you open up this file in Visual Studio and what it's going to do is it's going to give you a mini dump summary and what that mini dump summary is is it's a collection of all the data related to this exception so as you can see there's modules here there's times when the exception occurred so the OS and the CLR version and I have this ability to click debug with managed only and what that's gonna do is it's going to load all the symbols that exist for this particular exception and it's going to actually spin up an experience similar to when you're breaking an application in production and one thing the call-out here is that the actual exception was thrown inside of throw Hobart CS which is part of system core Lib that might be not be valuable to a lot of folks but I have the ability to look at the call stack and I see my heroes there and I see an exception was thrown on line 53 of this particular class and was this exception actually doing so it looks like I pass in a name a string and then I make a query from a database and then I tried to get the the fourth item in that array what could possibly go wrong when you're trying to access the specific number of array that array might not have that particular instance so you get an argument out of range exception so this is obviously a silly example but I just want to show the thing that you have so you have the ability to use tooltip and as you can see the name is Bill if I take a look at the heroes I have tooltip here I also have watch an immediate window so I can actually pull up watch and type in name and it's a bill and then if obviously I can go into the immediate window as well and type in name and that's gonna give me bill so again really really simple scenario but it just shows you just the power of what snapshot debugger can do so we have about five minutes left so I want to take some time for questions so if you have you know if you want to take a look at some of the samples or additional documentation for this applet for this talk you know I'm using the URL list so shout out to Burke and sessile for putting that together I use it all the time so if you click on that particular URL or not click on it but if you go to that particular URL it's it'll take you it'll give you a handful of links so you know access to the github repository to see the tour of Heroes demo as well as some really valuable documentation on Doc's on Microsoft calm about snapshot debugger and application insights so we have about five minutes left like I said so let's take some questions perfect hey I say thank you so much Shane you got any questions we had a we had one question that came up sooner but looks like I got answered and I'll just let you speak to it real quick and the initial an't question was is it only for web apps I think we we kind of know the answer no it's not just for web apps but if you want to kind of expand on maybe some of the capabilities of the SDK that's out there for other types of apps other than web apps yeah so so one in particular so there is an SDK for WinForms so that that was built by the community and what that gives you is it gives you additional telemetry tracking for when you switch views in an in a win form right so that's one example you know there's is well one thing to call out is that even though we talked about dotnet a lot here any programming language can take advantage of a pin sites and there's SDKs that exist just for dotnet but for Java nodejs PHP and a lot of the SDKs are either owned by Microsoft or owned by major community members one good question that came up too is can I use a snapshot the bugger in docker yes you can so you have the ability to connect to I believe you it's and I believe that the AKS is in preview currently but you should be able to connect to docker applications even hosted in Linux school and I think your URL URL list that you had up there does that have some links to the docs about finding out more about snapshot and websites and all that it sure does okay and one last question I think we might have some time for here is how can i migrate normal logging to a pin size is it just a matter of using the SDK and things that are in the docs yeah so that so there's some documentation around that so if you're using like a pretty well-known library like an log or log Fernet or serial log so there are actually adapters that exist which will basically log all of the N log data into a pin sites as well so it's not a matter of you having to rewrite your login mechanism from scratch you can just append on to that by adding it into a pin sites and then obviously if you want to extend app insights you have the ability to do so with you know code and dotnet so you can write like track events and track exceptions and all that sort of thing to get all the telemetry you want I can add something to you know so I said I'm not sure if you know this but we're actually using a pin sites on the.net comp website so I would hope so cuz it's awesome yes it's awesome so we used it because for it tonight talk about might whoa originally was written dotnet and dotnet framework with nbc5 and so forth so we migrated it down at court - - and in case we wanted to figure out what's the performance are we missing anything so by using app insights we were able to figure out where we had missing files because we can actually see the 404 so we were doing we can look at our browser performance JavaScript performance so it was great for us to kind of fine-tune it and go as we like so it's a great tool especially for like migration or just to figure out what's going on your app and and really all we did is we deployed it to an azure app service when the left-hand side and said app insights emailed and that was it and the magic happened yeah exactly so then that's one of the great things about app in sites is that lighting it up is really easy so even if you don't have an application that's hosted in Azure it's pretty easy on Prem as well so there's a UI based instrumentation tool without code and there's also a PowerShell driven one as well so you don't need the code to actually turn on tap insights which is great yeah I know and that's some people in the chat I was as you were talking about while also bringing about Google Analytics sounds like you used Google Analytics app insights and like for us we're using both yeah why not yeah for us analytics is great to figure out how many people they're at where they're coming from and it's a nice quick little dashboard overview but it provides some information not all information that we care about how the act website is performing like we were able to see CPU a good example of this when the Kino started the CPU was getting hotter hotter and hotter and hotter we were 75 80 % CPU and a fairly large app service instance and we were able to get those details thanks to app insights yeah that's awesome sweet all right we're right on time so we're gonna get finished here so thank you so much I said we got syed here talking about vicious vicious to do for mac so we're gonna flip here a little bit and we'll be right back

Anders Hejlsberg A craftsman of computer language

>> Surely. Anything can be done here. Look at this diagram. I just drew it for you. Just go and make it so, right? No, coding is hard and it continues to be hard, and code gets bigger and bigger and bigger but our brains are not getting any bigger, and this is largely a brain exercise. >> Hi everyone. Welcome to Behind the Tech. I'm your host, Kevin Scott, Chief Technology Officer for Microsoft. In this podcast, we're going to get Behind the Tech. We'll talk with some of the people who made our modern tech world possible and understand what motivated them to create what they did. So join me to maybe learn a little bit about the history of computing and get a few behind the scenes insights into what's happening today. Stick around. >> In this episode of Behind the Tech, we'll meet Anders Hejlsberg. Anders has always been one of my coding heroes. He built Turbo Pascal, at Borland, which is the tool that I use to become a real software engineer. At Borland, he had a long career where he was Chief Architect of Delphi in addition to the Turbo Pascal tools and eventually moved over to Microsoft, where he helped create C# as the Lead Language Designer, and today, he spends his time as the Core Developer on TypeScript. Anders has had a 35-year career building development tools that software developers love. We're going to learn how he's done that today on Behind the Tech. >> So, welcome, and thanks for being my first guest on this debut podcast. >> Thanks for being willing to experiment. >> You were a calculated first choice because, I think I've told you this before, but I learned to program when I was 12 years old. My entry was BASIC in 6502 Assemby language, the 80 Assembly language. The first real programming I ever did was on Turbo Pascal. I went to a science and technology high school and took Intro to CS class and Turbo Pascal 5.5 was the tool. I don't think I would have chosen a career in computer science if it hadn't been for that sort of confluence of things. So like in a way, you're responsible for my career. >> That's awesome. >> The main reason I wanted to have you on the show is this must be the case for a huge number of folks and we'll get into your journey as an engineer. But what made you decide that you wanted to build programming and development tools? Because that's sort of been your entire career. >> Yes, it has. You know I've been doing it for more than 35 years now, and it's kind of scary to think back and it's such a long time ago now. I mean, and the world and the industry, there wasn't really an industry even. IT was so different. I mean, in the industry, I got started probably in the early '80s, but I got started coding in high school back in the late '70s. Probably I was trying to think back '78 or, yeah, '78. >> Were you the type of tinkerer where you were building a little programming language? >> No, no. So I was born and grew up in Denmark, and I went to a high school outside of Copenhagen. It was one of the first high schools to offer students access to a computer. >> Yeah. What was the computer? >> There was the old HP 2100 it was called. It had 32K of ferrite core memory. You can literally open it and see the ferrite core. So it was amazing. Paper tape reader and then after a while, they got a 14-inch one megabyte hard drive, which was absolutely state of the art. >> It was like huge. >> It was enormous. At the read-write head on that thing had this gigantic magnet, and everything was so primitive. You could program it, and we put that poor computer through so much torture, like trying to make music by moving the read-write head on the hard drive. They would vibrate the whole tape, and it was-. >> Yeah. Yeah. >> So that was sort of a very hands-on introduction to computing, and I too remember that you could either program it in Assembly code. I think there was a FORTRAN compiler but then there was an HP ALGOL compiler. >> Oh, Interesting. >> That was actually sort of how I vectored into that branch of programming languages ultimately. Because that was the first language I was taught. We didn't have BASIC. There was no BASIC on that computer. Do you know what I mean? So I learned ALGOL and this was a very primitive compiler. I mean, it didn't support recursion. >> Right. >> That machine had no stacks so call instructions would just store the return address and the first word and then return was an indirect jump back to that. Right? I'm probably going to get in trouble for saying it, but better than FORTRAN or COBOL. >> They were still better than FORTRAN. >> Yeah. Yeah. But anyway-. >> How much were you all influenced by the Scandinavian programming languages? So Niklaus Wirth was the designer of the Pascal programming language and then MODULA later on. >> It's funny, in high school, I didn't know anything about any of that, and really, it was just sort of learning by doing. Then, I started electrical engineering at the Danish engineering academy. There, I met a guy who had just transferred from another school into the engineering academy and we both liked playing cards, and he lost some money. So I had some IOUs so I had to get to know him. So I ended up getting involved with him and starting a computer company in Copenhagen. We had the very first retail store where you could go in and buy a kit computer. >> Wow. >> We were right at the cusp at that time of microprocessors becoming democratized. The 8080 and the Z-80. I'm like this is when the Sinclair ZX80 started to happen. There was this British kit computer called the NASCOM, which had a Z-80 in it, but I started writing software for that one then. It came actually with a Microsoft ROM BASIC. >> So what sort of software were you writing? >> Well, so first, I started writing games. It's funny, I never liked playing games but I liked writing games. >>Were these sort of text-based adventure games? >> Yeah. >> It was like Moon Lander and Star Trek and that sort of thing, right? You could actually buy these books. I think it was like Byte Magazine had these 101 computer games where you could type it all in, right? >> Just great. Like it was such a great thing. >> It was awesome. So I learned a lot. But then, I started actually getting into assembler coding and sort of trying to understand more about how the machine worked. Then I got curious about extending the Microsoft ROM BASIC. Because that ROM BASIC, it had to fit into an 8K ROM. So there were a bunch of commands it didn't have. There was no renumber command, which was a royal pain in the neck, because if you ran out num now, you had to manually go retype every line. But there were some extension points where you could actually sort of hook into the ROM BASIC and because they were an extra slot for E prompts on the motherboard. I wrote this little 4K ROM BASIC extension that gave you renumbered and a bunch of other things. So that was like a little plug-in tool kit. Right? >> How old were you then? This is like after university? >> Yeah, I was probably 20. >> So like very, very early in your career you were mucking around with your programming tools. >> Sure. Yeah. >> Is that just sort of a sensibility thing or- >> I just sort of found it interesting. There are a lot of challenges there, right? Then that interest further got piqued by- now that I've figured out, "Oh, you could actually the extend." I remember still missing that ALGOL programming language and I was telling my buddy, "Maybe I should write a little ALGOL thing that we could probably-.". "No, no. There's this new thing called Pascal. You really should check that out.". "Of course. Okay. Okay". Then I started like, "Oh, this is better. " Because one of the things that Niklaus did consistently through his entire career, he's the creator of Pascal, but he was involved with ALGOL and then later MODULA and Oberon, and every language got progressively simpler. >> Yes. >> ALGOL had all these complex call by value and call by name and then Pascal dumped a bunch of that, and then MODULA dumped even more of that and that Oberon got even more minimalistic. >> Yeah. >> I remember I've never written a real ALGOL program but because I was a compiler guy, the ALGOL grammar was all over the place. >> It was complicated. >> So complicated. >> So anyway, so there, I set to work and I wrote this little Pascal that was effectively the nascent Turbo Pascal, if you will, right? It had a little onscreen editor and a runtime library and a compiler and it was all squeezed into 12K in a ROM. >> What gave you the idea to do that? Because that's sort of a new thing, right? That might have been the first ID, right? >> Yeah. That was probably one of the very first IDs ever. Yeah. >> That's amazing. >> Well, UCSD Pascal was on the Apple too, but it was sort of different. It was a PCODE interpreter and the ID was not really quite as user-friendly. It was more like a sort of semi-command liney ID thing. >> So you wrote this thing in mostly in Assembly? >> It was all in Z-80 Assembly. Yeah. Oh, yeah. Now, that was my weapon of choice at the time, and that grew into a CP/M-80. It was obvious that one was a subset implementation, and then that grew into a fuller subset and then finally a full implementation for CP/M-80. At that point, we met the guys. Borland was founded in Denmark. A lot of people don't know that. We knew the original founders because they had had another computer company and it was a very small industry in Denmark. They were writing some stuff in Pascal MT Plus. I remember from digital research that CP/M. That was a horrible Pascal. It was like one of those insert-pass-one disk in drive. Right? Then they would grind and then you'd take that out and then it would write some of the temporary code and then you'd insert the code generator disk. It took an afternoon to compile a small program. There were like dialects of Pascal that were just like not as nice as They were Turbo Pascal. >> Right. Then they were afraid of making extensions, and then, I was never really afraid of making extensions if they were useful. >> Yeah. >> So these guys were "Wait. We got actually this implementation you should check it out". They didn't believe a word of what we are saying because that's not possible. >> I just want to double-click on this point again. Coming up with one of the first integrated development environments that you have written in Z-80 Assembly language at that point, that's a unbelievable breakthrough. >> I suppose in retrospect, yes. I've never really thought of it that way. But, you know, it's- >> Just incredible. [inaudible]. >> It just seemed like this is going to be so much better than having to have a first date a load an editor and then load at the bargain. Why not just put it all to there? I don't know. I never really- and especially, at the time, because again, like more framing. These are not Windowed systems, can't have multiple things opened at the same time. It's super tedious to switch from one program to another. So like having everything in one place is just as huge >> Totally. The added compile, run, debug, cycle, just shrunk by many orders of magnitude. >> Yeah, and I'm embarrassed to say I've forgotten what was it F9 to compile and run, or was it F5? >> I don't even remember what it was. I think it was F5 yeah but. >> It was like miraculous. >> Maybe F3 but yeah, it was great. There were all sorts of tricks in there like the runtime library was the first 12K of the system and then when producing code, I just copy the first 12K into the X we were producing. There is your runtime library, right? Then generate code from there on out and you could compile the memory and we'd put the code in memory and run it, right? Or the original implementation compile to tape, to floppy tape and then you go, sorry to the tape recorder interface, right? Then you can load that machine code up because I mean there was only 64K of memory. I mean it was crazy. >> Yeah. So, I bought a copy of Turbo Pascal 5.5 out of a catalog called Programmers Paradise. This is just sort of how you used to buy software and so I forked over my two hundred bucks or whatever. >> Oh no, it wasn't even that. It was $49 like $49.95. >> It was affordable because I was poor. So thank you for making cheap software. >> Yeah. >> But like it came on like this bundle of five and a quarter inch floppy disk that sort of fed into my and I was lucky... >> I mean I got to get credit there to the Borland guys, to Philippe and Niels and Mogens and all of the original founders of Borland because what they did, they ended up licensing this Pascal compiler that I had in my small company and we were selling it for 500 bucks and doing business the way business was normally done for a software, right? Then they licensed it. Of course we never thought to put a minimum price on what they were supposed to sell the product for and then come back with we're going to sell it for $49.95. What? You got to. It's just terrible. It's supposed to sell for 10 times. And so they cut the price by 10x and then they literally sold four or five orders of magnitude more copies of it, right? That was tremendous. >> Yeah, I mean when you think about the life cycle of innovation, it's like not always just about the technical thing. Like that wouldn't have been an appropriate environment for students if they cost 500 bucks. >> At that time it was like, "Hey, if you only charge 50 bucks, why even pirate? It was worth just to have the manual that actually tells you how it works, right? >> Yeah. So one of the other things that was really good about Turbo Pascal was the manuals were actually quite good. How big a push did you have in that? >> I had written manuals for the Pascal compiler that we had in our company called Poly Pascal and it had a pretty extensive manual for the language. The introductory parts were not as great and Oler who wrote the documentation Oler Rassmussen. He did a great job on turning that into something that was really a fun book to read and so a lot of people were very happy with the documentation as well. So it was just a confluence of a bunch of factors that just came together right. And the right thing at the right time and the industry was so nascent. I mean that was it. >> So going back to your university days, did you have a professor or colleagues or like someone who was really great at the programming language the compilers part of the curriculum where they sort of lit this aha moment for you. >> Not a whole lot actually. I did electrical engineering because in order to do computer science, you would have gone to the university. But I was always more of an engineering sort of focused and I wasn't necessarily sure that programming was what I wanted to do. Do you know what I mean? >> Yeah. >> At the school at the time, they had yet to introduce personal computers. So, they had the Northern European Computing Center there where you would turn in your stack of punch cards and then the next day you'd get the printout which would just be 100 pages that said error, error, error and then you'd have to go back figure out why it was that. It was horrible it was like a week long debug cycle. >> Yeah. >> But then they started getting some again also some Z-80 and CPM-based microcomputers and by the time I left the university there, they were actually using Turbo Pascal or Poly Pascal the one that I written in the introductory courses. >> Holy crap. That must be great. >> So my professor did allow me to not attend the class he gave me an A. >> Because you've written the compiler. >> Yeah, that's right. >> That's great. >> Yeah. >> I think one of the things that folks may have started to take for granted now is like you sort of jump online, you've got Google, you've got the open source community. >> Right. >> YouTube and like all these video resources. I would argue that it's like much easier now to bootstrap yourself as a programmer or even in sort of esoteric things like how to build a compiler. So, how did you get your bootstrap, like how did you figure out how to do this stuff? >> You learn by doing. You learn the hard way in a sense. >> I mean in retrospect there were so many things that had I known that, I could have gotten there a lot quicker. A couple of things I suppose is one is you couldn't stop me from doing it. I wanted to do it. Someone once talked about how do you get really good at something. Well, it's by putting in the time. There's this talk about the 10,000 hours that you got to put in and I was like yeah I definitely put in 10,000 hours in the first three years that I did this because I was obsessed. I just have to do it I didn't care if anyone paid me. It was just a challenge of it was so interesting. >> It probably wasn't 10,000 glorious hours. You were probably were making lots of mistakes so. >> Absolutely. Absolutely. Yeah. I didn't know how to write a compiler. But then you started looking at compilers that were written and since my native language was machine code I mean heck yeah I could disassemble other stuff and figure out how that worked right and then you gradually learned. But there were still things I didn't know. Even in the first version of Turbo Pascal I remember all the symbol tables were just stored as linear lists, which of course doesn't scale so well, right? I mean and then I remember learning about hash tables so I was like, "Holy cow! I got to go home and try this." Then I put it in and doubled the speed of the compiler, right? I remember that's one of the first books that I thought was really instrumental for me in understanding a lot of sort of the basic computer science was written by Niklaus Wirth called Algorithms Plus Data Structures Equals Programs. >> Yeah. >> Which is a great book. >> Oh my God. It is the most pragmatic computer science book I have ever seen. I was like never into the symbolism and the formal proofs and whatever. I'm just like give me the algorithm. Tell me. Let me understand how it works, right? >> Yeah. >> This thing explained how binary trees and binary search and hash table and how to build a compiler with a scanner and a lexer and a parser. Do you know what I mean? Code generator and recursion and oh my God it was like I loved that book. >> Yeah. >> You can go back to it today and it is still super valuable. >> I've always loved books like that. Another good one Dave Hanson who used to work at Microsoft Research here wrote this book called C Interfaces and Implementations. And I like C because it's sort of simple. I mean it's got a bunch of hair on it, right? >> It does. It does. Easy-to-make mistakes. Yeah yeah. >> It's easy-to-make mistakes not the most elegant language but it's simple you can sort of pack all the rules and you add. But this book, C Interfaces Implementations was genius because it was a bunch of data structures and sort of approaches to programming that were super pragmatic. They had these very broad applications and it was almost like teaching C to do crazy object-oriented sort of things that couldn't- >> All your tables do. >> Yeah. >> Yeah, yeah no I mean heck at Borland, we definitely had lots of systems that were sort of calm that Windows is largely based on is effectively roll your own read tables, right? >> At Borland, how did you all get feedback? How did you know you were pushing your product in the right direction? >> That's a good question. >> The cycles were long, right? >> They were. Back then there were a lot of trade magazines, and you got a lot of feedback through that. Through the reviewers, like [inaudible] and Byte magazine and what have you, right? We also had bulletin boards early on. Like the old BBSes that we would monitor in our tech support, and so, there were a variety of ways. People would write us letters and send us letters. I have so many letters with suggestions for stuff. So, we always had a long list of things we wanted to do. It was really not a matter of figuring out what to do, it was like a matter of which ones don't we do, and sorting it and doing the right ones. You mentioned too Pascal 5.5. That was the release where we introduced Object-Oriented Programming. Oh my God, that was like the big buzz word of the time. That was like the AI of the 80's, right? >> It was a good implementation. So, you must've taken some inspiration from Modular. >> Well, Object Pascal was probably the work that Larry Tesler did at Apple. That was definitely an inspiration. Although, our first implementation interwove Pascal 5.5 was a little bit different. It had some influences from C++ also. Then by the time we got to Delphi, I think we were more true to Object Pascal. There was no difference between object references. You didn't have to use an up arrow to dereference them, and then that made the syntax a lot more gentle on user. It was just fu.bar not fuuparrow.bar. >> Yeah, I remember. So, 5.5 was where I learned Object-Oriented Programming. I think I'm sort of lucky because if you got thrown into a modern Java for instance, and that was your playground for Object-Oriented. It's so complicated now. >> It is, but it's also in some ways simpler, right? Because back then, the languages that people used, by and large, did not have garbage collection built-in, and were very not safe and had minimal runtime checking. In fact, we ship Turbo Pascal by default with runtime checking turned off, because we did better on the benchmarks that way. A lot of reviewers were not smart enough to know to turn it off, and so, they were comparing apples to oranges. We just wanted to make sure that we were always in the running there. Once you introduce garbage collection, then you really start to up the level of programming styles. You can write in a style where you have much more complex function results, and you don't have to worry about who de-allocates this. Who owns this memory. Who's supposed to get rid of it again, and you don't have all of these cycles that you maybe get if you implement with Ref counting or whatever you do to keep track of your objects. So, it made the world a lot simpler in a lot of ways. Then, the fact that these languages can be memory-safe, that removes a whole bunch of other. The thing that saved us all at the time was that there were just only so much capacity. There's only so much you can do in 64K. Even though Builds and 64 was going to be enough, there's only so much you can do on 640 also. So, that always saved us. It was like the complexity was never big enough that you couldn't get away with it. But once you're in this now, is literally a bottomless pit. There's so much code, and you take so many dependencies, and if you don't have some of these guarantees built into the system, you're going to be spending an awful lot of time just chasing down dumb bugs that really you shouldn't. That's not a creative process. That is just a waste of time. >> Yeah. So, I want to get to that, but before we jump into modern type, let's talk a little bit about Delphi. So, maybe the compiler didn't change all that much but my god, that would be- >> That was a revolution on the IDE side. It's interesting because I've worked on a project in between. I never went anywhere. It was code-named Monet at Borland, and it was about building applications visually, which was very sort of- Back then everyone was talking about software ICs, and you could just plug and play and draw lines between the inputs and outputs on the different things. We were building this very advanced set of components that you could just plunk down on a canvas and wire together, and making Fahrenheit to centigrade converters was super easy. But it turned out that making big apps was horrible because you had lines going from everything to everything, and it just didn't scale. But I think in that process, I got a real appreciation for what does work well visually. Like designing input and GUIs and whatever, and GUI was starting to happen. So, there was definitely a need there. So, by the time this Monet thing did not pan out, we realized it wasn't going to pan out, then we went back to basics. Then go, "Okay. Well, let's actually get into the GUI era with this product." Then there was this thing called Visual Basic out. >> Correct. >> That taught us a lot, but also had a lot of issues. Like it didn't have object orientation, it was interpreter-based, it was generally frowned upon language at least by a lot of people, and so, we go, "We can do this. We can do this, and we can do it better." >> Yeah. >> That was the genesis for Delphi. Then I think in the process of building Delphi, we also realized that- and there is this I think was Zach Urbach, our program manager who astutely realized that you can't just ship a Rad tool. You've got to have some angle, and the angle at the time was client-server. So, we actually pivoted it into a client-server tool. That gave us an inroad into enterprises and companies that were really building real database connected apps. I remember competing with PowerBuilder. I don't know if you were with PowerBuilder. So, that gave us a unique vantage point compared to Visual Basic. >> It was sort of an interesting thing. Delphi came out shortly after I graduated from college, and I became a real software engineer, I remember being so grateful for it because I did a bunch of work with it that clients were paying me for, and the tool made me look better than I actually was. We had made this transition from, you build in these text-based apps where if you really fancy, you're sort of blasted ASCII codes and the screen buffers. But Windows 95 came out. The onus was on you. It looks slick. It was a pretty Operating System. >> It was an awesome way to build client apps. It really was, and then it had a bunch of fun things in it. I remember the two-way code generator. You can either visually design your form or you could go in and modify the code and then the form would change, right? Making that work was not easy, but once it did work, oh my God, it was so cool. >> That must be a gratifying thing. You've been doing this your entire career, but in my mind, a force multiplying effect of building developer tools as you put your development effort into this thing, and then it gets into the hands of the huge number of people. >> That is the thing that I think in retrospect has been hugely rewarding. It's like when you build end user apps, you don't build the same kind of fandom as you do when you're building developer tools. Because developers, they put in the hours. Do you know what I mean? >> Yeah. >> They come to really depend on their tool. They come to truly appreciate what they do. >> Yes. >> Then they become these ardent fans. >> They are almost religious, right? >> Yeah, I know, and that is so rewarding. Throughout my career, that has been so rewarding to go speak at a conference and have all these people come up and tell me how you saved my life. You did this. People have literally told men that. It's like guys who were in Russia, and couldn't put bread on the table learned to program with Turbo Pascal and literally this guy is claiming I saved his family's life. I mean, that I'm just God. That's amazing. That is wonderful. >> Really great. >> Yeah. >> So, at the time you sort of referenced it already, there was this intense competition amongst commercial entities, companies like Borland and Microsoft, and the guys who were building PowerBuilder. There were these database language things going around and literally catalogs full of shrink-wrapped software that was just for developers to help them get their job done. So, the big thing that came on the scene right after Delphi was Java. How did that factor into your move from Borland to Microsoft? Because, in a way C-Sharp, it seems like [inaudible]. >> There is an arch there definitely. But I do remember, I think it was in '95 when Java made its first appearance. This is where the Internet was starting to happen. Particularly, I think in the development tool space and programming, there was this collective madness around Java where everyone thought it was over. It was done. There were going to be no more [inaudible] and Java to take over the whole world. There was a Java fund. Remember the Java fund? Funded by hundreds of millions of dollars whose sole purpose was to just invest in companies that were building their software in Java. As if that would make a difference. It was brilliant, what Sun did, I think that even they had no idea what they had unleashed here, right? But it was discouraging in many ways because we felt that, yes, that's fantastic for building applets in the browser. But you can't build real Apps with this thing. But hey, you know what? There were the shiny object. There was collective craziness over the Java thing, but there were also things that I thought were interesting. This whole notion of write once and run everywhere is even today, it just so happened that it wasn't actually born out by Java. It was born out by Javascript. But, which was there already in the browser and ignored for a decade. It's crazy. We'd had a JBuilder tool we built at Borland, which actually was built in Delphi. They started with the Delphi IDE, chopped it down, and then the language service, well- They weren't really called Language Services at the time, but the Mini compiler analyzer are used by the IDE to do all of their syntactic highlighting and whatever that was also written in Delphi. So, I got to know Java as a language. Then at the same time, there was a change afoot at Borland. Borland had a bit of an identity crisis, in the sense that everyone was up leveling how business was done. It all became a game of platforms. Oracle was databases. Sun was workstations. Microsoft was the OS, and then Office became another platform. And Borland never really got the platform up leveling. It was always a bunch of separate products, and we try to bundle them together, but it never really made sense. Then the company was so singularly focused on trying to get a foothold in that business that they started neglecting their developer tools, which was really where the company came from, and a series of management revolving door. Then I got more and more disillusioned. Then of course, Borland ended up going through a bunch of reductions in force if you will, and we spread a bunch of people into the universe. A bunch of them went to the valley. A lot of them went to Microsoft. Then of course, they started calling, every summer when the weather is nice in Seattle, I'd get a call from Brad Silverberg, who had run R&D at Borland, and now was running Windows 95 development. So, I would come up and we'd talk, and the first year I wasn't interested. But then eventually, it was time. So, I joined Microsoft in '96. >> Was C# the first thing that you worked on? >> No. Not at all. There was no C# There were .NET at that time. I joined to work on Microsoft's Java development tool set. >> Interesting. >> Yes, and I've worked on Visual J++. So, at the time, we had a Java development tool, and it was really just C++ IDE with the C++ compiler taken out and a Java compiler stuck in there, right? >> Yes. >> That was visual J++ 1.1 I think. Then, we jumped from 1.1 to 6.0 because we realigned all of our Rad tools, VB was at version 6, and so, it became Visual J++ 6.0, and it had a Visual designer. You could design applets and whatever. But then we were also doing stuff that made it a better language for writing Windows Apps, and that ended up being very controversial. I have personally read the contract we had with Sun. It was explicitly permitted in there that as long as we ran all the standard tests, we were free to do additional inventions. But that blew up. Literally, within three months of our shipping Visual J++, our product was enjoined by a judge in San Jose, and we were required to put in a warning dialog, "Warning! You are about to turn on Microsoft proprietary extensions. Are you certain your wish to proceed?" And that was just so you could use com interop. That was considered so evil. I was like this is crazy. Inside Microsoft at the time, the Java fever, it was all over the industry and there were literally fractions of groups at Microsoft that believed that it was all going to be Java. We should build a Java OS, it should all just be Java. But then that happened the whole Sun lawsuit and whatever and that was sort of the genesis for us understanding that, listen, it's really hard to do what's right for your customers by extending someone else's platform. We've got to build our own that works for what it is that our customers are telling us that they want. >> That was the genesis of dot net and of course, we needed a programming language. I so happened to find myself at the right time at the right place for that. >> So how fun was that? Is that the first time that you had a blank slate? >> Totally. Yeah. I mean can you imagine the opportunity to have a company like Microsoft put their might behind a programming language that you're going to create. I was flabbergasted that I was given that opportunity. Yeah, sure I'd proven myself but there were still a lot of other people at Microsoft who had different ideas about what should be done and then ultimately I was the one who was handed the task. So that was wonderful and we had a great team on that early C sharp compiler which originally was written in C++ or C plus minus because we didn't use all the C++. >> Which is a whole other design. >> Yeah, yeah, I remember a guy named Peter Goldie wrote the core implementation of the compiler, I wrote the language spec. We had a wonderful design team process that we set up that you know to this day still exists. Where we used to have three meetings a week for two hours, where we would just do the language design. Iterate on it, you know what I mean? And Scott Wilson with our program manager that I worked with for almost a decade was the PM. So for four years he commuted from Hawaii. We would do our design meetings on speakerphone with him. It was a great time. >> Based on some of the stuff that you've talked about already and just sort of looking at C sharp and then typescript, you're fairly pragmatic when it comes to language design. You're not one of these language designers is like, "Oh, let's throw a Hailey Milnor type system and-" >> I've always been a believer in understanding the problem and feeling the utility of something before I want to go implement it. I have to believe in it. I don't just throw it in there, yeah, I need a type system, want an Hailey Milnor or whatever. Now, no. I want to understand why is it there and does it really need to be there? >> And a real programmer is going to benefit from it. >> Exactly and so that was the case in C sharp and that drove a lot of our decisions. For example, we added properties as a first class language construct because everyone was doing properties. It was like that was how programs were written and Java didn't have those, for example. So there were pragmatic decisions that we made. So whenever someone goes, why is this feature there? It's not just because I thought it was fun, it's because it solves this, this and this problem. And ideally, with every language feature, this is something you come to learn over time is, people will request a lot of features but they will always have synthesized their idea of what it is that they want. They really come to you with an instance of a class of problem and they tell you I need this instance. And then-. >> So the trick is to get them to really describe the problem. >> No, the trick is for you to understand what is the class of problem. >> Got you. >> And that's what you go implement. So I never wanted to implement a language feature unless I could see multiple good uses for it. We're not just going to implement because it does this one little corner of XML well and that's it. I want this to be a generally useful thing that you can do other things with as well. >> Because it's a very serious thing to bake something into a language. >> The thing you come to learn about languages is you can add all you want but you can never take anything away. At least if you care about backwards compatibility. And we've seen lots of train wrecks where people did not care. Like say the transition from Python two to three even when you're just doing it in the name of cleaning up stuff that isn't right or isn't ideal or whatever. You can't do that to your user base. They have too much of an investment, it is your responsibility to ensure that their code continues to compile and work and then you can add more on top. And if you're not going to do that then you might as well blow it all up and go create a whole new thing that advances the state of the art. The worst thing you can do is the 99% compatible, that is absolutely the worst thing. >> So some of that attachment to the old is emotional but you can very quickly have hundreds of millions of lines of code across. >> If you're a serving enterprise, well, it doesn't even matter enterprise is like anyone who writes a large body of code and then gets adopted somewhere, does not want to have to spend a bunch of time changing it in random ways just so it's prettier. No, big code bases get ugly, they all do. Then programming languages do too. I sometimes joke that show me the perfect programming language and I'll show you a language with no users, because only then can you go change it. >> I did an internship at Cray Research when I was a younger engineer still in grad school. One of the most mind blowing things that I had ever heard up to that point was I was sitting at lunch one day, one of these Cray veteran engineers was describing this sales process. So, they were trying to sell a supercomputer at some point to a car manufacturer and because they had this big FORTRAN codebase, it was due in finite element analysis. So they could simulate crashes on these supercomputers. They'd come out with this fancy new version of unicode, so it was just going to be impossible for the car company to rewrite their FORTRAN code base which was tens and tens of millions of lines of code to work on this operating system for this new machine and the guy's looking at it like, all right, this machine is millions of dollars and that's tens of millions of lines of code. The operating system kernel is 25,000 lines of code, we'll just write a custom operating system for this. >> Being able to unpack where the abstraction and complexity is, is really sort of an interesting skill you have to develop as an engineer. >> Yeah. So pragmatism was always a main driver for me and it continues to be. >> What lessons is a language designer or like as a builder of development tools, have you learned that you're applying the typescript right now? >> Well, we touched on a couple of them. You really have to respect and value backwards compatibility. Doing language design, it's interesting, there's really in a sense two phases to designing a language. There's 1.0 and then there's everything else. And with 1.0 it's a green field. You can do whatever you want to do. It's crazy fun and you can be super inventive. But then from there on out it becomes a very different discipline because now, it's a game of trying to sneak in new features in a way that does not break backwards compatibility. And that is very different. And also you got to be very cognizant of every programming language sort of has a gestalt to it, if it's an object doing a programming language, you can move it towards funtional program but you can't make it into a functional program. Like where immutability is first. So there's-. >> There's iterators, but yeah. >> Right, there are certain things where you just got to go, "No, if we do this that'll just give people two ways of doing the same thing and now there will forever be confusion about which one it is that I'm supposed to use. So, we can't do that." So, after 1.0 you have to learn when to say no and save it for the next one, which is hard because there are things you want to do but this is not the right place to do it. And you could sink the ship if you did and then, I think you learn also to withstand the pressures of marketing. I can't tell you how many mails I have written to defend our decision not to put XML literals into C sharp. I literally spend a year writing that email every two weeks. And Visual Basic did put XML there and I was always like "Listen, there are so many different ways you can write this markup. If we put it in an XML sinks then we sink along with it." Can you imagine if we'd had XML literals in C sharp. Now what-. >> I can't even imagine. >> And it's sometimes you just got to stick to your guns and the face of adversity and go "No, this does not belong here, here is what I know, I understand how with the vantage point of today it might look like it does belong here but it doesn't belong here, long term." >>Yeah. >> So, there are lots of interesting things that you don't realize up front. >> I've always thought that the better design programming languages were the ones where there was some coherent philosophy that was developer oriented up front. Pearl, which in many ways this is I've written a lot of bad Pearl code in my time. It's really easy to do and it's my fault, not language's fault but it had a lot of good stuff. Like Larry Wall the creator of Pearl had these philosophical tenets like make the easy things easy and the hard things possible. I remember hearing Fred Brooks at one point say one of the best things you can do in language design is to figure out the things that you're not going to let people say. Because that's where mistakes happen. So it's always fascinating to me what these philosophical principles are because there's no one right way to design a programming language. >> Right, but there are lots of wrong ways, and I think that one thing that people tend to forget too about programming languages is well a couple of things. First of all, it's fascinating to look at how slowly they evolve and how similar the programming languages of today are to the ones we use 50 years ago. It's really quite frightening. I mean like Pascal was invented in 1974, so we're talking about like 40 some years here and it doesn't really look all that different. Okay, we've had a few, okay, object orientation but then Pascal looks a bit like a functional programming language, it doesn't have pattern matching, it doesn't have lambdas or whatever but it has some of it like functions and data being separated and anyway. So that's one thing you come to realize. I think another one is that it's very easy to focus on one shiny thing that you're programming language is going to do. But then you always forget about the 90 something other percent that every programming language has to have. And that 90 other something percent keeps getting bigger and bigger now because people need tools, they need IDEs, they need statement completion, they need code navigation, they need blah, blah, blah. And so whenever you're like, "Oh I got to have my little DSL like thingy here just for configuring this thing, oh wouldn't it be cool." Well, are you going to build an ID VoIP or you're going to build two? "Oh no, they're never going to get big enough for these programs." Well, every configuration file grows up to be its own crappy programming language eventually and if you don't watch out. And then they get bigger and bigger and bigger and now you need tools and now there we are repeating history again. >> Some of the hardest things that I've had to do as someone leading teams of engineers is to be the bad guy coming and saying, "Okay, we're not going to use that shiny new language." And it's precisely for that reason when you're figuring out what development tools you're going to use to empower all of your engineers to build great things, you have to make choices because all of the apparatus that you build around them to support them, what's the build system going to look like when you've got hundreds of millions of lines of code and thousands of engineers? How do you do continuous integration and continuous deployment? What is your testing regime look like? So you build all this automation that sits around the programming language, the engineers can sometimes have this notion in their head it's like, "Oh, it can't be that hard, I'll just write my one thing in this and it'll be okay." And then- >> That can happen to you, it particularly the higher you rise in the engineering ranks and the less code you write, the more possible you think the impossible is, right? You become an architecture astronaut where surely, anything can be done here, right? Look at this diagram, I just drew it for you. Just go and make it so, right? No, coding is hard and it continues to be hard. Code gets bigger and bigger and bigger but our brains are not getting any bigger, and this is largely a brain exercise. >> Yeah. >> So one of the things that I end up talking with fellow engineers about a lot over the past several years is where we are now as a discipline, as a profession, compared to where we were before. So, in some ways, the programming languages from a language perspective aren't that much different now than they were. But you do have these crazy things like cloud computing and open source software where, I can't tell you how many times, when I was a young engineer I re-implemented chain hashing implementation. It's like I could probably still write the code just out of finger memory. >> Right. Right. >> But like so much of this stuff is accounted for you, so, you've got really robust SDK's and like a standard class library for programming languages and then you've got like all of this infrastructure. What you can sit down in a weekend and write in terms of internet service application, compile it, press long button and ship it to a cloud, then expose it to the world. It's like crazy. >> No. It's phenomenal what's happened here. I think a lot of it is like - open source has done a tremendous amount to shorten the distance between individual programmers and between users of someone implementing a tool and someone using a tool. We're this close. I mean, I feel it on my body every day, right? I sit on the GitHub issue tracker on TypeScript and then I'm talking to the very people who are using it and if they report a bug, we can have it turned around and have it in the nightly bill that evening, which that used to be a two-year cycle. We have done it like old proprietary style. So, the pace of advance there and iteration is just gone up so much. That is- >> It's also that you doing it in the open, right? >> Sure. >> Like so many people are making so much of this stuff available for low or no cost. >> Yeah. >> That is still a strange phenomenon, because ultimately, someone's got to pay, right? >> Right. >> I don't know where that's going all land eventually, but I have to say I do love the process of doing it. It's sort of like a return to the things that really matter about programming. I mean our team, it's not a big team but it allows us to be craftsmen and it allows us to really just continue to iterate. I was always a great fan of- you don't just build a product and throw it out there and then you move on to a whole new thing. No, you got to come back and polish it. Then iterate on it and make it better and make it better. It doesn't get beautiful just out of the box. It gets beautiful over a period of years of constant iteration and care. Do you know what I mean? >> Yes. >> That's something that this ecosystem allows us to do at such a phenomenal pace that it's just beautiful. We could have never done what we're doing now with Visual Studio Code and TypeScript in the old proprietary world. It simply would have taken 100 years to get that amount of feedback incorporated on the kinds of cycles that we were on back there. >> Right. >> So that's great. >> That's awesome. >> Yeah. >> I think maybe that's a good point to stop. We've gone from core memories to the sort of near infinite rate of change in open source software. So, thank you so much. >> All my pleasure. It was great, fun. >> It was awesome, so fun. >> Fun talk, yeah. >> Thanks for joining me from Behind the Tech. It was a lot of fun speaking with Anders. I had some surprises in there, like I didn't realize that he had written a precursor to Turbo Pascal while he was still in university. That may very well be the first integrated development environment in the entire world. And he's so modest about it, like, "I never thought of it." This is one of the more important breakthroughs from point of view of the developer that has happened in the history of computing. So, many thanks to Anders for being on the program. >> Next time on Behind the Tech, we'll hear from Alice Steinglass who heads Code.org. We'll hear about how she's working to make sure every kid has the opportunity to take computer science classes in school. Be sure to tell your friends about our new podcast, Behind the Tech, and to subscribe. See you next time.

Adam Day Promoting Creativity with Physical Environments

Good morning, everyone. I'll be leading the last session with Chris Congdon from Steelcase, and we'll be focusing on the built environment. I think this is a very crowded field. We're all in various ways trying to get our teams to set the stage. I like the theater analogies earlier today, because really it's about stage setting to figure out how we can prime our teams to be more creative. Let's see if we can get our slides up here. This is very much sort of going from macro to micro, looking at the passive environment and understanding what can work. There's been a lot of, I think, simple applications of a lot of the creativity research that's led to a lot of silver bullets. I think you read about them in the blogs everyday about we need to add plants, we need a baristo, we need to lighten the colors, we need to put everyone in the same room, they need to be in different rooms, on and on and on. I think we're realizing of course that we've talked about today, that the creative process is obviously much more complex than that, and it's also very paradoxical. There's a lot of creative tensions that we need to solve. We felt that in looking at this, the best way to frame it is more in the analogy of a recipe. We're all cooks at some level, and a lot of our energy has been focused on the main ingredients, things like comfort, control, inspiration. It's definitely been part of, I think, the positive psychology and things that make us feel great and prime us to sort of be at our best. The problem comes is that when we design experiences or environments that create these emotional sensations, it ends up being a little bit more like a cruise ship atmosphere. High levels of satisfaction, probably low output in terms of original ideas but everyone feels great. We have to balance the main ingredients with some spices. Actually, it's counterintuitive but we need things like stress, surprise, constraint, things that are uncomfortable, sometimes they're unwelcome. The challenge is if of course we have an environment that is only spice, it's kind of more like an interrogation room than a cruise ship. That doesn't work either, and so we have to figure out a way to resolve these tensions. All of these things need to be true in the space, and the question we're going to explore is that balance process. There's an additional layer that is a challenge for the environmental design, which is all of us need a different mix at a different time. You think about the design process and architecture and trying to design things for 5 years, 10 years, 20 years, knowing that you have people coming in and out, each of whom have a unique need that changes over the course of the day. How do we create environments that actually can help us achieve greater creativity? Our teams will be looking at this idea of tension, and finding, and discussing what are the best solutions that we know of now to create these emotional responses within a space, both on our main ingredient list ... This is not exhaustive either. There's other things here. Boredom, arguably, is a very good creative input here ... But also on the spice side. Then look at not just what creates these responses, but importantly what are solutions that can move us between these tensions or across them to make our environments more tunable, more dynamic, more responsive so it's not an astatic experience. We'll be trying to energize and change how we think about the built environment to drive the creative process. Looking forward to discussion. Thanks, everybody.