Transcript of remarks given at RacketCon, 18 Sept 2016
I want to thank all the people who have been using Pollen in the last year. We have a tiny, ultra-tiny user community. But, like a lot of fun projects, it’s so neat to make something and then see other people make things with it that you didn’t necessarily expect.
And I brought one. Because it fit into my briefcase. This is the book Flatland. It’s not actually about Racket’s first family. It’s a novel: “A Romance of Many Dimensions.” But a gentleman named Joel Dueck up in—sorry if I get this wrong, Joel, I think you’re up in Minnesota—used Pollen to make this. He made a web version and he made a PDF version. And then he sent the PDF version to CreateSpace to make paperbacks. And he did this all from one set of Pollen sources. Pollen being this DSL that I created to do digital books.
And what’s fun about this for me is it’s such a great idea to see—what I was hoping for, to have one set of source files that you can do web and PDF with. I haven’t actually done it yet! So thank you Joel. Pass that copy around if you like. Again, that’s all Racket-generated product.
Right, so I’m here to talk about Beautiful Racket. Where are the slides? Well, you have laptops. So if you have a laptop or phone or you want to follow along at home, please go to beautifulracket.com.
Beautiful Racket is a book I’m writing about making DSLs and languages with Racket. What is at beautifulracket.com right now is a sort of initial excerpt, which shows all the major sections. You can start looking at it while I tell you a few more things about what I’ve been up to.
Because I actually was speaking with my man Oliver Flatt last night. At the bar, where I speak to a lot of young people. And he was saying “I heard that you’ve pretty much spent the whole past year programming Racket.” And I said yes, that’s true. I decided, after last year’s RacketCon, that I was having such a great time with Racket, and learned so many things, and been so productive—what would happen if I just set everything on my schedule aside and did nothing but Racket? And Beautiful Racket is the major project that I’ve been working on.
And he was very curious. And he said “So you haven’t been going to a job?” No. “You haven’t been going to school?” No. “You don’t have students?” No. I just do Racket.
And he said, “How do you pay for this?”
I thought, this is a fellow after my own heart. I said, “that’s the great thing, Oliver. I’m paying for it with Racket!”
Now he’s very interested.
As he should be. I said yes, I’m totally a pro Racket programmer. Because the first thing I made with Racket—I mean, I made Pollen in order that I could make Practical Typography, which you’ve all heard about. Which is this website that offers hints about typography. It offers hints about slide presentations. I don’t know, if anybody here has to do a slide presentation ... ? I don’t know, you might go on this free website.
And there are fonts for sale. And people buy the fonts and they send me money. So every day, the internet sends me money. And all I’m doing is working on Racket. So it’s a great setup: Racket project #1 is spurting all this money that then allows me to work on Racket project #2. So if you can make it work for yourself, great. I’m living the dream.
So, why Beautiful Racket? You know, this RacketCon’s actually really exciting to see, because it’s nice to see so many talks about making DSLs with Racket. I feel like this is the highest concentration yet. Because that’s really—I mean, for me, I came to Racket wanting to write a DSL. For whatever reason, I had the genetic mutation already. And I actually prototyped my DSL in Python. I mean, that was a garbage way to do it. But the fact that I was out there, trying to make a DSL—you know the old adage: when the student is ready, the teacher appears. I was ready for Racket. So when I discovered it, I thought yes, these people have figured out everything I’m trying to do. Just much better.
So I’m trying to take what I learned on Pollen, and that experience, and put it into this book form. And the book really has two purposes, when I’m speaking of Beautiful Racket.
On the one hand, it’s meant to be a tutorial of both Racket as a language, and as a way of making languages. And to that regard, if you’re on the website, you can see that there’s going to be a set of tutorials that go from simpler to more complex, introducing the key language-making features.
And then there’s also a set of what I call “explainers” that are short overviews of certain key topics in the Racket language. Because I still remember what it was like to be a total Racket newbie. I have all the questions that I wrote down and struggled with. So it’s almost like the book that future me wants to go back and give to past me—if only I had continuations in real life.
A lot of the book links back to the documentation. Our documentation is wonderful. But it’s almost just to give more of an on-ramp for people who are new to the whole concept.
Because a question that I asked myself when I was starting this out is “what is a DSL?” Matthias [Felleisen], in his Racket Manifesto, has given us a technical answer. But I really appreciated what Emina [Torlak] had to say this morning, because I thought I was going to be the only one to say it. Now the keynote speaker agrees with me. That’s so much better.
She was talking about how a DSL is a way of taking domain-specific knowledge and packaging it inside a programming language. And I think that really encapsulates something important, which is that a DSL has two ingredients:
One is the programming. But whatever, we’ve got a lot of programming already.
The other is this domain-specific knowledge. Which is really actually special and hard to come by. And the idea that there are—Emina gave us a lot of examples—all these people out in the world who have domain-specific knowledge, and of course, what they do touches computers and languages. And the idea that they could take that knowledge, and put it into DSLs, is really interesting.
And the thing I think is especially interesting is that these people with the DSK, I’ll call it—the domain-specific knowledge—they’re not necessarily the professional programmers that you’re going to find on the streets of San Francisco, bragging about the stock options they got in the new iOS app that—god knows what it does. The point is, that’s a different kind of programmer. Those are the brogrammers. They’re about snapping necks and cashing checks. They’re about whatever’s trendy. Domain-specific knowledge—they don’t have any domain-specific knowledge! They don’t know anything. I mean, they know about programming. But that’s not what we mean. We’re talking about being able to bring knowledge from another area, and bring it into a DSL. Which is such a powerful thing.
And it’s part of what has made Pollen successful. Hey—I am not on your level as a programmer. I am not. But I have a lot of domain-specific knowledge about typography, and design, and how writers and people who publish things want to work with their material. And that’s really where all the important ideas in Pollen come from. To see that I can take it, and as Emina said, package it into a language, turn around, and share it with people and document it. And you get things like [the Flatland book] you see coming around. People really get it. And that, to me, is very satisfying. And that’s really the experience I have: of sharing the knowledge, and seeing people say “oh yeah, the way this dude sees the world is a good way of doing things.”
So to go to the next question about who is Beautiful Racket for. I think the idea that Beautiful Racket can be for people who have that domain-specific knowledge. Right? Not necessarily professional programmers. I mean, if they want to come in and learn how to do DSLs, and bring it back to their iOS app—that’s great. But I really want to see—I would love to see more lawyers, and scientists, and accountants, and psychiatrists, whoever—who are dealing with this domain-specific knowledge—come in to Beautiful Racket and start saying “oh yeah, I see how to do this and why.” Again, a big part of the book is going to be making the case for DSLs.
Now that said, because I’ve been spending a lot of time looking at the DSL apparatus. Racket has a lot of good features. Wonderful features, really. But then there are some little gaps along the way where if you’re a newbie, you can get your shoelace trapped. And I’m trying to sort of smooth over some of those things.
Like the fact that we talk about how Racket’s main feature is that it lets people make other languages. But that’s not really the lead message. It’s not the lead message on the website. Or in Realm of Racket. Or in How to Design Programs. So Beautiful Racket is really putting the language-making front and center. And putting the fun stuff too. Trying to get people into making languages quickly.
Another part of Racket: we have tutorials in the documentation. They’re very clear. And they’re very good, in a certain sense. But they don’t help you make languages. The initial tutorial about drawing stuff. There’s a tutorial about doing a blog engine with the web server. Again—it’s a great tutorial. But Racket isn’t really going to compete in the web-server and blog-engine space, is it? It’s going to compete in domain-specific languages. So, again, just wanting to bring that forward for people who are new to Racket.
What else? Here’s one that’s been a kind of vexing issue for me. Which is that—and you’ve seen a little bit of this today, and Alexis [King] touched on this—is that DSLs based in S-expressions snap together really easily. But once you venture outside of S-expressions, and you start hacking on the reader, and having to deal with a parser—the road gets a little bit bumpy.
And I’ve had to spend some time going back, and try to find a coherent way of explaining this to people new to Racket. I don’t think, for instance, it’s OK to say “oh, and then you write a parser by hand. Whatever you feel like doing is fine.”
So I discovered that our friend Danny Yoo—who originally made a fun tutorial for the bf language, which I repurposed for Beautiful Racket. He also did a neat DSL called ragg. Which was his “Racket AST Generator Generator.” It’s a parser generator that will take a BNF grammar and turn it into a parser. So I took his work and I forked it and I added some improvements to it. And that’s what I’m using in Beautiful Racket.
Again—there are upsides and downsides to using a parser generator. But I’m trying to show people the easiest path. It also lets you introduce the concept of a grammar to people who might not know about it.
Another place that I’ve had a little bit of trouble is with hygienic macros. Now, we love macros. We love hygiene in macros. It’s great. But sometimes you need to do unhygienic identifiers. And most of all, you sometimes need to do them when you’re making DSLs. Right? Because you want to be able to type in identifiers onto the REPL, or into a definitions window [in DrRacket], and have them behave as if they were defined there. Which is what an unhygienic identifier is. So I think that the interface and the explanation of how to break hygiene smoothly and efficiently is a little bit clunky.
And I know that Matthias [Felleisen] is probably saying “hey, use syntax parameters.” They’re great. But you need to know the name of a syntax parameter in advance. And again, if you want to do a language, like—one of the tutorials in Beautiful Racket is going to be a BASIC interpeter. Because who doesn’t love BASIC. But you want to be able to do
10 LET _ = 42
And just have anything in the blank. If it’s a syntax parameter, you have to know the name ahead of time. So that’s another example.
So that’s really it. The Beautiful Racket website—you can click on any paragraph—I’m kind of relying on Cunningham’s Law here. Have you heard of it? It says that on the internet, the fastest way to get the right answer is to post the wrong thing, and people will correct you. Click on any paragraph and there’ll be a comment form. So if you see something you don’t like, I invite you. You don’t even have to put your email in. You can just type the nastygram. I don’t know who you are. But I’m saying there are plenty of things that could be improved.
I mean, obviously I’m trying to find a balance here. There are certain aspects of Racket where I’m trying to stash some of the dirty details for later. Because again, the documentation is wonderful. That is a challenge too: to figure out how much to conceal at any point, and how much to show.
But this is where we are after eight or nine months. I think there’s another three or four months. There are more sections to come. There might be a couple special guests making an appearance.
But again, I thank everyone for this wonderful community. And really, this project is a tribute to everything that you have taught me. And it’s way that I can give it back. And I hope to bring more people into the fold so we keep hearing about all the great DSLs. So thank you.
Question from Matthias Felleisen: I want to talk back, because I think you’re wrong about one small point.
MB: Could be a big point. Fill out the form!
MF: Unfortunately, I would have to fill out all the forms. It’s pervasive. And it’s the following. I think domain experts want to achieve something with their knowledge. They just don’t want to write out the knowledge and then it’s there, and it’s inactive, passive, stuff on the web. They want to hook up to web services. And they want to distribute to many users of domain knowledge, [for instance] at a remote hospital. There’s a doctor somewhere who puts down his domain knowledge [in one place]. But it’s really for people somewhere else.
So you really need a real programming language underneath that can do all the things that Racket can do. And Racket is as good as any other language. (If it’s not as good, you guys didn’t contribute enough libraries. It’s your fault.) We really need the other piece of the manifesto too. It’s really a full-spectrum language. You can do anything you want with the domain knowledge that was encoded in DSLs.
MB: Where do we disagree?
MF: You said, these domain experts don’t want web services.
MB: Oh, I’m sorry. I was unclear. What I was saying was, for instance, when I look at the Racket web-server tutorial, or the blog tutorial—that’s not the special, valuable thing that Racket can do. I totally agree with you.
MF: We don’t disagree.
MF: So now I’m going to end with a challenge. And that was the first picture in the manifesto. And that is: if you’re a lawyer, or a doctor, with domain knowledge—they need to interact eventually. And we have not really figured out how DSLs talk to each other. We can kind of do it manually—A is like X. Or descend into the common language of English. But that’s a manual process. Can we do better? For those of you who do research, for those of you who want to do research, for those of you with nothing else to do, and if you have spare cycles—that’s a problem.
MB: We need more books on Racket. That can be Beautiful Racket 2. I’ll license it. There you go.