 So welcome everyone. My name is Joe Martin. I'm a developer at OVH. It's a big cloud company, international cloud company, mostly famous in Europe. And I was a developer at Ubisoft before. And today I want to talk about an experience I had while I was a developer about managing data and how data usually grows out of control. And so I'm going to talk about JSON, but it could be about any data structure language. What we usually expect from JSON is well to present structured data. Here's a bunch of JSON and you usually know it has strings, it has numbers, it has arrays, dictionaries, maybe booleans and that's it. Any time you want to save some data that is not in boost types, you need to put them, usually you put them in strings and then you have some program to transform them later. The issue with that is, for example, what if we want self-references? Usually it's done with IDs, so here I want my owner to be from a list of owners, so I create owners with IDs and then I put an ID in the owner section and good luck to keep them in sync. If you've worked with MongoDB, for example, it's not made for relational stuff and when you start doing relational stuff because anytime you want to do something, usually you have a relation sometimes that appears, so I guess it's data to... the number of max level punnies is not something complicated, but it's data. And JSON actually cannot compute that. We need a program to compute, to fetch the number of punnies and see which are max level, but the number of max level punnies shouldn't be something that you need to compute. It's just simple data. So JSON is not enough and any data structures is not enough for any complex system. We fail at self-referencing, we fail at representing processes and computations. So it's 2019, what everyone does. Let's add JavaScript to it. So this is some grand file I took from a random project on GitHub, but most grand files look like this. It's supposed to be a configuration file, but you use JavaScript because you need some computation at some point and the file grows up into this big monster and you don't handle it anymore. And it happens to be the case with JavaScript, but I've worked with Lua files for configuration, I've worked with Python files, and most of the time they start doing stuff they shouldn't do and grow out of control. So why is that? I'm going to quote Bill Cosper here. A data structure is just a stupid programming language. JSON, XML, HTML, CSS, those are all stupid programming languages. When you try representing concepts with them, the abstraction leak, and we end up writing some abstraction layer by hand to end up with data. So we should be able to use data structures that are smart. This is an example of something we do to make them less stupid. For example, CSS has no variables, so we create less. JavaScript cannot handle itself. It has no meta system, so we create Babel. Babel is an awesome project by the way. HTML was kind of a mustache template, but old languages also have their system to handle this limitation. C as the preprocessor, C++ templates, Python as meta classes, nobody uses them, but they're here, they're here. C sharp as reflection. What if I told you there's a simpler way, there's a more personal way that adapts to your domain? It's called a DSL, so we saw a DSL just before my talk, domain-specific languages. They're an abstraction that becomes a language. And you use DSLs all the time without knowing there are DSLs. For example, make files for DSLs, regular expressions, SQL, the QT UI language, any game engine language. These are languages that represent data structures, complex data structures, I don't know, a monster in a game, a quest, something. But they're not simply data, they're a bit more of a data, and so we need a language for that. Because structured data will always be better expressed with a specific language for that domain than a generic data structure. So banking data, you need a banking language, game data, you need a game language, medical data, you need a medical language. But I hear you say, isn't writing full language a bit excessive? And I need to remember the first rule of computing, the first rule of programming, abstraction leaks. It's what I call natural growth or organic growth. It's whatever you do, your data will always evolve and leak through the abstractions you create. Usually what we do to prevent this is we call this middleware. It's the kind of software that we write to pipe data into something so that it works. But Lisp programmers usually know how it goes there. Most of the time, with middlewares, they actually are a badly written half implementation deep inside somewhere. There's this Lisp hiding. So why not using Lisp in the first place? And so I'm here to talk about my favorite Lisp, which is actually from the Scheme family, its racket. And it's a language-oriented programming language. So you can check it out at racketlang.org. And so as it's a Lisp language, it allows writing itself by design. It understands itself. You can modify the compiler by using the language. And so it's really good at writing DSLs. These are examples of DSLs that ship with racket. There's language for slideshows, which is the one I'm using right now for these slides. There's a racket for doing UI interfaces. Cribble is for documentation. There's a language for editing videos. And there's a web server language. Anything you like. Because making a DSL in a racket is like five lines. These are the five lines that generate a parser in a racket. They're very bit intimidating at first, but they're just a smart combination of racket features. And you just put these lines into a file with the name of the language you want to create. And you've got yourself a full reader, parser, expander, with all the standard functions from racket. Which allows you to create a lot of languages. This is one of the languages I'm working on. It's called WebGalaxy. It's based on the web server system. And as you can see, you kind of blur the frontier between what is code and what is data. In this case, we got a response from the API. The API endpoint is Pony. It takes an ID. Then it gets the Pony from the database. And then it returns HTML. So now we're writing HTML. And then a bit later, we're writing CSS. Then a bit later, we're writing JavaScript. And so we don't care. It's just using this list syntax called sExpressions, you can write any kind of language in the same flow, in the same code. Your code is your data. Your data is your code. You don't care. This is another example of a project I worked on. It's a simple file that you write your emulator for. You write the description for a processor. And it generates a full emulator from that description. So this file is about 500 lines, I think. And it generates a full emulator for that processor. You just describe the registers. You just describe the status register, what the means to interrupt, then all the operations. And you got yourself an emulator without writing any code. You just have the data presenting what the emulator is doing. This is another example used everywhere in the racket environment. It's called Scribble. It's the documentation language. It's kind of like Markdown or Lattec. It's really useful when you want to write more textual documentation. And there's functions. You can open a function there, define a function. And it generates some paragraphs. And it generates links to other parts of the documentation and stuff. So what I really want to focus on is usually your data structures are not enough for the problem you're trying to map. So in those times, we seek more abstraction. And from my point of view, I think DSLs are a very good way to express abstractions as languages. And it happens that racket is a really good language for writing languages. By putting this middle way logic into a language, you can make it evolve and fit your domain. You care about your language more than you care about a shadow script in some part of your system. You don't have to write ugly data transformation scripts ever again. The language is there to help you make the transformations. You don't have to write some one-shot scripts to transform data into something else. And when you work in a team, the documentation that describes usually a script that modifies some data has been written for one-shot thing. It has no documentation. But if you write the language, you have the language specification. You have the language description. And so you can provide your team with that documentation to make them learn how the language is working and so they can directly use it. This afternoon at 5 p.m., if you're interested in making languages, I'll be having a workshop in an hour, about an hour. You can come and create your language. And so in an hour, you get back home with your own language you can use for whatever you want. So if you like making languages, then see you there. I think we've got some time. So if you have any questions. Yeah, you can, by default, the easiest way to make those kind of languages is using S expressions. But if you want, you can create a custom reader and then, for example, Scribble is not made with S expressions. You can have the syntax you want. Sorry? Nope, I don't know. Do we need to repeat the question for the... Submit a talk next year. Yeah, well actually, I submitted a talk, then accepted, and then we'll go through that. All right, yes. I mean, I think like Haskell, I mean, the advantage of JSON, obviously, particularly if you go to a binary with JSON, is that you've got really high performance, right? Tribial parser can get pretty good performance in the running in real time. I mean, racket performance is awful, right? Relatively, it's pretty bad. Just on a scheme of things. Did I really like racket? I mean, I really like Haskell, but the performance relative to writing a JSON parser in C. Yeah, definitely. Yeah, obviously. And in many cases, it's complicated. Maybe. I don't have a lot of experience with having to really crunch data files at high speed. Usually, I use data files for mapping to a specific domain, but yeah. Racket is really good at being reactive like that. Mostly, there's an IDE that comes with racket, that is Dr. Racket, and it has allowed the language to evolve a lot into interactivity. For example, if you write a custom language using racket, it's automatically auto-completed inside Dr. Racket, and the highlights, the color highlighting is there, and stuff like that. For example, I didn't award the presentation using Dr. Racket, but if you do, you have some kind of interactive thing like a WYSIWYG system when you can create your slides by clicking on it. And so by using a language that understands itself, you can usually make some interactivity easier than using another language. Yeah, so racket is really interesting for that because the typed version of racket is actually a language made with racket. So when you want types, you use typed racket and when you want... You can write a program using just the simple racket and then add types later, for example, and you just have to change the first line of the file and say, now it's typed, and that's it. So any language can become typed using racket, yeah. Thank you, Jero. Thanks.