 So yeah, my name is Kevin Lina. I'm going to be telling you guys about building a grammar for statistical graphics using closure. The agenda for the talk, it's in two parts. The first part of the talk, I just want to kind of talk broadly about data visualization, kind of what's out there. So it's a really exciting field to be in. So kind of what's going on? What do I mean when I say data visualization? And also sort of how you go about doing it. So both in terms of tooling and then also kind of the 101 of human perception and mapping data to visual things. And that's going to lead me to the second part of my talk, which is building a grammar of graphics. So there's so much out there. How can you think of all of these seemingly very different things, so bar charts and line charts and all this stuff? How can you kind of put them together in a single framework to think about them and reason about them? And so I have a 40-minute slot. I'm going to talk for about 30, 35 minutes. And then we'll have five or 10 minutes for questions. So yeah, as Stuart said, you guys should all have a handout. It's got my email and all this stuff on there. So if you do have additional questions, feel free to ping me on Twitter. I'm going to email. And we can talk more about this stuff. Cool? Sweet. OK, so part one, data visualization, what, why, and how. Rather than trying to just tell you about everything that's out there, I'm going to keep it actually very limited and just talk concretely about some of the projects that I've been lucky enough to work on over the past year and just give you an example. And I'm hoping that when you see those, you can kind of step back from the particulars of it and see maybe some of the motivations and some of the benefits and how those might apply to things that you're working on yourself, so on your own projects. And then after that, I want to talk about what and why. But then also how. So there's a lot out there. You can find a lot of stuff on the internet now, a blog post about how to do these things, how to draw them and make them on the computer. But you don't actually see that much about how to actually do them in theory or how to do them well. And there's a lot of research, very good research that's done about human perception that most people don't know about. So I kind of want to give you guys a crash course on that. And then also talk briefly about what's out there. So this is the first example of a project that we worked on this past year. This is an iPad dashboard that we made for a client who runs wind farms. So this is actually all closure script, by the way, which was really fun, harrowing at times, but fun to do. And the thing that this client had was basically, they did done all the hard work. Like they have all these wind farms and they had all this infrastructure in place to collect data about it, right? So they were getting every half second or every second information about all the different turbines, like the wind speed and how fast the rotors are going and the oil levels and all this kind of stuff. And so they were taking all this data and just putting in a database. And the problem was, it doesn't really do anyone any good just to have this stuff in a database. It wasn't accessible to the people who were actually in the field. So people on the ground who had to maintain these things, they're not gonna just stop and sit down and write like a giant SQL query to answer their question. And so we did really what were a lot of very simple visualizations. So this is just a screenshot of bullet charts, which are kind of like a bar chart. And so it's just showing very simple scalar values, but to put it on an iPad and actually have it in the Jeep, in the desert where you can look down and kind of see what's going on is very powerful. So to kind of put this information out there where you need it and do it in a visual way where you can just glance down and kind of get a sense of what's going on. This is another example of a project that we worked on. This is actually open source. So it's on the GitHub. It's also a closure script project. This is for, this is a collaboration with the Harvard School of Public Health. And this is actually a dashboard that they wanted for biologists to look at gene sequencing data. So you guys have probably heard all this stuff about genome sequencing and all this kind of thing. And you have to remember that most biologists are not like us, right? They're not developers and it's not natural for them to just get a giant text file of all their genes in whatever organism they're studying and then to start banging out like a Perl script or whatever to answer their questions. And so this is just a very simple kind of like, this is all built in the browser. And so it was just like you could go and upload your file and then start looking around, looking and selecting subsets of these different distributions. But you could answer your own questions, right? And so that's really powerful. Like none of this is crazy advanced computational stuff. It's just sub-selecting on these different things. But to put that in a browser and make it accessible to practitioners is really powerful because they can kind of help themselves, right? They can answer their own questions. They don't have to wait two months for a postdoc to come by who knows how to program. And one thing I want to say about this kind of data visualization stuff, right? So I showed you this bioinformatics example and this wind power example. This isn't something that's limited to just very kind of like technical domains, right? There's an example that I really love. This is a screenshot from Orbitz. So one of these flight search engines. You know, you type in, you want to buy a flight somewhere. This is a results page. And you can see like just above the fold there's like two results there. And this is kind of typical in the stuff that we build. And a lot of times we don't think about this being a design process. But it's kind of neat. There's a company out there called Hip Monk and this is their take on the same page. So this is their results page for flight search. So if you search for query, you know, this is just showing from Portland to Copenhagen, all the different flights that you can get. But they did it in a visual way. And so you can look at it and see what's going on and answer certain kinds of questions much more easily than you can in just a straight up text thing, right? So in this, you kind of have to scroll up and down and juggle all of these times and prices in your head. But on here, you can kind of just look at it and get a sense of what's going on. So the actual encoding they're using here, each row on this is a different flight or I guess a trip, they're made of multiple flights. They're sorted vertically by the price and then they're positioned horizontally based on the time of departure. So the earliest, you know, the far left is like early in the morning and then moving over is later in the day. And it's just great because you can just look at this and very immediately kind of see and compare in a way that you can't do with something like this. So yeah, we have nothing to do with this but I just love using it as an example. So that's enough of kind of example. And so I wanna talk quickly about sort of the how of data visualization and sort of the theory. What data visualization really is, you know, fundamentally all of these different things is mapping from some data to different visual aesthetics. So you guys are familiar with what data looks like, like a SQL table or a vector of maps or whatever. And when I say visual aesthetics, what I mean are there are a number of different dimensions that we can use to display quantitative data. So this is just a subset of them. This is on your handout as well but doing things like saying, okay, we're gonna take quantitative value and map it to the length of a line or the width of a line, you know, the size of an object, the hue or the intensity of a color. These are all different ways that you can encode that information. And that's what you are doing when you're making a data graphic, right? So a bar chart or a pie chart or whatever. So if you look at something like the Hitmunk example here, what they've done is, you know, they've used a 2D position to map two different variables, right? They have time moving from left to right and then cost going up and down. And a 2D position is a very good aesthetic. It's something that we can perceive very easily and understand. So if I ask you, right, what's the cheapest flight? It's very easy to answer that question visually, right? Because I said, you know, it's ordered vertically by the price. So you can just look at the top and say, okay, that one's the cheapest. You know, and if I say, which one is the flight that leaves the earliest in the morning? You know, it's very easy to see that it's this one kind of down towards the bottom because that's the one that starts furthest to the left. This isn't the only encoding they're using here. You can see they've used color to encode the different carriers. So different kinds of airlines is the color. They've also used the width of these bars is basically the duration of the flight. But width is not something that is as easy for us to perceive as a position in space. So if I say, look at this, what is the shortest flight that you could take? It's very hard to see, you know? It's not something that jumps out in the same way that position is something that we can jump out and perceive. So there are sort of two lessons to take away from this. The first one, as I said, is that some aesthetics are better than others visually for encoding quantitative data. So we're much better at seeing something like 2D position or the length of an object aligned on a common baseline. So these are sort of the workhorses of data graphics, like a scatter plot or a bar chart. They're using these aesthetics because they're very good aesthetics. There's things that we can look at and understand very easily. It's very easy to see. If you have bars on a common baseline to see that, okay, this one is twice as long as another one. So those are kind of the two that you should really rely on as much as possible. And both of those are better than something like width. So the width of objects that aren't sharing a common baseline much harder for us to see. And that itself is much better though than using something like size. So you hear data is people a lot of times ragging on pie charts. And that's because pie charts are using the size of an object to encode a quantitative value. But it's actually very hard to see how much larger is this circle than this other circle. And that's something, if you're skeptical about this or if you're really like pie charts, what you can do is just take the labels off and then have people guess, right? Have people actually try and assign numbers to it and they will be so far off. And that's because we're not good at seeing that. So that's the first thing to take away is that just know that some aesthetics are better than others. And there's a lot of research in this area but if you just kind of use the rule of thumb of let's use position or let's use length, you'll be pretty good most of the time. But because some aesthetics are better than others, the other thing that you need to remember is that you should always have a thesis when you're making a data graphic, right? I mean, it's no different than writing an essay or something like that. Like fundamentally, you're making this data graphic because you wanna communicate data to someone else, right? You're trying to make a point, you're trying to make something clear. And so you need to know what that is so you can choose the appropriate aesthetic, right? So going back to the Hipmunk example for their flight search, they say what are the two most important things when you're buying a flight? Well, most of the time it's gonna be the price of the flight and when it's leaving and so that's why they mapped those things to the position because that's like the best aesthetic that we can use. So that's something just to always remember because people ask me all the time, like what's the best data visualization? And my answer is always like, what are you trying to do? Like, I don't know. You have to think about this and you have to have a thesis. So that's enough of the theory. You guys probably are more interested maybe in the how now for the practice. And kind of what's out there now on the web and just in programming in general, it kind of falls into two different groups that I think of. The first group of things is what I like to think of is kind of the off the rack kind of stuff. So like a pile of t-shirts, you know you walk into a store, you see something that you like, you put it on, you like it, you buy it, you're done. Okay, and so this is something like Microsoft Excel, right? You have all these buttons at the top. You have just buttons for a pie chart or a line chart or whatever. And if you see something that you like and it fits your data and it shows what you wanna make, you make it and then you're done and you're good to go, right? And this is what most people are familiar with when you make data graphics. This is sort of off the rack kind of cookie cutter stuff. So this is Excel, you know, Adobe Illustrator has a little chart button. Here's like the meta slide for my talk because in Keynote, you know, you can make all these things too. So that's kind of what most people are familiar with. The other extreme is this sort of bespoke approach, right? So if you know exactly what you want and you have super particular needs, you can go and do all the hard work to make it. I really like this picture because there's this guy wearing this plaid suit but the stripes on the plaid between the breast of the suit and the sleeve, they like line up at the seam. So he really wanted that, okay? And he did a lot of work to make that happen. And in the same way, if you have a data graphic and you've designed it and you know exactly what you want, there's some nice stuff out there where you can make it. So there's this great project from last year called D3 by this guy, Mike Bostock out of Stanford who is now at the New York Times. But the kind of thesis on this particular project was like, hey, the web is super awesome, right? Like there's all this great stuff in modern browsers in terms of vector graphics and CSS and interaction and all this stuff. So this is actually a JavaScript library that you can use to make custom data graphics. So it's really neat. If you go on their GitHub, you know, they have this examples and things like that. And they just have tons and tons of really cool stuff, you know? But the problem with bespoke graphics, in the same way, like sort of the problem maybe with bespoke clothing is that it's a ton of work, right? In the same way, like doing a bespoke graphic is a ton of code. So this is just like something that I made for like the Hitmonk example in closure. But you know, you have to have all this code to generate the markup. You have to have all this CSS. You have to do all of this stuff. And so there's kind of these two extremes right now where, you know, you have this general stuff like D3 or just, you know, using the canvas or SVG or Java 2D or whatever, basically saying, you know, give me a blank piece of paper and I'm gonna draw everything myself. And then the other extreme which is, hey, here's a big collection of, you know, stamps or cookie cutters. And you know, you just pick the one that you want and then it stamps out your graphic and that's it. And so there are these two extremes right now. And what I'm interested in is, you know, is there something that we could have in the middle, right? We could have something that's a little more flexible than Excel but is not as much work as just having a crayon and a giant canvas where you have to draw all the axes yourself and draw all the guides and do all that kind of stuff. So not surprisingly, this is going to lead me to the second part of my talk, which is a grammar of graphics. That phrase maybe sounds a little silted or strange, right, you know, this is programming. Why is it not like a DSL for graphics or something like that? And the reason is that the grammar of graphics, it was actually a book by this statistician named Leland Wilkinson that came out in 1999. So this is kind of a very thick academic book but his goal, he says in the book actually, he says this is the grammar of graphics. There are no others. This is what you would use to describe any kind of statistical graphic. So it's actually very kind of heavyweight and complicated, you know, and he uses it to describe just everything from maps to bar charts to line charts to all of these other things that, you know, we don't even have names for. And so it's kind of an interesting work from an academic standpoint but the way I actually found out about the grammar of graphics was through this other thing. So in 2005, another statistician named Hadley Wickham implemented a simplified version of the grammar of graphics as part of his PhD thesis and he implemented it and embedded it in the R programming language. So I think we've heard a couple of people mention that already today. But this is where I think a lot of people learned about it and people actually started using it. So instead of having the cookie cutter graphics, you could actually use the grammar of graphics in R to build kind of custom stuff, which was really neat. So I want to just give you a quick flavor of some of that stuff and to do that, I'm going to show you some graphs made from this simple data set. So this is a classic data set used in the R community of just cars, right? So each row is a different car and the variables are things like the fuel efficiency in miles per gallon and the horsepower of the engine and the weight of the car and stuff like that. So some of the graphics, this is what they look like actually coming out of R and this is the actual R code. So you can see instead of having some sort of function that's like make me a scatter plot, the function is here's my data. Here are the aesthetics. I want you to map these variables against. So I want to map the weight aesthetic to the X dimension and then the miles per gallon variable to the Y dimension. And I want to use points to represent that. So that's how you would say make me a scatter plot. And what's cool about this is that it kind of splits apart these different concerns and you can add additional aesthetic mappings very easily kind of in this framework. So you can say, oh, what if I want to color these points by the number of cylinders in the car? You can do that pretty easily and the system draws you a legend and things like that on the side. And of course, you have other kinds of geometries. So doing things like box plots and it is an R which is a statistical language. So you can do things like having a curve fitting and moving averages and things like that. The sort of problem with this is that unfortunately it is written in R which aside from having this horrifically ugly logo is also, I mean, this is what Edmund said earlier this morning is it's kind of this island, right? You know, R is this academic language and it's great if you can get your data and you go in your corner and you fit your models and you're sort of playing by yourself and then you come back with the answer. But so many people now and especially in this room and in this community, we don't sort of have that luxury. Like we're building systems in production. Like we have all of our data is not something we can just spit out to CSV and then take over in the corner and look at. And so I was sort of thinking about this problem and no surprise it would be really nice if we had this in a nicer language that more people could use. And so I've been working on implementing this grammar in closure. But the important thing is not actually that it's in closure that's sort of an incidental detail. The important thing is that closure is on the JVM, right? So you're gonna have this library or this service that is accessible by sort of the broader community of developers, right? So you have all these other languages on the JVM ecosystem. You have the actual, you know, nice toys like Hadoop and web servers and all this kind of stuff. So that's kind of the goal of this thing that I'm working on is to take this idea which is a very interesting idea and then move it over into a space where more people can actually use it. But I wanna step back before I actually start showing you code examples and things like that in the closure grammar of graphics and try and motivate again sort of why you would wanna do this. And, you know, it's nice. I gave this talk to a non-closure group and sort of had to explain this stuff. But here I think you guys understand many of these ideas but, you know, fundamentally the idea here is that most of the way we make charts and graphs and all this stuff, it's totally complexed, right? If you have a function that just says, like, draw me a scatter plot, this is just this insanely complexed function because, like, think about what it's doing. Like, think about all the different things you have to do to make a statistical graphic. You know, you have to do things like calculate the extents of all the different scales that you're using. So looking at the data and the variables and figuring out how much room they need. You know, you're doing linear scales and log scales. You have to calculate all of these tick marks. You know, doing things like curve fitting or other sorts of statistics. And then once you've done all of that, right, you actually have to draw this stuff, right? You have to iterate over the data and draw all of these labels and guides and this kind of stuff. And if you just have this function, you know, that's draw me a scatter plot and you wanna kind of change these little pieces in here, it's just insanely difficult to do, right? I mean, in Rich's talk, when he introduces the word complexed, he has this example of the knitted castle, which, well, I think it's hilarious because I didn't, you know, it's a knitted castle so that's pretty funny. But it really is like a good way of thinking about it because it's like, if this is the castle that you want, if this is the graphic that you want, great. If you want something slightly different, like, sorry, it's gonna be a ton of work. You're gonna have to reimplement all of these things because all of this stuff is tied together in this one function or in this cookie cutter sort of thing. And so the idea, again, with this gram of graphics is ultimately, you know, you wanna decomplect all of this stuff. You wanna take a statistical graphic and you wanna break it into the different fundamental pieces. And so if you step back and think about what those pieces are, you know, of course you have your data. You have the geometry that you're using in your graphic. Maybe you have more than one kind of geometry. This would be things like points and lines. If you're making a map, right, you have polygons and areas, box plots, things like that. And then you have your mappings. You have mappings from the dimensions of your data from your data space into the different aesthetics of your geometry. So these are the aesthetics that are on the handout that I mentioned earlier. And then of course you have things like statistics and groupings. So if you're making a histogram, you wanna bin the data and sum it up or maybe do weighted sums, things like that, scales, all that kind of stuff. So the idea with a grammar is to take all of these things and, you know, these are orthogonal things and you should treat them as such. And you know, and you should be able to work with them on this orthogonal level. You wanna tease apart all these different concerns. So this is actually some examples, specifications and output of what the system does. So this is a scatter plot, not too surprising. You know, just a closure map, you say, here's my data. Here's the geometry that I want. Here's the mapping from my data dimensions to my geometry's aesthetics. So you can look at this, this is pretty cool. So this is a miles per gallon versus the weight of cars. You know, no surprise here. There's a negative correlation. Heavier cars are less fuel efficient. But you can see there's a little bit of over plotting on some of these points. So they're a little big. So it'd be cool to do something to say, okay, let's make the points a little smaller. So these are, the system uses tag literals for doing this. So point is just, you know, it's like a, just a typed map, basically it's a closure record. But it's nice because, you know, this, when you wanna do these kinds of things, when you wanna override the defaults, there's kind of, it makes, there's a natural place to put these things. So just say these things. Like you say, I wanna make the points smaller and then you change this data structure, right? There's not some weird flag that you have to look up. Or you don't have to hope that the library author has given you some, some option in the make scatterplot function to do this. And the only thing that's cool, right, is you can change all of these things and it's all orthogonal. So you can look at this and say, okay, you know, that's interesting. What does it look like if we wanted to look at, instead of the weight of cars, you wanna look at the cylinders of a car. So that's just a one line change, right? In this aesthetic mapping. You don't wanna assign the weight to the X. You wanna assign the number of cylinders in the engine. So you can do that. And then immediately, you know, some things stand out. You say, oh, it looks like all of these things are now falling into just three distinct groups, right? So all the cars in this dataset have either four, six, or eight cylinders. And then once you've done that, you can kind of think, oh, well, you know, now maybe points are no longer the best representation. Like I've kind of discovered this thing about my data, but the point geometry no longer makes the most sense. Maybe I wanna use something like box plots. And so because all of these things are split apart, it's very easy to kind of interactively explore and look around, which is very powerful. You know, because again, comparing to sort of what's out there now, if you wanted to do this, if you wanted to go back and forth from like points on a scatter plot to like a box plot, like you probably have to step back like a page of code because you probably had to munge all of your data to some form of like arrays and arrays so that scatter plot function could eat it. And then if you wanna look at box plots, you're probably gonna have to step back and like go find the appropriate package or whatever and munge the data that way to get it in here. But if you can split apart all that stuff and just do it in this nice grammar, it's very simple to sort of explore, which is really important. So one thing that I do wanna point out, if the astute of you in the audience may be noting that, this seems very sort of suspiciously short, right? Because, and if you think about it, the mapping, so the aesthetic mappings, I have X and Y. But that doesn't seem like quite enough for a box plot, right? Okay, so X and Y is for a point, that makes sense, but the box plots, they have a lot more aesthetics, right? They don't have a single Y aesthetic, they have the position of the bottom, the position of the middle and top of the box and stuff like that. So stuff is missing here. The actual full specification, if you kind of decomplect all these things that you would need is you need something like this, right? What's really going on here is that you need to group the data by cylinder, you wanna calculate these quantiles for that group and then you actually wanna apply the results of that calculation. So like the Q25, the first quartile, right? You wanna do that to be the lower part of the box and all this kind of stuff. So what's going on here? Where you can write this to get this graphic and if you show this graphic to someone, they would kind of say like, oh yeah, this is sort of colloquially how you would say it. But in reality, you're kind of to be fully explicit, you'd have to say this. So how do you sort of reconcile that? Because if you have to be this explicit all the time, it kind of sucks because then doing sort of exploratory stuff is very hard. So really what you want is some sort of way to recognize this sort of colloquial or incomplete expression and then turn it into sort of the full realized expression that has kind of all the fiddly bits spelled out. And I was kind of thinking about how you'd go about doing this and looked at how ggplot implemented these kind of defaults and really what you want is you want a nice sort of declarative way to just specify kind of rules to say when you see something like this and the user has left this stuff out, maybe you should rewrite it because they probably meant this, that or the other thing. And it gets really nasty if you try and put this in just different conditions of the code and stuff like that. If you want to handle all of these different cases, it would be a huge mess of like if then else statements and stuff. Really what you want is some just declarative way to specify these rules and then have the right thing automatically happen. So it would be really nice if there was some library in the closure community that could declaratively do rule-based things. And luckily David wrote that library so it's called CoreLogic, right? And I was so jazzed about this because I found out about CoreLogic at the last conge and I sort of had a running joke with Paul, actually Paul the grandest, about making t-shirts for the conge this year that said my program would be way better in CoreLogic and then on the back it would say if only I knew how. And I was so jazzed to find this example of not a logic puzzle and not a compiler of some kind that I could actually use CoreLogic but it's worked out really great because you do this kind of thing. So here, this is kind of, this is a work in progress syntax but you say things like okay if the specification map if the person has asked for a box plot and they haven't provided a statistic they probably want to use quantiles, right? You know you can just put out all these different rules and you can do actual unification, right? So you can move things around in these maps to turn sort of the colloquial stuff into what you actually need fully specified. But at the same time, right? If the user knows exactly what they're doing and they want to specify everything out they can still do that. So that's been really interesting. Same kind of story with something like a histogram. You really, like most people they want to write something like this they want to say yeah I want bars I want to use a sum statistic and I just want to look at this one dimension of the data but if you actually want to be pedantic about it you need to write something out like this, right? You need to say I want to bin along this carrot dimension with this many bins I want to sum and this is the actual mapping from the result of that statistic to the bars. So it's really cool to be able to use something like CoreLogic to match on this stuff and do rewrites. And so I definitely wanted to thank David for that and also I don't know if you guys have seen Jonas' Kibbit library which does this kind of pattern matching as a linter for closure code which is really where I got this idea. So that stuff is really cool. And you know this is possible again and this is sort of a theme so Chris mentioned this in the first talk and this is a term I heard from Alan Dipert but to data all the things and this is like so key and it just seems like I cannot stress this enough. Stuff becomes so much better when you do that, right? There's no way I would have been able to do this kind of CoreLogic pattern matching stuff if I had all of my stuff tangled up in objects with methods and all the stuff but because all the specifications just with closure maps and records you can plug into all this stuff and use all this great stuff out there. And the benefits of using data, I don't want to stress it too much in this community because you guys already know it but for me it's really nice because Rich talked about using services and stuff so making our lives a lot easier as a developer or people who have to develop this stuff to support different languages so this is the closure API and this is the Ruby API and this is the JavaScript or Python API, right? Like it's all just data, it's so great. The other thing that's great about having data is that you can program, right? We're all programmers and that's what we do. We manipulate data and if you're just upfront about that as a library author and you let people mess with this stuff then they can solve their own problems much better than if you try and shoehorn them into using whatever methods that you're providing them and whatever options you're providing them and nothing else. So to give you an example of that here the actual workflow in the system as you start with this specification it goes through a kind of compiler and turns into this sort of scene graph kind of thing and then it actually gets rendered out into SVG or PDF or PNG or whatever you want but what's cool about this scene graph thing is this is just another huge data structure, right? Like this is just a big map, it's got sub maps and vectors and stuff in it but you can manipulate it with your own code, right? So you can say here's my specification I wanna compile it into this scene graph and then you can add your own code into this process you can aso-shin and say I wanna update the scale here so the y-axis I want it to go from zero to 40 instead of whatever extent you've calculated automatically from the data or I wanna change the label on stuff but you can do all of this very easily because it's just code, right? You just look at this thing and it's very evident if you wanna change the stuff around you can do it. So that's really powerful and I can't again say like it's been so great to sort of this idea of decomplecting things like it's very, very powerful to just look at things and say what's going on here and to say actually there's a lot going on here and if you can pull apart those separate pieces you can really get a lot of leverage and a lot of mileage out of that stuff. So it's nice because having this grammar or having this framework lets you say a lot of very interesting things, right? If you have a limited vocabulary and you can only say something like a scatter plot or a histogram you're sort of caught only being able to describe those things but if you can split apart all of these different concerns and kind of have this vocabulary you can express certain things that maybe you weren't able to express before and really more importantly it lets you think about stuff in a different way, right? So having something like this when you're actually upfront about thinking about different visual aesthetics, thinking about the role of statistics and all these separate things you can put them together in just totally different ways that maybe you weren't even able to think about before and so really I think this is not something that is unique to this particular problem domain and it's I think a benefit that you get from stepping back and trying to pull things apart into smaller pieces. So that's all I have. I hope you guys like it. Thanks. Questions? So the question was how can we visualize our functions and our code as developers and in light of things like Table and Brett Victor's work and things like that. I don't have any I don't have any particular thoughts that come to mind on that. You know this kind of system too is right now very focused on sort of more standard statistical graphics and things like that. I mean, yeah, I'm not exactly sure what that would look like. So maybe talk to me in a year or two. Yeah, so the question was have I seen stuff in the R library about using functions or formulas and stuff like that in the lattice graphics package? I haven't thought about how to sort of expand it even higher level to kind of talk about specific problem domains for stuff. I mean, and this is kind of the thing about using stuff with data like the interface for this is just maps. You know, so and it's accessible from all the programming languages basically because everything has maps. So I don't have any sort of plans to move into that kind of stuff but there's a sort of foundation where you could do that, right? Like you could have a more domain specific thing where you're talking about formula and specific mathematical things and then sort of have your programs spit out maps and things like that to render. Oh, sure. Yeah, so one thing that I didn't cover and I can talk to you more about this a little later but one idea that Hadley Wickham, the author of GGplot had that is implemented in the system is that the plots themselves are a kind of geometry. So it handles faceting and things like that. So faceting is when you take, instead of like multiple subplots. So you might wanna say, I wanna do this miles per gallon versus weight thing but instead of coloring the points by the number of cylinders, I wanna actually just make three different plots. So I'll make a plot for four cylinder engine, six cylinder engine, eight cylinder engine. And you can actually do that kind of thing because it works recursively. So, yeah, so the question was can you have code? Yeah, this is not open source right now. Actually it's not totally ready for public consumption. It is actually going to be a proprietary thing. There will be probably some kind of free version but my hand was sort of forced on giving this talk because one of the other speakers canceled and they asked me to come and present it. So it's not quite ready yet. Yeah. So limit to the customization. Yeah, the question was, is there a limit to the customization of this stuff? Yeah, definitely. I mean, this is never going to be as expressive as having just a crayon in the scene graph, right? Or like a blank canvas. You know, the idea is kind of to be in this middle ground where it's going to be expressive and customizable enough for most people's needs. But you know, if you want to do very custom things or you have a very specific idea of what you want, you probably will still want to use something like D3 or Java 2D or whatever. So, yeah. So the question was stuff relating to a closure script in this. Yeah, so actually last year at the conge, I talked briefly about some database stuff and so the D3 library is a JavaScript library. I have a port that works in closure and closure script called C2, you know. And this system, right now it outputs SVG and stuff and it shouldn't be too hard to port over to closure script. But the actual, you know, a lot of people ask me about interactive graphics and things like that. And that's a very hard problem. So it's not something that I've been able to think about enough to have a satisfactory answer to. I actually tend to be very conservative in having just well-designed static graphics over kind of crazy customizable interactive things. But yeah, we can talk more later about closure script stuff if you want. Any other questions?