Grand Unification Theory: Writing and Running Code, by Brian Ford

so it's uh it's very good to be back in barcelona i actually got this is the only city in europe that i've been to twice i haven't been to that many cities but beautiful city very happy to be here i want to thank um the organizers choose and everybody else from uh from the organizers of baruco beautiful city beautiful place to be and uh also thanks to uh all of you for being here and the other speakers so i work at engine yard on rabinius i started working on robinius late 2006 and started working with engine yard in january of 2008 and as a company i think they've done more for ruby and rails than than many companies have done for any language so i'm very very happy to work there basically what i want to talk to you about today is uh this idea uh when you look around at how you write code how other people write code um not much has changed in decades and i would like to do something about that so if we look at like these are the things that we kind of we have right if we're going to write code we have debuggers we can we can profile our code we can see where you know what code is running where we might look at like for our total code base what the coverage is if you use a statically typed language then you have this little theorem prover that you know checks your type stuff is correct and we have an editor right these things largely are unchanged for like decades so there is one language though that uh does things a little bit differently uh small talk you may have heard of it um and basically any time you start talking about code someone will say well small talk did this right so the fact that small talk already invented everything and we're not using small talk probably means that either small talk didn't actually invent everything or we just suck right you can decide which one of those it is in small talk writing code is sort of a function of running code so your system is running and your editor is part of the system that's running so you can like write some code and like change how your editor works so it's it's a very interesting system but the total experience of writing code is is largely not that different than when you're writing a ruby or something else we have this editor and our editors are basically like you know we we talked there's like a slime is that the new new big thing the new hotness like textmate was going to be for a long time and textmate 2 took forever so then people actually started using vim and emacs again which they've been using like decades before that and then you know so that like editors it's just this thing that it's like it's like a really good photographer or something you know it's like not taking like a picture of something it's just like pointing pixels here and there you know it's like that level of sophistication in in in language like so in english this is a perfectly grammatical sentence that is absolutely meaningless right it means nothing and yet you can actually sort of if i say this board swam wistfully through the narrow sky you can actually like sort of create some image that goes with it but it's absolutely meaningless it's like writing a program that type checks and everything and then just sits there and like like zed was saying doesn't halt right so uh our editors and the way that we write code it's basically about the level of sophistication of a spell checker right and if you've if you've ever been typing on your iphone right and you have a spell checker and autocorrect right it works so well right there's whole sites dedicated to like the the hilarity that ensues from like autocorrect you know getting in the way and that's about the level we're at in writing code right so writing code right writing code we the the word that we basically use is programming right so so what are we doing when we're programming we talk about all these things you know like zed's talk was just fantastic for me i think because i i love to see where people start to build up this beautiful structure in the sky about how important lake yankee says category theory is or test first development and you start worshiping at this thing and like he says your brain just goes off right you're no longer like critically thinking you're no longer questioning is that really helpful is that something that we need so you know patterns you know like there's always something new to like help you protect against you know some terrible thing that you probably haven't actually asked whether it's that terrible what's gonna happen if you don't do it so nothing is wrong with any of these things but are they what we're actually doing when we're programming are they the most important thing that we're doing we hear something like this so someone will say good design communicates in tension everybody like nods like yeah intention and when you look at the ordering of the concepts here good design comes before communicates but if we were to try to break down what those things mean good design is this very nebulous and difficult to describe thing but there's another word in here that i think is a lot more concrete then we can actually look at what makes up that word and that's the word communicate i think that when we talk about programming when we talk about writing code the most important thing that we're doing is we're communicating and the definition here these you know this definition just comes from the apple um dictionary on my computer but you know you can look in a big dictionary something that's going to be very simple it's uh imparting or exchanging information there's a lot implicit in that definition right so if you're going to impart or exchange it suggests that there's an actor it suggests that there's somebody who's receiving i mean you could i guess you could impart information to yourself but that's kind of hard to to think about right because if you didn't know it before you told yourself about it then yeah so so there's probably two two people there when we're programming uh we have the computer we have something that's running our program but we also have our later selves and that's that's something that you could actually communicate with your later so if you come back to that code a week later and you're like who wrote this you go get blame you're like oh i did or other programmers other people that are going to read our code so the idea the fundamental sort of idea i think that what we're doing when we're programming is we're actually communicating that's that's the thing and i didn't i didn't make this up kent beck actually has a book that started out as small talk best practice patterns and it was rewritten uh as this book implementation patterns and the rumor is that he's going to write one that's more focused on ruby instead of java like this one but basically the idea is that you're communicating when you're writing when you're writing software the other thing is that the software that we write almost every piece of software we write ends up itself being an artifact for communicating so if you make a website right for booking travel then some other person comes to the computer and they're using your website to try to communicate with you know the system or if you're like sending an instant message to somebody you're using the software to communicate and things that that system does may either enhance or impair that communication right like typing you know a message to your girlfriend and autocorrects and uses the wrong word and you're like oh you know that sort of thing so again communication is central so if communication is central how do we look at communication how do we break it down how do we figure out how we can communicate better these are things that i've sort of just pulled together i don't have like a source for this but i'm sure there's people who've done studies on communication that would be helpful if you go look them but these are the things that i find most important for communicating first off being clear which simply means not being confusing right not being ambiguous so if something is an x then it should be an x and not be um you shouldn't have a question in your mind or is that the x or is it a why that sort of thing that's just simple obvious or unambiguous simple it often goes with clear but they don't mean exactly the same thing if you've seen uh rich hickeys talk about simple versus complex right in in this this sense we're talking sort of that way that it's it's not complicated it's not too many things that come together there's one thing or there's two things and i think this particular one is very important so is it relevant you could be very clear and you can be you know very simple and you could be talking about politics instead of like programming language or something like that right so it really needs to be relevant to be a good communication and precise right which is simply this idea that um if there's a distinction to be made right if there's a line to be drawn somewhere that you do that as as closely as you can to the the concept that you're talking about another idea in communication is how you're doing it right now i'm talking to you but i could have written this out and you could all be just sitting there reading a blog post or something right so the way that the message comes to you right the medium is uh is a part of the communication and it can impact whether communication is good or not and then there's things that start to like go sort of away from all that stuff previous is a little bit mechanical right it doesn't it doesn't like um it doesn't necessarily involve a person you could use those those criteria for good communication and see how well two computers are talking to each other right potentially but when we get into more human factors there's this idea of tone tone can can have a very large impact on uh communication if someone you know if you you walk in and you're like hey how's it going in the morning to your co-worker and they're like they just grunt at you or something i mean they acknowledged you the communication was pretty clear but the tone you're probably not going to be like oh by the way i had a problem with your code because they don't seem like they're in a good mood so so tone is something that non-verbally i i don't want to make it too like human center but basically tone can affect how the message comes across and then or not something is intimidating or um threatening like if you um if if the message that you want to convey is too aggressive perhaps then people are going to react to that in a way that they're not even dealing with your message they're just dealing with the way that it's that's coming to them but this isn't just for people either if you watch people interact especially people who are not particularly technical if you watch them interact with computers they're often very reluctant to try something because they're afraid it's going to break and they're probably going to blame themselves if it breaks right if they do something and the computer like fails they're like oh i did that wrong it's not necessarily that they did anything wrong the computer could be completely screwed up but there's that that tendency to blame themselves so that whether something is safe or not can impact how willing someone is to to try something uh and then i think this is another thing that's very important for communication um whether someone is open to what you're saying if someone is very defensive they're they're going to be thinking about every possible way to tell you that you're wrong about what you're saying instead of hearing what you're saying right so that's something else that's very human but it can affect communication and i i think that um that it's one of the factors of good communication that is not often appreciated right like you can just be talking if you see two people in an argument you're like how much are they communicating and how much are they just sort of protecting against actually getting the message right so those are some those are some things about how communication uh how we can analyze communication how we can see how how good communication is the one that's very interesting to me from the standpoint of changing how we write and run software is the idea of the programming language itself so the choice of programming language the programming language when we look at those factors of communication the programming language itself is not just um it's not just something that we're using it's it's actually the the medium that we're that we're conveying meaning with right it's not just that it's not just the arrangement of symbols it's more than that it's the it's the thing that carries the communication right so the choice of programming language whether it's python or ruby or haskell or closure or something like that it's not just the syntax and the grammar the way you have to put things together and whether you can use a you know a string that's immutable or a string that's mutable it's actually the whole body that's carrying that that meaning and it's going to imply things about how how well we can communicate one of the biggest in my experience one of the biggest um debates in programming like if you talk to different people it's like do you use a statically typed language or dynamically type language right so the emphasis being on typed here so here's a definition of type this it's a category of things that have common characteristics right but if we if we take a look at ruby um where's the type in this right there's no there's no type here what we're doing is we're dynamically setting a constant so the fact that we can set a constant at runtime instead of like you know before it it implies runtime versus writing code time right which we don't have a good word for um authoring code something like that it's dynamic but it doesn't really have anything to do with typing right or this right the instance variable b right there i'm defining a singleton method so i'm adding an instance variable to this particular object again it's dynamic but it doesn't and it doesn't necessarily imply anything about a type the fact that i'm changing the singleton method on this object a means that a is no longer going to be quite like other objects even if it's of the same class but the fact that the instance variable can be created dynamically doesn't again really have anything to do with types and uh if i do this right if i create a new class at runtime this is closer to type but it's there's not actually i just really have an object that i sent a message to right i just asked for a new thing the thing happened to be a class that i'm asking for a new one so um that last slide it's a little bit of meta programming right the idea of like uh not the language itself like you know just deaf class whatever but the idea of sort of talking about the language that you use to define your program right this idea of meta programming is often seen as something apart something that you can do in ruby but you can't do in something else it's basically again you know just sending a message to an object right so meta programming is not really that different i think just focusing on this idea of computing values right by using these little objects or values i took the word object out of there to try to keep it a little bit away from object oriented programming basically just computing by having these values that you send messages to is i think a more uh important way to look at programming than getting too wrapped up in types right so i want to take that type out and we're just going to talk about a dynamic language and the implications of just using a dynamic language something that can change its form or structure over time and we'll leave the whole typing debate to people who just want to argue right so my assertion is that dynamic language actually communicates better based on those those things that we looked at before the the characteristics of good communication if i have something like this right um it's quite simple right because each element of this right is relevant to it like i don't i don't really care what type of thing x is i only care that it has some behavior called y right it's clear there's no there's no way to sort of confuse what x dot y is with other parts of it um it's relevant right what i'm saying is i have a collection of things i want to visit each one and i want to ask for this particular value to be computed whatever y computes right and it works just fine if you have a heterogeneous array like this right it doesn't it doesn't have to be all of one type there's nothing that adding you know x is a you know integer and only integers can you know function here there's nothing that that adding that additional level of specificity really helps me understand this code any better right one of the things that we get sort of wrapped up in in this whole static statically type versus dynamically type thing is this idea of correctness uh or safety rather it's like well you want your program to crash at runtime you know it's like oh my god what's going to happen this program is going to crash um the confusion there is often correctness versus safety ruby if it raises a no method error it's not really any less uh safe right the computer is not going to be in a in a state that it can't recover from but the program program's not really correct unless what you're trying to do is raise a no method there right so we can have very safe uh programs in ruby that are not statically typed but they may not be correct and you can have completely safe programs in aesthetically type language but they might not be correct and what i'm more worried about is correctness than safety right okay so writing code communicating that's the central activity right i think what we're doing when we're writing when we're writing code what about when we run code like uh every time you run a program it's not necessarily the same the same context i guess right these are different reasons why you might run your program you might just be like in irb or some other repel testing stuff out you just want to see what happens right or you could actually be running all the tests for your program the sort of feedback that you get if you're just doing some exploratory programming might be a lot different than you care about when you're testing right you don't necessarily want to know what particular thing ran when you're when you're testing you want to know did everything pass if it failed if there's some failure can i get to the code and the test very easily when you're when you're doing exploratory programming you might want a lot of like output you might want to see like the whole structure of the object that you're playing with stuff like that right you might be running code in development you might have you know rails up and it's got the great like dev mode where you change one file and you go do something and you don't have to like communicate okay now reload this sort of thing it takes care of that for you so you're running in development again you have like different uh output that you want different way that you want to communicate with that um and then you know it might be actually in production right so that might be another way that you're writing code or you might actually be learning so the difference between that exploratory and learning is that you might be following exercises you don't know anything about this programming language you're just beginning and how you run the code at that point um you might want different uh feedback from the computer then then you would get if you're just doing like deploying the program just go over there run all i want to know is that is that server alive that sort of thing so we tend to lump everything together it's like uh running code it's just like you know there's no difference in how i sort of execute ruby under all these conditions right i would just be like ruby whatever script it does there's like no no additional like context or anything it's just like it's all running and i think that's that's something to think about is there is there a reason why we're running code and we just sort of run it all the same way so this project that i work on rubinius right it's an implementation of ruby if you don't know anything about rubinius which i i'm hoping is pretty rare please talk to me i'm not going to go into a lot of stuff about rubiness here's three reasons why you should use rubinicus or you should try using it we have a precise garbage collector it's a pretty good garbage collector might not be as good as the one in the jvm you know yet that sort of thing but it's far better than mris it's precise we know every object that is an object so we don't scan huge stacks of stuff saying are you an object i'm not sure okay i'll pretend you are maybe that sort of thing it's a precise garbage collector and uh we typically see like five to ten percent of time spent in garbage collection which is more than we want but it's still far far lower than i think you see an mri we have true concurrency or however you want to describe this so where there's no global interpreter lock right so if you spin up two threads they can both run ruby if you have two cores they can run it simultaneously right in parallel and we have a just-in-time compiler so the bytecode virtual machine chugs along and at some point your code gets hot enough and it says you know what this is this is used a lot let's generate machine code directly and uh so we do type type feedback you know we sort of keep track of how everything is actually running so these are reasons why you might want to use rabines for the purpose here i i want to talk about some of the stuff that we have in robinius that i think we can use to build some tools that are going to help us um achieve changing the way we we write and run code in urbinius uh if you like if you go into mri and you do def whatever that last line where you see rubinius compiled code you would just get nil back right mri you define a method and it says okay thank you very much and you get nil back in robinius what you get is an actual object that represents the method or whatever computation you just defined right so i define this method i get this compiled code back if i take this code right here right so simple method takes takes an argument generates a string if you look at this in the rubinius like you can do rbx compile and get this output if you look at this this is sort of a description of the object you can see the arguments arity you see the local variable and its name you see how much stack size it actually needs it needs four like slots on the stack to do this computation um and uh there's that i ran this at the at the reply not in the code so it says there's one line that if you if you ran it on that little file you it would be three lines and then you see see the byte code right so the reason that this is important is that this is a representation of your code that is faithful like exactly what you wrote is just transformed into this this other form that allows us to do a lot more analysis of it and it's it's saved it's not just like sort of hidden away somewhere it's something you can get your hands on as an object in rubiness so what might we be able to do with this right so you have your rails app right which has a ton of rails code and you've got all this core library stuff in in ruby itself stuff that you may never have looked at you've got all this stuff running and you have your app deployed in production right and you have the test that you run before you deploy your app in production the thing that we typically see is those are completely separate processes there's nothing nothing that's shared there except for the source code right so when you deploy you might send the source code over there when you're running the test you have the source code here but there's nothing that exists between them right if somewhere to like look at the server they wouldn't necessarily know anything about the test that you ran and if you were looking at just the test output you might not know that the thing is is deployed in production but we have something that we can use to create a link between these two things we have those compiled methods so everything in ruby every class body every module block method script every one of those things anything that ever runs in ruby we represent as that compiled code object right so one of the things that would be interesting to do right is that if in my tests like we often use like a mock or a stub right and we say this thing should respond to this message if we kept track of those things and we have code running in production and we say you know what the actual object that i see at this bit of code doesn't have this method that was there and test that could be a problem right that could be something that that could lead to a failure and your code might be running fine in production you might have no problem but there could be a problem and right now how would you know that right there's there's no way to know there's no way to actually see if something might fail tomorrow but what if you could do an analysis of your code that's running in production and the code that you ran during testing or something that i that i think is a lot more interesting what if you could actually associate a particular feature in your code with uh sorry a particular feature in your application with the code that provides that feature so you get a new rails uh you start working on a new rails project it's not yours you didn't you didn't start it's an existing project and it's pretty big and you go in and they say uh we need to add you know open id to our login sort of thing and you're like okay so you go sort of read the tests and you you look a little bit of the code you're like i think login happens here you expend a lot of energy to like figure out how things go what if instead you just started up the application and you logged in and then when you're done you're like show me the code and you're able to go through and see all the code that ran so the way that you could do this all those compiled code objects right every single one of them what if all you could do is just start every time one of them started running you just put a time stamp there right and then later you sort based on the timestamp and you visit every piece of code and you say oh i went here first and i went there then i went there then i went there then i went there and you can just see like a tour of your code right or in production if you could look at this information in production you could see that these users interacted with our application in this way you could associate geolocation information you could associate time in the morning users tend to use this feature in the afternoon they use this feature or you could do you know sort of analysis of what sort of things are actually more important right because then when you're looking at allocating developer time or resources you can can make a more informed decision than um than just like oh i think this feature is important you know it gives us it gives us a basis to communicate about the application in a way that right now we have nothing i mean i i know nothing no other like tool that would give you this sort of information just the fact that we have that object that compiled code object that we can start associating information about how the application is running would enable us to create a feature like this and then to you know sort of use this word type again it's not i don't want to get hung up on type but basically anywhere in your code right that your these values are flowing through you can look at those values you can see what flows through if you have a method that is fairly general like something like map you know and you want to see well what sort of collections are we mapping over you could also look at actual values that go through your code right um oops and in looking at those values you can sort of see well you know the the the in a web application it's it's kind of simple you know like basically data comes in a form and it goes through but to be able to look at where those values originate and how they tour through your code and where they come back out gives you ability to look at this this uh data flow right and you can see like from the standpoint of performance or you can see from the standpoint of like the feature map the things like how the code is actually running how the application is is um is working and then error analysis if you have imagine you have like a an exception in production right and it's you basically um assume it's something like what we looked at the other day like nil can't be converted to a string right so you have this nil there and then based on the types of objects that you've seen at that location what if you could look at all the other locations that saw those similar types of objects right so if a nil caused a problem over here and all in this place is over here you also have code that sees those types of objects not nil mind you but these other types of objects you can say well it's possible that i could have a nil over here so what do these different code locations have in common right actually potentially giving you feedback before your application crashes so the the the thing that we're missing still in rubinius is this compiled code database basically if we have a way to collect all that that can be on the server on your develop machine on one of your your co-workers development machines if you have a way to look at all of your code not just the source code but as the compiled code and link all that stuff together we could do analysis that spans testing development production so this is this is like a feature that we're adding to urbinius to enable building this tool the um the fact that no one has has built some of this stuff on the decades you know if we go back to the very beginning where we looked at those those uh debugger profiler the sort of things that we have um i guess that basically means it's not a not a trivial problem right so there's two huge challenges that i see in trying to build a tool like this and and this is an opportunity if this is interesting to you this is an opportunity to sort of think about these things the first is information display we're used to looking at our source code in editors and the most advanced thing that we basically have in our editors right is uh code highlighting right like an identifier is a different color than a than a you know like a function identifier is a different color than a variable that's the most sophisticated we have right now and if you add like an ide then you can do like you know context display it might tell you what type that's the most sophisticated we have but there are dimensions to the code like if you imagine you know looking at some ruby code and you've got different um kinds of objects that come through there how do you represent all the kinds of objects that come through there we go from a very flat two-dimensional display where all we've added is color to needing depth right so how to display this information is a big problem and the other one is uh if you've ever used a profiler tool you know instruments or visual vm any of these things if you use this stuff typically what you get is a view of information right that you have to manually go through it's like the the profile information is just this tree of methods and you start clicking through it and see it's like the most primitive thing you can imagine right data needs to be there to support decisions but we don't the data is just presented in like this sort of rough form it's like you're looking at a raw excel sheet and you're like it doesn't even have the sophistication of adding a graph so you can see a trend over time right so if data is there to support decisions then how do we make the data communicate something more than just a list of things that you sort of click through right and if we start going into like uh you know if we start creating tools like this then do we start questioning some of the stuff that we're doing right do we need tests like tests are used as a way to help us write code sometimes right so you write i think it should do this you write a little test and then you run it and it fails the red green refactor thing of test driven development can be a powerful tool for helping us explore you know the problem that we're working on but all the time that i write on a test is not code that's going to run for who's using the application right so there's other things that tests might do they might prevent me from accidentally breaking something so that's it that's a good that's a that's a value of the test but in terms of like how we write code do we need to spend all that time writing tests i don't have an answer for that but it's something to consider if we if we actually look at how we're writing code and we try to make the computer computer communicate better with us right then how does it change something and the reason that i picked on tests in particular is because ruby has a you know good culture of testing right but like zed was saying you know if you uh if you sit down and and pound out some code and someone's like where's your test you're like i don't have any you know then they're like that that code probably can't be very good right does that help us build something does that help us communicate better so just a question to ponder and finally you know it's like this is what we typically see when we communicate with you know the computer it's like i have my editor up and it sits there with this blinking cursor right that's the best the computer can do that's the best we can we can hope for it's like i've done all this stuff i've run my tests i've played around i've done all this stuff and the editor just sits there with this blinking cursor in human terms right if you came to talk to me and i just like stared at you blankly it wouldn't be a very good interaction right there wouldn't be much communication there so you know i want to i want to leave you with that question is this blinking cursor this blank stare from the computer the best that we can expect right now what i see as sort of the goal that i'm trying to attain is this idea of insight right the source code is this medium of communication we've often labored many you know sometimes a single author or many authors we've labored hard to express all this stuff to try to communicate and yet when the new developer comes on the team they sit down and they like you know clone the repo and they you know sort of start looking through the code my experience of doing that with a lot of fairly big code bases while working on ravinius is just that that sort of feeling of weight of like oh my god how am i going to understand all this stuff how am i going to read through all this stuff it's like before you even like start reading it you just have sort of no clue can we actually do something like create a you know deep understanding of this code base without spending like hours and hours going through the code and trying to make it run and this sort of thing right so that's that's my talk thank you there's more information here uh this i think is a very interesting space and uh i hope that you'll join me and like sort of you know seriously question is the best we can do are these tools that we've you know created like five decades ago and we're basically doing the same thing is that the best we can do so thank you um do we have questions hi um it seems that you you're you're talking about um dynamic uh type enrichment or semantic enrichment as one of the problem that you're questioning yes and it makes me think about multi-stage programming that there is an extension in ocaml for instance and if if you if you are going to build tools that help such insights your tools will need to make assumption on the code which is difficult with a dynamic type yes thank you yeah it's difficult to make assumptions on on your code uh with uh such dynamic typing so am i understanding correctly your questioning uh and is it about dynamic typing and by extension would adding annotation about some runtime level would help your tools to make assumption on the code because as a developer you know that when you reach this stage you you you can make assumption but maybe your tools cannot it's completely generic so if you add type runtime levels then your tools will be able to understand it yes no it's an excellent question um so that's the that's the central role of that compiled code so um sure if you if you take a dynamically typed language like ruby and all you have is a source code as a programmer even you go in and you look at it you're like what sort of thing can i do here you start looking at the methods that are called on an object and you're like ah so it has to respond to 2s okay so that's one class of objects but then it's got concat right you're like i only know can cat on array so maybe this thing can only be an array right but at some point you could add some other object that responds to concat right so the idea is that being able to add information not just from you working on this code base but one of your co-workers when you ran the test in production imagine if you could look at your application instead of just this bit of source code right here but as a spectrum of the source code with the work that you've done on the application your co-workers when you've run the test in production what sort of things have happened imagine if you could see sort of a super imp position of all that information as you are looking at your source code or as your co-worker is looking at your source code so um it it sort of takes these arbitrary boundaries that we have right now right you clone the repository your co-worker clones the repository it gets deployed over there those things are completely separate there's no way to communicate if you had a way to start building up metadata about that type information would be one of those examples of metadata in a way that as you're looking at the code you can see all that where as the machine is running in production and you've got some analysis stuff sort of chicken like is everything okay here you know that sort of thing that's the sort of thing that i'm envisioning so what you are hinting now is like some kind of distributed constraint uh system it could uh disrupt constraint system well i mean i wasn't thinking in terms of constraints but but yes distributed right it's like our computer's network why why does why does the code act like it's completely separate yeah so it could be like a distributed type system i mean to certain extent sure absolutely yup totally there's one up there well hi um well i got to think about languages not just programming languages yes natural human language it's a thing about me and zed says programming is characters into a file i actually think of it as talking to my computer right how sad is that and how does the computer typically respond you yeah it doesn't work stares at you that's the idea um [Music] yeah well you know what i mean now um that thing about everything you showed um so the the the theme of communication uh generally resonates with me and um it's also about the how short is the loop the feedback loop from the computer and what you showed that the little bit that you showed in the bin is how it responds by compiling code and the jitter and what gives you back i think that it would uh it would actually um work very well with those ideas uh that brett victor saw yes in in his uh certainly brett victor's uh designing and strangers like table have you looked into that absolutely visualizing such change would be perfect in that kind of environment i think yeah and and not to not to knock what they're doing but i mean the fact that it's revolutionary that you basically made your repple your editor to me that's depressing right that's the best we can do you you basically have irb sessions sort of running along with your code i mean that's the point that they're at now yeah that's the point now but essentially the vision is that in you at any point in time where you are in writing your code uh binds all that matter it brings the documentation name the feedback the compile code yes and if you pull that distributed if you can network it with everything else that would be yeah it would be that that's that's where i'd like to see us go absolutely thanks a lot that was nice thank you uh my question more than a question here over here hello oh there you are hey uh i really love your your talk but something that person means that at the end you talk about how to display the formation shouldn't be how to engage in productive conversations absolutely yeah that's because it's not it's not like at all i mean just showing me something but i don't want information i want to talk right as you said and get significant responses or even questions like uh i just show you what you're doing yes have you noticed that that graph will crash right mentally right you know have you used microsoft word i mean you don't really want to say it looks like you're writing a letter can i help you with that right but you're right and the display of information is just because our our actual ability to communicate with the computer is mostly limited to display but yes why couldn't it talk to you why can it why couldn't it uh i don't know do other things but yes a much better way to say is like how do you facilitate a conversation i don't want that computer just blankly staring at me yeah absolutely all right so uh we here we have no more time for questions but thank you thank you brand you