Little Languages Review

It's surprising to think that Jon Bentley published this paper in 1986.  It feels current to me today and, as I think back over my education and career, current for each stage of my discovery of computer science.

On my first read, I take three main sets of lessons away.

Little Languages
 
First are Bentley's explicit lessons about little languages.

Bentley motivates little languages from several perspectives:

1. A powerful way to accomplish specific tasks (like drawing pictures) that you need to accomplish, if someone else has done the work for you.  I need to do a better job of taking advantage of such things!  (Up front, mostly p711-713.)
2. A framework for describing data for use in your own systems, including quite varied purposes for the data, which is powerful yet accessible to your users.  (Point mostly made in the sidebar, p714-715.)
3. A technique to create abstraction layer boundaries in multi-layer systems (including compilers).  (p716-719)

Each of these is a profound example of the impact of languages on our tasks as programmers and users of computers.

Powerful Programmers



Next up in my three main lessons is renewed respect for Jon Bentley, the colleagues he discusses, and generally for effective programmers.  A virtuoso programmer, armed with tools like the ones Bentley describes in his column and books "Programming Pearls", can accomplish more than a pedestrian programmer in (orders of magnitude) less time.  I consider myself a pedestrian programmer, but I do strive to learn new ideas, techniques, and tools to improve my capabilities.

Bentley's column describes some tremendous tools, though dated, on the UNIX system that might increase a programmer's productivity, but his most important point is the concept that we should watch for how to design, exploit, and stitch together little languages to help us and our users accomplish tasks.

I fit this lesson into my understanding of programming along with the "laziness principle" my grad school friend Greg Badros explained to me.  Laziness taken to its extreme is a virtue for the programmer.  That extreme is never to redo work when you can write a program (or create or use a language!) to do the work for you!

Community of Design

The third point I take from the article is the importance of our community to our creative process.  Bentley comfortably weaves the collegial process that led to his ideas and designs with the story of the systems themselves.  Particularly telling is the story on p717 of Bentley and Kernighan designing CHEM in tandem with chemist Lynn Jelinski.  Bentley and Kernighan would never have envisioned the problem without Jelinski.  Jelinski would never have conceived of the type of solution B&K designed, nor its power.  However, working together through a few rounds of iterative design, they created an impressive tool as a team.

Appendix: Formatting Note and a Few Quotes 

Note that the sidebar on pages 714-715 is not visually distinct from the text in the PDF.  It includes all of page 714 and the left column of 715.

Here's three quotes I grabbed from the paper.

The thesis, from p711:

Languages surround programmers, yet many programmers don't exploit linguistic insights. Examining programs under a linguistic light can give you a better understanding of the tools you now use, and can teach you design principles for building elegant interfaces to your future programs. This column will show how the user interfaces to half a dozen interesting programs can be viewed as little languages.

The heart of the argument for understanding more powerful underpinnings of language when creating (and perhaps using) a little language, from p714:

When I first designed the program, I sketched half a dozen bells and whistles before I realized that such was the way of folly: I could never anticipate all the options a user might desire, and any program that dealt with all options would be a rat's nest of code.

I therefore looked for a general mechanism that could handle the problems...

One core idea: letting systems designed for particular tasks do what they already do best (from p715):

I finally made progress by abandoning the interactive approach and thinking about the problem as designing a little language to describe surveys (and leaving the editing to the system text editor!).