Building a Live Programming Tool with Roslyn
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 96 | |
| Autor | ||
| Lizenz | CC-Namensnennung - keine kommerzielle Nutzung - Weitergabe unter gleichen Bedingungen 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben | |
| Identifikatoren | 10.5446/51702 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
NDC Oslo 201654 / 96
2
7
8
9
12
14
19
20
26
28
31
33
38
40
43
45
48
50
51
61
63
65
76
79
80
83
87
88
90
93
94
96
00:00
Quick-SortFormation <Mathematik>DifferentePerspektiveSoftwareentwicklerProgrammierungMultiplikationsoperatorBitrateFront-End <Software>RückkopplungWhiteboardCodeGruppenoperationBildgebendes VerfahrenGebäude <Mathematik>Gewicht <Ausgleichsrechnung>SchwebungVisualisierung
01:20
GeschwindigkeitCodeCompilerWeb SiteProjektive EbeneBitPlug inQuick-SortSoftwareentwicklerProgrammierungVisualisierungDifferenteTwitter <Softwareplattform>Web logGebäude <Mathematik>CodeEinfach zusammenhängender RaumNormalvektorSystemplattformComputerspielProgrammierumgebung
02:46
Quick-SortMathematikCodeMultiplikationsoperatorProgrammierungLaufzeitfehlerProgrammfehlerATMJSON
03:42
ProgrammierungQuick-SortEinfach zusammenhängender RaumEinsMultiplikationsoperatorAbstraktionsebeneNeuroinformatikProgrammiergerätRechter WinkelWeb logQuellcodeGebäude <Mathematik>Güte der AnpassungSchreib-Lese-KopfComputeranimationBesprechung/Interview
04:40
CodeInnerer PunktFormation <Mathematik>BildverstehenSpielkonsoleQuick-SortProgrammierungTwitter <Softwareplattform>MathematikCodeLoopMinkowski-MetrikRückkopplungZweiProjektive EbeneSoftwareentwicklerNatürliche ZahlVisualisierungBildverstehenGeradeResultanteSyntaktische AnalyseSkalarproduktComputerspielOrdnung <Mathematik>Einfach zusammenhängender RaumIterationVariableMailing-ListeMultiplikationsoperatorFunktion <Mathematik>Reelle ZahlObjektorientierte ProgrammierungGraphfärbungNichtlinearer OperatorAbstraktionsebeneDatenbankBitAggregatzustandTouchscreenGebäude <Mathematik>MAPE-MailWechselsprungRuhmasseFrequenzSystemaufrufSoftwareZahlenbereichKontrollstrukturCompilerEinfache GenauigkeitAdressierungExistenzsatzWinkelRichtung
09:34
Quick-SortSyntaktische AnalyseObjektorientierte ProgrammierungVisualisierungMailing-ListeStreaming <Kommunikationstechnik>Projektive EbeneAggregatzustandProgrammierungHeegaard-ZerlegungCASE <Informatik>GruppenoperationGeradeMomentenproblemMultiplikationsoperatorInstantiierungProgrammfehlerZeichenketteResultanteMinkowski-MetrikWechselsprungLoopProgramm/QuellcodeComputeranimation
12:00
LastKonfiguration <Informatik>Heegaard-ZerlegungGeradeZeichenkettePerfekte GruppeAusnahmebehandlungSpannweite <Stochastik>InformationsüberlastungVarianzAutomatische IndexierungFehlermeldungQuick-SortObjektorientierte ProgrammierungMailing-ListeCodeRückkopplungProgrammfehlerZusammenhängender GraphMereologieProgrammierungGanze ZahlTopologieMomentenproblemCASE <Informatik>IterationProgramm/QuellcodeComputeranimation
14:52
GeradeProgrammfehlerCAN-BusAnalytische FortsetzungQuick-SortZeichenketteKonditionszahlMultiplikationsoperatorCASE <Informatik>MomentenproblemBitCoxeter-GruppeWechselsprungDemo <Programm>Nichtlinearer OperatorRückkopplungMinkowski-MetrikHeegaard-ZerlegungFehlermeldungProgramm/QuellcodeComputeranimation
16:20
DreiQuick-SortElektronische PublikationVisualisierungRechter WinkelHalbleiterspeicherInformationSampler <Musikinstrument>CodeMultiplikationsoperatorAnalytische FortsetzungRekursive FunktionBefehl <Informatik>Ordnung <Mathematik>ResultanteZahlenbereichProgrammierungTypentheorieFigurierte ZahlCompilerProjektive EbeneKommandospracheProgrammschleifeGraphfärbungProgrammfehlerDienst <Informatik>Formale SpracheDreiecksfreier GraphWeg <Topologie>ZweiQuellcodeLokales MinimumPhasenumwandlungSpeicherbereinigungGeradeGerade ZahlFunktionale ProgrammierungSchlussregelCASE <Informatik>TUNIS <Programm>Gesetz <Physik>IntelProzess <Informatik>Gerichteter GraphSkriptspracheObjektorientierte ProgrammierungDezimalbruchTermGebäude <Mathematik>FlussdiagrammComputeranimation
22:18
Schreib-Lese-KopfCodeTouchscreenComputerspielProjektive EbeneAusnahmebehandlungQuick-SortGeradeDifferenteKomponententestRechenwerkTypentheorieIterationParametersystemCASE <Informatik>ProgrammierungAttributierte GrammatikProfil <Aerodynamik>Komplex <Algebra>AggregatzustandSoftwaretestUnicodeZweiMaskierung <Informatik>Message-PassingZeichenkettePunktSuite <Programmpaket>IntegralFehlermeldungRückkopplungFlussdiagrammProgramm/Quellcode
25:30
ProgrammierungProgrammierungMultiplikationsoperatorProzess <Informatik>Einfach zusammenhängender RaumKomponententestVariableProfil <Aerodynamik>KontrollstrukturMehrrechnersystemQuick-SortProgrammbibliothekObjektorientierte ProgrammierungCodeTypentheorieZeichenketteWechselsprungKonfiguration <Informatik>AuswahlaxiomMonoidale KategorieProjektive EbeneGamecontrollerPunktRechter WinkelAggregatzustandProgrammiergerätFlussdiagrammJSON
27:35
TypentheorieZeichenketteEinfach zusammenhängender RaumObjektorientierte ProgrammierungQuick-SortReelle ZahlProgrammierungDatenfeldProgramm/QuellcodeComputeranimation
28:24
ProgrammierungRekursive FunktionOISCSkalarproduktCodeDatenbankAggregatzustandVerzeichnisdienstAnalysisZeichenketteProgrammierungQuick-SortDynamisches SystemPunktKorrelationsfunktionGRASS <Programm>EinsMathematikHilfesystemTypentheorieEndliche ModelltheorieKontrollstrukturBeweistheorieBitMultiplikationsoperatorDivergente ReiheResultanteSingularität <Mathematik>Objektorientierte ProgrammierungProdukt <Mathematik>Formale SpracheGraphMaschinenschreibenRechter WinkelRückkopplungVisualisierungSoundverarbeitungNatürliche ZahlAbstrakter SyntaxbaumProgrammiersprachePhysikalische TheorieSystemprogrammierungSkriptspracheTermersetzungssystemCompilerValiditätProzess <Informatik>RechnernetzReelle ZahlMultigraphProgramm/QuellcodeJSON
34:02
EmulationKategorie <Mathematik>KommandospracheMAPWeb SiteMaschinenschreibenSoftwaretestQuick-SortInformationMultiplikationsoperatorWechselsprungRechter WinkelSoundverarbeitungObjektorientierte ProgrammierungGüte der AnpassungJSONProgramm/Quellcode
35:36
MultiplikationsoperatorAggregatzustandFunktionale ProgrammierungWeb SiteKategorie <Mathematik>PunktRechter WinkelBitWeb logCodeQuick-SortSoundverarbeitungDivergente ReiheVideokonferenzFormale SpracheMereologieProgrammierspracheFahne <Mathematik>MaschinenschreibenEinsData MiningPerfekte GruppeProjektive EbeneSichtenkonzeptParametersystemJSONComputeranimation
37:49
PunktEinfach zusammenhängender RaumCodeQuick-SortMereologieFormale SpracheFlächeninhaltComputeranimation
38:30
BildschirmfensterMultiplikationsoperatorComputeranimation
39:10
CodeQuick-SortProjektive EbeneFormale SpracheComputeranimationFlussdiagramm
39:48
CodeBasis <Mathematik>Funktionale ProgrammierungElektronische PublikationSystemaufrufMomentenproblemCodeRechter WinkelQuick-SortKeller <Informatik>MAP
40:24
Quick-SortProgrammierungMAPFreewareFunktionale ProgrammierungMultiplikationsoperatorFormale SpracheBildschirmmaskeDatenflussCodeEinfach zusammenhängender RaumComputeranimationProgramm/QuellcodeXML
40:57
CodeVisualisierungQuick-SortPlastikkarteDreizehnComputeranimation
Transkript: Englisch(automatisch erzeugt)
00:04
We're good to go? All right, cool. All right, so we can, I guess, get started here. I guess it's 1.40 time to go. Before I start, they wanted me to mention, and I'll mention this at the end too, that if you liked the talk, you can leave ratings at the end.
00:21
If you didn't like the talk, then they can't force you. So keep that in mind as well. But we're here today to talk about live programming, and I guess I should preface this by also saying, live programming sort of has two distinct camps. There is sort of a group of people who do performance art programming, where they live
00:44
code music and beats and visuals in front of an audience. And then there's sort of those who use tools in their everyday work, and it's sort of a different camp of live programming, where they're getting instant feedback, something sort of similar to a REPL. And the latter is the type that we're going to talk about today.
01:00
So maybe I should get a feel for how many people in this room do .NET, so C sharp, F sharp, and how many people don't do any .NET at all? So one, one in the back. And that's great. Okay, so we'll get into this from sort of a .NET perspective, since pretty much everybody will be on board with that.
01:20
My name's Josh. I'm one half of a team of a company called Code Connect. We're based in Canada. We build developer tools, and we mostly use Roslyn to build developer tools for C sharp, so plugins to Visual Studio or websites that help you understand and interpret code. And our latest tool, and sort of the one I'll be talking about a little bit today,
01:43
is called Alive. And this is a live programming environment, and I'm going to go through sort of the history of live programming a little bit, some things that influenced our design here, and maybe some things that you guys would find interesting. So one thing I'll say is that, and I can't speak too openly about this yet, but Alive is a commercial tool, but don't buy it right now, because I can't tell you because
02:06
I'm sort of under NDA, but it will become a lot cheaper in about 30 days. So keep that in mind going forward. You can do a 30-day trial, so you can test it out after the talk. Normally I'd try and get you all to buy it, but today's a little different.
02:23
And I do a lot of work sort of with Roslyn. I have a blog called Learn Roslyn Now where I try and get other people using sort of the C sharp compiler platform, and I've been doing that for about, since 2012, sort of been working with the Roslyn project and doing a bunch of cool stuff there.
02:43
And you can find me on Twitter at This is Josh Vardy. So the world of programming can sort of been broken up into these two pieces. We've got edit time and we've got debug time or run time. And traditionally what this means is that at edit time, you know, you make all your changes to your code, you write some code, and then at debug time you actually see
03:01
what that code does. And for a lot of the time we sort of flip back and forth between these two modes. We make a change to our code and then we restart the world, see what's changed, see how our changes have influenced our program, see where we went wrong, and then correct it. And it's sort of this back and forth jumping between two worlds.
03:22
And live programming is sort of the idea that we want to reconcile this. We want to bring these two worlds back together and sort of merge edit time and debug time. So while we're editing our code, we're always debugging it and we're always seeing what's happening in our code as we write it. And a lot of this stuff has sort of been, I wouldn't say invented by, but like popularized
03:45
by this guy here. And this is Brett Victor. He worked at Apple for a long time doing some sort of UI research and he's done a lot of blog posts about learnable programming and ways to get more people into programming and understand programming.
04:01
A big problem with programming, he says, is this sort of disconnect between the really good programmers of the world today are sort of the ones who can look at this abstraction we've created that is source code and understand what it's going to do in their heads. And he sort of has the opinion that, you know, you've got a computer right in front of you. Why are you playing computer in your mind when maybe the computer should be doing this
04:24
for you? So a lot of his sort of research has been driven by these principles. And he's given a really good talk on building these tools and sort of creating sort of a destination to which live programming should sort of aim towards.
04:41
And we'll look at a few of his ideas. And we'll talk about them and we'll critique them and then we'll talk about how we sort of try to approach these ideas when building a live. So one of the things that he really believes in is that you should relate code to its final result. You can sort of see in this example here, no matter where he hovers, you get this instant
05:01
immediate connection to what's actually being created. So the final output of your program. If he toggles things and manipulates things, you get this great experience. This is a tool that I would say doesn't exist. It's a handcrafted illustration. But it's something that he thinks we should strive towards.
05:21
The second principle is that we should map time to space. So when you're looking at something like a for loop, that's operating over a period of time. But we can sort of break that down into discrete steps. And here we see that at each step, an operation occurs and a line is drawn on the screen. And sort of as we progress through this for loop, we can see how things are changing.
05:44
And this is sort of a powerful way about thinking about programming. It makes it easy to gain intuition about what the program does in just a matter of seconds without even reading a single line of code. You can sort of start to understand what's going on here.
06:00
And then finally he talks about how we should show state directly. So sort of building on the previous example, now instead of sort of having those dots at each step, we see not only what each iteration is doing, but what each line is doing, whether it's rotating some object or it's, you know, changing an angle or a color. You get this incredible experience here.
06:23
Now there's some problems with these ideas. Brett Victor provides sort of a vision for us to work towards, but he doesn't offer us much on how to get there. And building such tools turns out to be very difficult in practice because code is not always as simple as what was shown there, and it's not always mapping to sort of these 2D outputs.
06:44
So some of the problems with his thoughts on this. You know, this isn't real world code. Real world code is not always nicely self-contained at 80 characters wide. It's not mapping nicely to 2D outputs, so it doesn't give you this visual experience.
07:00
You know, one of the things he said was that you should always map code to its final output, but how do you do that when you're writing something like a compiler or you're writing sort of a database or, you know, some kind of abstraction? It doesn't always map nicely to something visual for us to easily understand. And sort of building on this, you know, this is what real world code actually looks
07:24
like sometimes. It's this giant mess. This wasn't created for the purposes of this demonstration. An individual on a mailing list sort of posted this as sort of a problem that he was facing. And even sort of Visual Studio's tools break down sometimes when dealing with code of this nature.
07:44
And the reality is when you build a tool like this, you have to consider what happens when someone's line is, you know, a thousand characters wide or has hundreds of variables. These are the real world problems that aren't fun or interesting to think about. They're painful and they're annoying and they suck to think about, but you have to solve
08:02
these in order to give something useful in your final tool. So another problem is that performance matters. You'll notice that every time he made a change or tweaked a value, he got this instant feedback, this instant update. But what happens if, you know, you've got this loop that's running a million times
08:21
and it's making network calls? Well, there's no way around the fact that you can only have your tool be as fast as the code itself is running. And this is sort of something that's glossed over a little bit in the live programming community and sort of prevents live programming from being this sort of fix-all solution
08:40
to some of the problems that we face as developers. Performance also matters in another respect. If you look at projects like Roslyn itself, this is sort of the, I guess, the by-the-numbers look at Roslyn. It's 151 projects big. It's almost 4 million lines of code now.
09:01
And when you make a change to a project like that, it doesn't compile instantly. Other projects like ReSharper are also of similar size and there's all kinds of performance problems that you run into when you try and make changes to a project like that. So you're not going to get this instant feedback without a little bit of effort, at least.
09:20
And we'll talk about some of the ways that we tried our best to sort of get there so a live can run on projects the size of Roslyn. So let's take a look at a live, and this is sort of our take on live programming. I'll just jump out here to Visual Studio. And what we'll do is we'll do something we're all sort of familiar with and we'll parse
09:43
just a CSV, like I've got it loaded here with a name, age, country, company, and we'll just sort of parse this up into a list of people objects that represent this. And there might be some mistakes in our data, there might be some issues, and we'll sort of find those out as we go. So here I've got just a path to our CSV there.
10:03
I've got a stream reader here, and you can see if I just click this play button, we sort of start to instantly get some insight into what's going on in our project. We can see if we hover over here, we've got... This is our data that we're working with. Our lines have been split, although it looks like there might be an issue there.
10:22
We're splitting on new lines, and there's some issues with the... It looks like a slash R slash N or something like that. And what we can do is we can sort of start to go through here and look at what it would be like to build such a program with live programming. So what we'll do is we'll go over each line, and we'll see that once we sort of write
10:45
this loop, we have... We've essentially mapped time to space. So here we've got this for loop, and we can slide through and see what's happening at each individual state in our program. And we can sort of find edge cases like here, our very first line is the name, age, country
11:03
and company. We probably don't want to include that in our results, so what we'll do is we'll just skip it, and we can see, okay, we fixed that bug the moment we wrote it. We didn't have to wait until we ran our program for the first time. We just instantly see the problems that we're running into, and we can fix them as we go. Another issue, like I mentioned before, is there's this sort of extra new line here.
11:23
So maybe we want to just clean up this line, trim, and we can see... Okay, that looks a little better. Before we had that extra new line, now that's fixed. So let's start sort of creating instances of our people and start working with our
11:40
data here. So we'll just split this line based on the comma, and we can look at and see that we've... Okay, we've got our groups of objects now, or our groups of strings. However, there's this empty one at the end, and that's probably caused, if I jump
12:00
back here and check, yeah, there's extra commas at the end of our data here. This was data I just generated with a tool, so I guess when the tool builds this data, that's something that I guess it just sticks in there at the end of every line. So what we can do is we can... If you remember all your overloads for this, you can go new char, and we can tell it
12:22
to string split options, remove empty entries. And I'm missing that. Okay, so now we've cleaned that up, we've gotten rid of our extra entries, and we can now start sort of breaking this apart into all its component pieces.
12:42
So split line 0, I think name was first. We can check that. Yeah, name was the first one, var age, I think was the next. Split line 1. We've got instant feedback there. We probably want to turn this into an actual integer, so we'll just do that quickly.
13:06
And we'll just quickly do our last two. So country, split line 2, var company, I think was the last one. Split line 3.
13:20
Great. So now we can just double check our work. We've got the name, age, country, company. That's perfect. I've just got this little DTO, this little object down here that will stick these in, so var person is equal to new person. And we'll just pass in name, age, country, company.
13:40
Perfect. And then maybe we just want to save these all in a list somewhere now. Var list of people. And this needs to be static.
14:01
Whoops. Perfect. So now we'll just build up our list here, and I think everything should be good. Add our people to it. And now there's a little warning here. This icon, we haven't talked much about it, but after clicking it at the start here,
14:22
we've got sort of this, I guess there's syntax errors, I don't believe that. Maybe it's... I thought there was an actual error. Maybe it's just broken right now. Oh, there we go. So there's some kind of index out of range exception. So we can see that this code looks like it should work, but somewhere it's failing.
14:42
So we can sort of just scrub through here. I mean, if it got to the last iteration, it must have failed there. And it looks like there was maybe an empty line or something. Yeah, there was an empty line, I guess, at the end of our program here. So we catch these bugs the moment we write them, just with this tool that I guess built
15:02
some questionable data for us. But we can see these things the moment we encounter them. We don't have to wait until we encounter sort of... We run it for the first time and find out our assumptions were wrong. We can come in here, we can say... Okay. I guess if the line is empty, then we don't care.
15:20
So this is kind of a quick hack, but if split line string is null or white space, continue. So we'll just ignore that. And then it runs, and this time it looks like it worked. So we can see that it didn't encounter any errors.
15:43
It chugged through our data. Everything's perfect. And one thing to notice here, too, and you can't really... I can't tell if you guys can see it there. Yeah, you kind of can. The lines that don't run are just grayed out here. So we know that when we do these iterations, this particular case didn't run, and we just
16:00
sort of get this instant feedback, where we're seeing what's going on. And you can sort of just implicitly understand where your edge cases are, where conditions are changing, just by sort of visually scrubbing through these things. This is the basic intro to Alive. We'll get into a few more features in a demo here, when we work with NuneSoft JSON.
16:20
But let's jump back to our presentation here and talk a little bit about where we are and maybe how we didn't reach Brett Victor's goals and maybe how we can get there. So one thing that you might find interesting is wondering, how does this work? So how are we doing this? Are we running the process, like inspecting memory?
16:41
What kind of approaches are taken here? Well, what we're doing is we're... And this is the simplest case, is essentially we're rewriting this code here to what's on the right. And we use Roslyn very heavily to do this. And you can see what's essentially happening is this little method is being rewritten such that it's logging, in this example, all of the assignments.
17:01
And it just, you know, creates this... It just calls this sort of this method that we inject in here, this log value that can take any type and will return that type unchanged. And then it creates a little result for it that has the name and the value, just the toString of that object. So you're not getting sort of your deep drill down at this point.
17:22
But you're getting the basic information about what your program's doing and what's going on. And then we just sort of save that in results. And obviously this isn't the full story of what's going on. You need things like line numbers. You need to think about, well, if statements and for loops and recursion and all these little things you can run into.
17:40
But this is the basic principle behind alive. We rewrite your source code to keep track of what's going on, and then we can sort of play that back for you once it's run. And like I mentioned, we use Roslyn very heavily to do this. Roslyn, for those... Has anyone... So who here is familiar with Roslyn? Like, who here has written something that's consumed?
18:02
Yeah, yeah. Imagine someone who works on Roslyn is familiar with Roslyn. So not too many. So Roslyn is sort of this catch-all name for a bunch of things. It's the C-sharp compiler, but it's also the language services like colorization and IntelliSense that you have in Visual Studio.
18:24
And it was essentially a ground-up rewrite of the old C++ compiler that also, while they were writing it in C-sharp, they exposed all of this functionality to people like myself, people who work on other projects like OmniSharp, ScriptCS, that allow us
18:42
to build these powerful tools while having parity right with the Visual Studio compiler. What ships in Visual Studio 2015. One thing that's really nice about that is we get to save on a lot of compilation effort, because we're sort of reusing a lot of the compilation information that
19:01
Visual Studio already has to calculate when you want to go to definition or when it's colorizing files and all these sorts of things. So Roslyn was definitely key in making this performant and making it possible at all, because before Roslyn, you'd have to do what JetBrains did and hire a team of extremely talented engineers and make them write your own C-sharp compiler
19:24
and figure out what bugs the original C-sharp compiler had and match them and all these awful things. And two guys in Canada aren't going to be able to do that. So in terms of performance, what kind of gains or what kind of things had to be taken into account here when building this?
19:42
Well, there's no fancy tricks. If you look at a paper published, I think it was by Bill Childs on the Roslyn team. He talks about some of the methods they took to minimize garbage collections and all these issues that they run into when trying to give you like IntelliSense
20:02
in a tenth of a second and stuff. We didn't have to worry about that. The real bottlenecks here are number one, the time it takes to run their users code. There's nothing we can do about that. We can't make their code any faster. And number two, the time it takes to do compilation. And I guess maybe I shouldn't say no fancy tricks
20:22
because there's one fancy trick that we'll get into in a second. But there really isn't any like crazy garbage collection tuning. We're not rewriting async to be faster and any of those sorts of things. One rule we have is we try not to hit disk. So if you have a project that's changing all the time, you don't want to compile that and send that to disk.
20:42
If you're just about to load that back up into memory so you can run it. Roslyn allows you just to emit to memory. Makes things a lot easier on us. And then sort of I guess the one trick that's not in alive today but will be in I'd say within 30 days is that we've recently started to take advantage of the edit and continue API.
21:03
So we've actually kind of glossed over that. We in the C sharp and dot net world are kind of spoiled because we have this CLR, this VM where they did a ton of work to get it. So you can actually do sort of live programming with editing continue.
21:21
You can pause your program, you can change it, you can break your program whenever you want and change it and resume. And we've started to take advantage of that in a lot. So in order to make a live work on a project like Roslyn, what you do is you don't recompile and emit the whole project. You only recompile and emit like that one method that changed.
21:41
Which obviously saves you an incredible amount of time and gets our compilation cycle into something like less than 100 milliseconds. So that's actually not in alive today. So it will be slow if you use it on something like Roslyn and it will be slow the first compilation anyways because it has to do the initial emit phase
22:02
and compile a project of 151 CS proj size. So let's just jump to the next one here. One thing we'll do now is we'll look at one more sort of use case for alive. And I'll just jump back to Newtonsoft JSON here.
22:26
And we'll sort of, you know, before it was sort of like, I wouldn't say canned demo. I hadn't done it before, but it was a pretty simple use case. We were running main. What happens when we want to run more complex projects, like things that have state methods that take parameters?
22:41
What kind of issues or how do we solve these kinds of problems when we come up against them? So one thing that we've done is we've made it so alive integrates with x unit, n unit and ms test. So anywhere you see like a test attribute, you can just come in here and fire alive up. It'll compile and run this project. It's not that big. It's I think 35,000 lines of code,
23:02
but it takes a second or two to compile and show you what's going on. But then, you know, from here, what if we want to start, you know, digging into some of these other methods, like what's going on in this JSON convert to string? We don't know what that is. Well, we can just jump there and we can click this little continue button.
23:21
So what will happen is that original method that we saw, and I'll actually keep it on the screen. This original method on the left here is still being invoked, but we're going to rewrite and profile the code on the right side here so we can see what's actually going on in a different piece of code. And we can sort of do this and, you know,
23:40
we can see what happens like when we come in here and we like, I don't know, like step on values in bad ways. I'm guessing errors start to happen. So now we can see there's some assert exception because we broke this unit test and we sort of get this live feedback. I guess in a sense, if you've ever used ncrunch, it's kind of like a more smaller version of that.
24:03
We're just running one test instead of sort of your whole test suite. But it makes it very easy to just jump around here. So now we can like go, let's see. So this code ran. Let's see what happens in here if anything interesting is going on. So right escape.
24:21
Yeah, this looks a little more interesting. So we can just continue. This original method on the left side here is still the one that's being invoked, but now we're going to sort of probe into what's going on a little deeper down inside here. And we can come in here and we can see like they're passing in this weird Unicode string. What happens at each iteration?
24:41
Well, we can just jump through here and see. Does anything interesting happen here? Like I guess different cases are getting run. And we can see it looks like it handles odd escaped braces in a special way when it's parsing JSON. And these are all things that you would expect if you use Newton soft JSON. But the point here is that any piece of code that's covered by a unit test that you've written
25:03
or a static method that you've written is very simple. You know, a type that we can create, for example. Well, we can come in and we can run that for you. We can show you what's going on inside of that. And this is sort of the way that we program now.
25:22
We write our unit tests and then we go through and we test all these things out in a sort of program like this. So let's jump back. So now we have to talk about some problems with live programming.
25:41
We started this project about a year ago, May of 2015. And when you start a new project, you kind of have, you know, you walk in with bright eyes and you think like, you know, this is going to solve everything. And then you sort of get hit in the face with the reality of, you know, code that your customers are writing or libraries that they're using or complex build processes
26:03
that they have and these sorts of things. And these are all project problems with live programming that I think the live programming community doesn't really consider. So the people who build these types of tools sometimes don't consider. One big problem is how do we fake state? So, you know, we've got a method here.
26:22
It takes a string and some claims identity object. We don't know how to build this thing. We can't really put whatever we want in this string and just hope it works because if it's like a connection string, it obviously has to be valid. So how do we fake these sorts of things? There's not really a good answer for this right now.
26:41
I would say, one, you can do what we do with unit tests and solve it that way. Alternatively, one thing we've considered is every time you hit a break point, maybe we like profile the world and we see what are the values of all your variables. And we can sort of build up this understanding of your code that maybe we could start to
27:05
fake what goes in your connection string because every time we saw it, it was the same value or something like that. Or we could build this object because it's always the same type of object or we can provide you with a choice of options to put in there. The other option that we have, and I guess I'll jump back to alive and show it to
27:44
you in a little bit, is we can let you put it in manually. So you can come in here and you can put in my
28:01
real connection string or whatever it's gonna be. And that comes in and we fake it for you that way. But that's obviously not a satisfactory solution when the object that you're putting in has 50 fields and you really don't wanna type that out. I'd say live programming completely fails you when you run into that sort of situation.
28:23
But these are things that we work on and we do research on. And there is a live programming community and we sort of challenge them sometimes. Like how are you guys solving this? And a lot of them don't really have good solutions. And that's just the reality of where sort of the research is today.
28:40
Where we would go with this in the future is I think we would start looking at probing with breakpoints and seeing what's happening when your program is running and being a little bit more involved there. So that leads to a second problem. What if you choose the wrong values and there are side effects? So like what if you think, oh, we can put C slash system 32 in this string
29:05
because it came here one time before. And then it gets routed to directory dot delete or something like that. I mean, these are the problems that you don't want to... You're running your customer's code all the time. You don't wanna run it when it deletes things or they update a database
29:21
and every time they were pressing a keystroke and a valid C sharp program was there, we added entries into their database over and over and over again. These are real problems and they're not fun problems to think about and they don't have clean solutions. And to be honest, the solution that we've done so far has been,
29:40
let's do it and see if anyone yells at us. And we haven't got sued yet and no one's complained that we've broken their things. We try and make it very clear that when we run your code, we run it for real. It's not like a static analysis. I guess you would consider it dynamic analysis or something like that. We're actually running the code.
30:00
If you're doing things in the real world, you will see the results of those things. And this has been something that keeps us up a little bit. Another problem with live programming, or at least a state of alive maybe, maybe I should say problem with alive, is that it's not intelligent enough. It hasn't delivered on this promise that Brett Victor and live programming showed us.
30:30
It's not a panacea. It doesn't fix all the problems that I face in my day-to-day. There are times when alive is not the right tool for the job. And some of that we can fix and some of that I think is just the reality of
30:42
the nature of either today's programming languages or programming in general maybe. A lot of the people who believe in programming or live programming believe that, well, if you have this problem with state, then maybe these...
31:00
And it's slow or something like that. Maybe this tear the world down programming such that, like when your program ends or something like that, all state is destroyed. Maybe that's the wrong model and they propose that, no, we should just reinvent programming from the ground up to suit these purposes. I'm not convinced that there's enough benefit there from live programming to advocate such a big change.
31:23
You're gonna need at least 10 times improvement in productivity to get someone to use a brand new programming language with their brand new tools and all that stuff. And live programming, I sell tools for it. It doesn't get us there. And that's just the reality of it today. But there are things here that we can improve.
31:41
We can maybe do better visualizations and improve things. Right now we're just doing two-string. And we'll have to... Sort of the what's next and sort of how we can improve alive and maybe make things a little better and more intelligent. So one thing we've thought a lot about is maybe custom adornments.
32:00
Maybe we allow customers or a community to extend alive such that we provide an entry point and whenever we see objects of type.stock.data series or something like that, then we handle them differently. We don't just call .toString on them. We build a WPF visual graph or something and we can show it there.
32:21
And then when they tweak the data, you just get this sort of instant feedback. Obviously, once again, you start to run into performance problems when you're doing analysis over stock data that's 20 years old and there's thousands of stock ticks and stuff like that. And that's just the reality of dealing with this sort of stuff. So we're not sold on whether or not we'll go there yet,
32:42
but that's something that we've considered strongly. Because even just little graphs would be nice often when you're trying to find correlations in data and these sorts of things. The other sort of speculative next step is broader language support. So a lot of people see this and they say, well, I'm lucky to be surrounded by C sharp
33:04
devs or dot net devs, but they say I want it for Python or Ruby or JavaScript and TypeScript. And there's only two of us now. We hired an intern over the fall and he did do research into supporting it with TypeScript. So TypeScript, as you may know, is the new sort of essentially takes your TypeScript
33:25
code and it compiles it down to JavaScript. Well, you can in theory take that TypeScript compiler and modify it to do those same syntax tree rewrites that we were doing earlier. And our intern sort of came up with this proof of concept.
33:41
It's not as nice as working with Roslyn, because they built Roslyn to support the rewriting. They didn't build TypeScript to support that just yet. So we're gonna have to see where that goes, but JavaScript and TypeScript will be the next languages if we choose to support them.
34:00
One more little thing I'll get into is sort of what we're doing with what's next. We'll talk about some of the future steps of the live here. One thing we didn't touch on was the fact that... Stop this. So I mentioned that there's no drill down in a live.
34:22
That's not completely true. We actually support first level drill down. So like this person object, we actually go one step deeper and you can decompose it into these properties. You start to run into issues, though. Like... And we haven't had any problems with it yet, but what happens if every time you get this
34:44
property, it has side effects or something like that? It increments a value or something like that. Right now, we haven't solved that problem, and we're waiting for people to complain about it. So if you use a live and it has problems like that for you, we have a GitHub issue
35:01
tracker where you can come and yell at us about these sorts of things. So let me just jump back here. So I'm a little early, but we'll jump to the end here. If you want more information on a live, you want to sort of test it out yourself, there's a 30 day trial, and the price will be vastly reduced, probably after your
35:24
30 day trial. And you can just get that all at... Oh, is it not up there? Let me try that again. Comealive.io is the website. Let me... There we go. Perfect. So comealive.io is our website.
35:41
If you want to follow up with Brett Victor and see some of the stuff that he's doing, he's sort of the person I would say sort of has the most optimistic view about all this stuff, and is the big dreamer, where we're a little down in the weeds, trying to make it work with programming languages of today. But he's got some fantastic blog posts on this sort of stuff.
36:02
If you want to learn about it. And then finally, if you want to learn about Roslyn, we didn't talk about Roslyn too much today, but I have... You know what? I think it's like 15 part blog series and 10 part video series on how to use Roslyn to build these kinds of tools. So if you're wanting to build a tool and you want to know, is it possible to build
36:22
this with Roslyn, just come and ask me now. I'd love to chat about it. Or you can ask if you have any questions now. I guess I should take questions and see if anyone has any. Yes.
36:43
Yeah. So the question was, how would this approach work with a functional programming language? It would probably work better. You know, when you... I haven't used F sharp too much, but from what I understand, the side effect of sort
37:01
of having immutability first is that you have less state to worry about, or at least less global state, which means if you can kick off a certain function, then you can be relatively happy that everything is going to work correctly. One thing I didn't touch on is in languages like C sharp, there's global state to worry about. So even if we provide the right parameters to our method, if some static property has
37:25
to be set with some special flag or value ahead of time, well, no one's doing that, because we're just running this method from the middle of their code. We didn't run whatever proper pipeline was supposed to be invoked here. So I think with functional languages, it would work better.
37:42
Maybe since I have a little bit of time, I'll show you another project of mine very quickly, where it also would have worked better with functional languages, but we haven't got to the point where we can build tools for those yet. Part of the reason is Roslyn makes our lives so much easier, and if there's not a Roslyn for F sharp or a Roslyn for Scala or whatever language, it's really tough
38:06
on us to build these sorts of things. I'll show you our first tool. We built it two years ago, and it was called Code Connect. And it was sort of... It was built with Roslyn as well. Oh, it's not on again. Look at that.
38:21
PowerPoint wants to do that to me for some reason. No, there we don't go. Let's try one more time. Duplicate.
38:46
Come on, you can do it. Or all of Windows might have hung. Yeah, that's beautiful. Oh, the mouse is moving again. Let me just try unplugging really quick.
39:07
I'll just try extending one more time. There we go. We're back. Okay. So we built this original tool that sort of lent itself... It turned out... We built this tool sort of as research.
39:21
We wanted to say... We just graduated school. We built this as a fourth year design project. Can we make a company that sells tools? We couldn't make a company that sold this tool. It turns out it's not useful enough for languages like C sharp, but might be more useful for languages like F sharp.
39:40
And we'll skip through my talking here, because there's no sound as far as I know. And we'll see that what this tool did was... It showed you... Instead of showing code on a file by file basis, we showed you code on a function by function basis. So you work on one single function. And to the right of that are all the functions that it calls.
40:02
And as you navigate around, you'll see the functions that they call. And you have this very interactive experience, where you're walking up and down the call stack. And the moment you change code and remove code, the world updates. And there's a few ideas bubbling in the back of my mind. What happens if you combine something like a live with a tool like this?
40:23
Well, now you see... Okay, we started here, and you see the values at every stage and every method of your program. And that seems like it'd be something that might be a powerful way to think about debugging or figuring these sorts of things out. But back to your original question about functional languages. This was not very useful for languages like C sharp,
40:41
because a lot of times you want a free form canvas, almost, to just throw in new methods here, that sort of thing. But with functional languages, it might be more of a directed flow, like the data seems to flow through these programs a little better. But that's Code Connect. This is also available, but not actively developed.
41:03
It's there for Visual Studio 2015. I should mention that alive is available for both 2013 and 2015. We had to do a lot of work to ship Roslyn backwards. And the other people on the team sort of frowned upon this when we were doing it.
41:21
But we did the work, and we got Roslyn sort of running in Visual Studio 2013. So you can use alive there as well. If there's no other questions, then I'd just say, don't forget to do the review at the end here. And if you have any questions, or if you want one of my stickers or a card,
41:43
come up and grab one. You can chat or something like that. Awesome. Thank you.