 So yes, I'm Brent Yorgie, I'm really excited to be here. I would like to tell you about a project I have called Diagrams. So Diagrams is a domain-specific language for creating vector graphics, and this was really sort of born, you know, I'm really a programming languages researcher, but I love to think and communicate ideas visually. So, you know, I was unsatisfied with the tools that existed for creating this sort of, you know, pictures that I wanted to use to communicate ideas. So I said, well, you know, what happens if I apply the things I know about math and programming languages to, you know, designing a language for creating these pictures? And so the result was Diagrams. And I'm especially excited to be here because I don't know a lot about graphics. I mean, I've been learning more and more as I've been working on this project, but you all know a lot about graphics, so I'd really love to get any kind of feedback and collaboration. I'm sure I can learn a lot about the graphics side of things, but I hope I can share with you some things about the programming language side of things as well. So the most notable thing, one of the most notable things about Diagrams is that it's, so it's this domain-specific language, but it's embedded in the Haskell programming language. Just out of curiosity, how many of you have heard before of Haskell? Okay, wow, great, everyone. How many of you have actually written a Haskell program? Okay, that's about what I was expecting actually, so that's great. So Haskell actually makes a really great sort of environment to embed a domain-specific language in, and I'm going to tell you some of the reasons for that. So first let me just show you some examples so you can get a flavor of the kind of thing you can do. And these are very simple, and I'll show you some more complicated things later. So starting very, very simple, I can make a circle and a square, give them some attributes, and in this case, I say put them next to each other so that they're touching. And this is just a Haskell expression, but all the things there, all these functions and these little operators are things that are defined by the Diagrams library. So none of the things up there are built into Haskell, they're defined by the framework. So here's, oh, yes, and I should say. The notable thing about this is that I didn't have to write any coordinates, like put this at 2, 3, and this is sort of one of the design goals, is that usually when I'm creating some kind of illustration, I don't actually care what the coordinates are. I mean, if I'm forced to pick some coordinates, then fine, I can pick some, but I'd really rather just say, I circle in a square, here's how big they should be, put them next to each other. So of course you can use coordinates if you want, but a lot of the library is designed to make it so that you don't have to. You can sort of specify things relative to one another, and the framework will sort of work out all the coordinates for you. This is a slightly more complicated example, drawing some kind of tree. So I have a function here, fib to construct the tree, it's a recursive function, and then the code down at the bottom, so it creates this tree with eight levels, applies a layout algorithm that we have implemented, and then draws it, and this code here is just telling it how to draw the nodes and how to draw the edges. And there's some list of colors that is constructed somewhere else that it's picking the colors from. And notice the interesting thing here is that because this is embedded in Haskell, I can write, Haskell is a general purpose programming language, I can implement arbitrary things, so in this case I wanted to compute a particular tree that I wanted to draw, and I can just write a little Haskell function to do that. And this is a pretty simple example, but you can imagine situations where you want to do much more complicated things, for example, maybe you have a bunch of data that you want to analyze somehow and then visualize it, using a framework like this, you can have that all be in the same program, in the same language. You don't have to worry about sort of munging the data and then outputting it to some intermediate format and reading it into some other program to draw it. Okay, so I just wanted to share sort of some of our experiences building this as an embedded domain-specific language, and some of the reasons that Haskell is a great language for this. And these are a few of the reasons. There are others, so for each of these I'm going to go into a little more detail and show some examples of how these work out in the particular case of diagrams. So I should say there's also a reason that using embedded domain-specific languages is annoying, which is that you get horrible error messages, because you would like to have the error message say something about, oh, you tried to, you tried to apply a point as if it were a color, but that doesn't make sense, but instead you get some horrible error message talking about all the internals of the library. So that can be, in fact, this is sort of an open research problem, and I know people that are working on this, you know, how do we get good error messages for embedded domain-specific languages, but, so, oh well, for right now in our manual we have a section that says, you know, here's some error messages you might see and what they mean. So, okay, so back to reasons that this is a nice thing to do. So one is that Haskell has a strong static type system, so I'm sure many of you are fans of dynamically-type languages like Python, which are fine languages, and I think there's a place for both. Sometimes, though, I hear sort of, I encounter people who have very VM in opposition to static types, and I think, from my point of view, I think some of that comes from working with statically-type languages that have insufficiently powerful type systems, so it's sort of just powerful enough to get in your way, but not powerful enough to really help you out. So Haskell's type system is, in fact, very expressive, and it makes it possible to sort of express a lot of constraints and invariance of your program and then have the compiler help you get them right. So just as an example of, you know, there's all kinds of types in our library for all sorts of different things, so here's examples of things that all have their own type, and in fact, a lot of these are sort of parameterized types, so, you know, for example, vectors, you can have vectors in any dimension, or you can have, there's various types of diagrams, depending on what backend you want to use and the vector space and things like that. Right, and the point is that the compiler makes sure that you don't make silly mistakes, things that don't make sense, like adding two points or even something silly or like applying a vector to a color. And this really cuts down on a lot of the sort of obvious mistakes you would make, it catches them right away, and then you can work on the more interesting mistakes. Okay, so Haskell is a functional language. That means a lot of things to a lot of people, but one thing in particular it means is that it has first class functions. So I can pass functions as arguments to other functions, return them as results, I can store functions and data structures. So here's one particular case where we really make use of this. So along with each diagram, we store something that we call the envelope. You can think of this as sort of like a generalized bounding box, but a bounding box only sort of tells you how big something is in, you know, two orthogonal directions, and envelope tells you how big is it in any direction. So the envelope is in fact a function, and as input it takes a vector and as output it sort of tells you how far along that vector do you have to go until you reach the boundary. And we use this for doing things like putting diagrams next to each other, but you can put them next to each other along any axis. These also transform very nicely. So if you have a bounding box and you rotate it, well, that's annoying because now it's not axis aligned anymore. And so you either have to sort of pick a bigger one or you have a bunch of choices and none of them work very well, but these work just fine under any kind of affine transformation. And it would be really impossible to do this without having first class functions in your language. I don't know of any sort of good way to represent these using some kind of first order data. I mean, you could approximate them using polygons or something with a lot of edges. But it's usually much simpler just to have a function. So another reason Haskell makes a great substrate for this kind of embedded domain specific language. It has really powerful abstraction mechanisms. So here's an example from diagrams. So you can draw squares, of course, and you might expect square to have a type like, but it takes a number telling you how big the square should be and it outputs a diagram. So in fact, so you can certainly do that with square, but in fact, square has a much more general type. So I'll show you the type and then I'll let me explain what this means. So this says, okay, square still takes a number as input. So that's this double part here, but it can give you any type as output, as long as that type satisfies these interfaces. So this is using Haskell's type class mechanism, but you can think of sort of like Java's interfaces, but a little more powerful. So this says a square can return any type you like, as long as it's trail like, which essentially means you can take a path and convert it into something of that type, and it has to be transformable and it needs to live in a two-dimensional vector space. So here's some examples of, so on the left here, I have an actual square that I've drawn. In the middle, what I've done is I've used a square, instead of using it as a diagram, I've used it as a path, and then I superimpose two of them to make a bigger path and then fill that path using some kind of fill rule. And on the right-hand side, I've used a square. You can also use it as a list of points, and it gives you just all the vertices of that shape. And then I've drawn some dots at those vertices. I don't have space in this slide to show you the code to do this, but the code is not that complicated. The point is that I can reuse this one function square in many different contexts, and depending on the context, it will sort of do the right thing. The last point I'll make is this has really been another focus of this project. Coming from my math and programming language's background, this is something I really focus on. Taking some domain and saying, what is the essence of this domain? Is there a simple, elegant mathematical model that I can use to explain what's going on in this domain? And then that sort of works out and tells me how to structure an API that works nicely. So one particular example, diagrams, a lot of it is based around this theory of monoids, which basically you can think of as how to combine things in nice ways that satisfy various laws. So most things in diagrams can be combined in various ways. So you can put two diagrams on top of each other, or you can put the next to each other. You can combine colors in various ways. You can combine paths. I think on the bottom, you can combine transformations. And this all works in this same interface that talks about combining things. Is there something else I wanted to say about that? Probably not. OK. Oh, well, yes, I wanted to say, in particular, that's interesting to you. I actually had a paper about this in the Haskell Symposium two years ago that sort of goes through this idea of monoids and how we use it to structure the design of this library. And I hope it should be, at least some of it, the beginning of it at least, to be accessible, even if you don't know any Haskell. Maybe you'll be able to get something out of it. So let me sort of begin to wrap up just by showing you a few more complicated examples of things people have done with the library. There's a few examples. There's a lot more examples on the gallery on our website. There's more examples. And for each of these examples, you can also click on it, and it'll show you all the code that was used to generate it. Here's another example. We have a user that took a big data set that was like a bunch of data about parking in one part of London. Sort of like how many parking places were being used at various points during the day. And they did some analysis and then used diagrams to visualize the results. I don't actually remember what this is visualizing, but the point is they were able to do it in one program, the same program they had that read in the data, analyzed it, and then spit out the visualization. And it made it really easy for them to iterate, changing the analysis and the visualization together, since they was all part of the same tool. I'll wrap up just by saying a little bit about where this project is going. This is just to show you the momentum. This is a visualization of commits. So each horizontal line is a repository on GitHub that's a part of this framework. The x-axis is time, and each little slice there is one week, and the height of each slice shows you the number of commits. So the takeaway is there's lots of work being done. In particular, recently there's been these big spikes. We've had some new contributors come and do a lot of cool stuff. So there's lots of momentum. And in particular, we have lots of great ideas about things to do, way too many to actually do. We have this Trello board full of ideas. You probably can't see this, but these scroll bars are very compressed. So there's lots and lots of ideas way down here. So a few particular things that we want to think about. We have a student who's going to work on a Google Summer of Code project to work on editing these diagrams. So have a nice way to express. You build up a diagram, but then want to express editing it in various ways, like changing some colors or manipulating parts of it. Another thing, we actually do have a way to generate animations using the same framework. But it's kind of ad hoc and clunky, and it sort of needs some rethinking. And then interactivity as well. I think there can be some nice ways to express making not just static animations or diagrams, but interactive ones. Have a sort of more pie in the sky idea about, well, you were writing some code to build this diagram. You want to be able to visualize the diagram in real time as you're editing it. But then wouldn't it be nice if you could actually manipulate the diagram itself and have that reflected in edits to your code? So thinking about ways to do that. That's more of a research level, I think. And there's lots of other ideas. Maybe you guys have some interesting ideas I'd love to hear any suggestions you might have. That's it. Thanks. Here's the URL for the project. And I'm happy to take any questions. So first, the suggestions. Does anybody have any suggestions? Suggestions? Questions, then? Thank you. OK, a suggestion or remark first about this bi-directionality. I'm really a really stimulating thing because somehow we seem to have a lot of trouble to get bi-directional interfaces where you can, on the one hand, edit code. On the other hand, edit the visual result. So maybe languages like Haskell or new programming paradigms can help us with that. So that sounds really enticing. And another question is a bit about the relation between design and mathematics. And I was wondering what you think about that, because you're, of course, not alone in positing this kind of relations. It seems to be also super popular among type designers. And for example, this morning, we've saw some examples of these kind of systems. Of course, there is Kanoof, who also is the OG of this kind of lines of thinking. And at the same time, in more practical design work, like we're making a website or a poster or any kind of design artifact that has to communicate a certain idea, I don't feel at all as if I'm thinking about mathematics or elegance, for example, where it always comes up. Or for me, it doesn't feel very present. So I mean, I was just wondering a bit more about your facts or what does that focus on mathematics and elegance. What does that mean for the domain to which it can apply it? So I guess I would say, I mean, I think there has to be kind of a spectrum. I'm certainly not advocating everyone. For every single project you do, you should be thinking about math. Because actually, one of the dirty secrets is that it's really hard. Even if you know a lot of math, it takes lots and lots of iteration and revision. I actually worked on an early version of this system. I wrote it in a few months, and I really kind of had programmed myself into a corner. And then I spent like a year and a half thinking about it on and off before I rewrote the whole thing from scratch. And even since then, it's been refactored thoroughly many times. So I think that kind of approach is really powerful. And it, in my experience, tends to lead to really powerful insights and really great APIs. But it's sort of only practical for these kind of projects where you have the leisure to really put in a lot of time to iterating. And as you say, for just some particular artifact you need to make, you don't have a year to iterate on it. It's not that practical. Yeah, yeah. Next question. Suggestions again? So thank you very much for the presentation.