Language-oriented Programming in Racket: A Cultural Anthropology is now available
I’m happy to announce that my latest book, Language-oriented Programming in Racket: A Cultural Anthropology, is now finished & available.
The book is my attempt to dig in to the idea of language-oriented programming, as its understood in the Racket community. The book contains the responses of a 9-question survey I made. 30 seasoned Racket developers, each explaining, in their own words, how they understand LOP, as revealed both in their own work and in the work of others.
Martin Ward, who coined the term
language-oriented programming in a 1994 paper, has written the foreword.
Here are a number of choice quotes from each of the survey respondents:
That kind of gradual development from analmost identical to Racketlanguage to one that has all of the features that you need, and behaves differently (possibly very differently) from Racket—that’s where most of the benefits of LOP come in, and that’s where Racket’s approach shines. (Eli Barzilay)
I’ve always been fascinated with different programming languages and even with the idea of creating my own, but I always saw it, and much of the literature and the public discourse presented it, as some impossibly complicated task not meant for mere mortals. (Annaia Berry)
Racket provides a parser generator library but what makes Racket different as a language building material is two features: (i) its macro system, and (ii) the possibility to override what function application means. (Jörgen Brandt)
I really had no exposure to the idea of DSLs. Rather, I wanted a certain result, and crept up on DSLs accidentally (it just seemed like the most direct way to do what I was after. (Matthew Butterick))
Certain vocabulary emerges out of rudimentary Racket functions. It is like the Racket language is enriched in the direction of game playing, population matching, regenerating, etc. They carry significant meaning outside the defined range of original Racket. (Nguyen Linh Chi)
If the programming model affects the structure of program fragments significantly then a new library is a sub-optimal solution as it introduces layers of encodings. A new language can hide all this and result in concise representations. (Christos Dimoulas)
I saw that I had an upcoming need to write lots of variations of the same kind of program, and wanted to make those programs as human-legible as possible, which means abstracting away overhead tasks and having logical names for things. (Joel Dueck)
I want [my students] to see that there are ‘languages’ everywhere. Sports teams have languages for planning plays; recipes are languages; medical protocols are languages. (Kathi Fisler)
After you use higher-order functions for a while, you’re not willing to go back. Macros are like that, so I think it’s just a matter of time for enough programmers to catch on. (Matthew Flatt)
I find making languages to be the same as normal programming: sometimes is easy, sometimes its hard. And often when its hard its because you picked the wrong design at the start! (Spencer Florence)
I was kind of doing LOP anyway when I create new libraries for people. When I discovered Racket and began researching it, I realized I could create more than just functions for people. I realized I could create new syntax and basically make theshapeof the code be anything I wanted it to be. (Stephen Foster)
Language-oriented programming, to me, means tweaking, augmenting, or changing an underlying computational model—or coming up with a completely new computational model. (Tony Garnock-Jones))
I understand the termlanguage-oriented programmingas an approach to problem solving where, before actually solving the problem, one focuses on expressing this problem in an optimal way. (Panicz Godek)
I’d already gone fromthinking about problems in terms of data structurestothinking about problems in terms of typesand so when I heard Racket was good forthinking about problems in terms of a tailor-made languagethat just sounded good. (Ben Greenman)
Having a common language meant the ops team was free to tweak the model and draft patterns while I bolted a CSV file parser onto a finite-state machine. Without explicit formalism, we solved a complicated problem elegantly by developing a pattern language together. (Eric Griffis)
I think it’s the case that anyone engaged in ‘bottom up’ programming is actively doing ‘language-oriented programming.’ As a result, you can look at virtually any library out there and see a language in it. The types, and functions exported are the primitives used to build up layers of abstraction to form more complicated ideas. (Andrew Gwozdziewycz)
I was always interested in programming languages and liked to learn about new ones, but the idea of realistically making and using potentially many languages never seemed practical until I learned about embedded DSLs made with macros. (William Hatch)
[In Racket] it is relatively seamless to go between the two: to take a ‘library’ and add some ‘language’ behavior to it, or to take a ‘language-enriched library’ and just drop the ‘language parts’. (Shriram Krishnamurthi)
My language design is almost entirely oriented around some sort of optimization that I want to do. I need to restrict the language so the optimization applies then I need to build a language that enforces that restriction. (Jay McCarthy)
I think there are two ways of language-oriented programming. There are the macros you write to make your own code easier, and there are the languages you write for others to use. I’ve used Racket for both. (Pavel Pancheka)
I understood from a long way back that rather than simply ‘coding’ in a given target language there was virtue in bringing the descriptive language to the problem. This can begin with functional abstraction and a ruthless desire to eliminate duplication and boiler-plate. (Daniel Prager)
The correct justification [of ‘homoiconicity’] is that parentheses facilitate careful metaprogramming, the ‘compile-time’ creation of code. And metaprogramming is at the heart of what makes Racket great. (Prabhakar Ragde)
I don’t thinkmaking a languageis a yes-or-no decision: You create abstractions, at some point you abstract over syntax and maybe later down the path you discover that just doing require is awkward or repetitive, which is when you do a language. (Michael Sperber)
The interface was originally provided strictly as a library, but composing using it felt like shoehorning the patterns into a program: quoting, boilerplate, etc. So I built a #lang interface instead. (Vincent St-Amour)
Originally, I thought language-oriented programming was just about using macros to build interesting dialects of Racket, such as Typed Racket or Lazy Racket. But it’s not really about writing dialects necessarily, since the languages people make are often hidden as a tool used to implement some other program. (Asumu Takikawa)
I find Racket’s ecosystem a good proof-by-construction of the feasibility of [language-oriented programming], considering the impressive tower of mini-languages that are used in concert. (Éric Tanter)
The most frequent sticking point is the question of when something is a language versus a library. I adopt a liberal definition of a language that blurs the distinction between the two, as I find that this makes the concept of making one’s own language more approachable. (Emina Torlak)
What’s nice for me about the Racket approach is that I only have to deal with the details of those aspects of the language implementation that I want. If I don’t want to deal with lexing and parsing, for example, I can use the reader. (Jesse Tov)
The particular domain of language construction might be especially amenable to domain-specific languages. (There’s a reason yacc stands foryet another compiler compiler. And yacc is old.) (Jon Zeppieri)
There’s much more than that in the book. There are more than 300 pages of insight, wisdom, frustration, joy, and inspiration.
If these kinds of snippets fire you up to get into language-oriented programming, I think you’ll really like what you’ll find there. Just go here to get your own copy.