A Computing Education Research Perspective on Programmable Programming Languages

When the March CACM appeared in my mailbox, my monthly Blog@CACM post wrote itself. The cover story is an important idea with significant education implications.

The article that inspires the cover art is A Programmable Programming Language (link here) by  Matthias Felleisen, Robert Bruce Findler, Matthew Flatt, Shriram Krishnamurthi, Eli Barzilay, Jay McCarthy, and Sam Tobin-Hochstadt. The authors describe the work that they do with Racket where software developers design and re-design the programming language itself to match the problem that is being solved.

In the ideal world, software developers would analyze each problem in the language of its domain and then articulate solutions in matching terms. They could thus easily communicate with domain experts and separate problem-specific ideas from the details of general-purpose languages and specific program design decisions.

By "language," we mean a new syntax, a static semantics, and a dynamic semantics that usually maps the new syntax to elements of the host language and possibly external languages via a foreign-function interface (FFI).

It’s a fascinating idea, and the article does a good job playing out the issues and possibilities. I’m particularly taken with the explanation of how types play an important role in specifying the new languages. The authors have thought a lot about how a language can usefully constrain and facilitate programmers’ work to improve problem-solving and productivity.

To fit into CACM, the paper is necessarily short, so not all the issues are laid out. I know that the issues of education are important to these authors, so I’m sure that they’ve thought of them. In fact, I know from discussions with Shriram that these ideas started from their work in education with DrRacket. The team wanted to define subsets of the language that were easier to teach, and generalizing that idea led to this work. They’ve likely thought of the issues that I raise here.

Programmable programming languages have been created in the past. Smalltalk-72 objects could re-parse their input. The language included an "eyeball" character in methods that could look ahead in the token stream to parse the rest of the input line. Dan Ingalls wrote in the "Smalltalk-80: Bits of History, Words of Advice" that this made Smalltalk-72 difficult to grow. The programmer was challenged to design a new language that could be understandable by others. How do programmers afterwards know the context and thinking of the programmer who implemented this language? How do they learn "Smalltalk-72" when it's really an umbrella for a bunch of different languages? This modern work is richer for thinking about developing new programming languages for particular problems, but the educational issues are still there. How do we teach students problem-specific programming languages?

Programming is not just about problem-solving.

• Programming is a job skill. It is hard for students to learn programming. Students often learn a particular programming language to get themselves jobs. Are problem-specific programming languages easier to learn? Will some become so popular and so useful that it’s worthwhile (from a job perspective) for a student to learn a problem-specific programming language?
• Programming creates infrastructure. Programming is like wires and sewer pipes. They are the infrastructure for our world. There are large systems still in use today that are written in Cobol and PL/1. And we still have to maintain that information infrastructure. Does creating more languages in problem-specific forms make it harder to find enough existing programmers who know infrastructure built in these problem-specific forms? Is it harder or easier to train new programmers to maintain that infrastructure?
• Intellectual property is embodied in programming. Programs are intellectual property. I wonder how programmable programming languages change the way that we define intellectual property in software. When intellectual property is defined in terms of thousands of lines of code, IP can’t be easily carried away in someone’s head. But when the IP is in the language, which can be learned and carried in a single person’s head, the definition of what’s protected and what was just learned seems complicated. If a programmer moves from Company A and Company B, and that programmer has learned the problem-specific language in Company A, and then re-implements it in Company B, was intellectual property stolen?

I love that this article makes all of software soft again. Everything is malleable, down to the programming language itself. As an education researcher, I know that learning programming is a struggle. New problem-specific languages may be increasing the challenges for computing education research. Because of the value of these kinds of languages, the new and interesting research questions raised are worth investigating.