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.
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.
Having been developing software for over 40 years, using 15 different languages. I have come to the conclusion that while it is great to have domain specific languages, having a common syntax makes the use and take up of the languages much easier.
For example, C syntax that has been around since the 1970s, has provide the based for other commercial languages, like C++, objective C, C#, using to these languages is must easier as you do not need to learn both the syntax and the language features and functions.
That's a fair point, but the advantage of the common syntax only comes once you pay the price of learning the complicated C syntax. For novices, forms like the "for" loop in C are a significant cost and a barrier to learning. We have evidence that the block-based languages and Lisp-like S-expressions are easier for novices to learn. There's a trade-off here.
Displaying all 2 comments