Sign In

Communications of the ACM

Contributed articles

A Programmable Programming Language


A Programmable Programming Language, illustration

Credit: Chris Labrooy

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.

Back to Top

Key Insights

ins01.gif

In the real world, however, programmers use a mainstream programming language someone else picked for them. To address this conflict, they resort to—and on occasion build their own—domain-specific languages embedded in the chosen language (embedded domain-specific languages, or eDSLs). For example, JavaScript programmers employ jQuery for interacting with the Document Object Model and React for dealing with events and concurrency. As developers solve their problems in appropriate eDSLs, they compose these solutions into one system; that is, they effectively write multilingual software in a common host language.a


Comments


Eric Nieuwland

In a way this reminds me of the work done by Paul Klint c.s. at CWI in The Netherlands.
See http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.92.6665&rep=rep1&type=pdf

Quite a bit of the effort from over 25 years ago seems to have been repeated.


Matthias Felleisen

Thank you for the feedback. We are well aware of the work at CWI, the "language workbench" approaches, the (commercial) "intensional programming" project from a decade ago, and the ongoing efforts at JetBrain. Racket differs very much from all these projects and none of the work is a repeat of old work.

Since CACM limits the number of citations, we focused on providing in-depth citations for our new work rather than an overview of the entire field. For experts, we recommend studying some of the citations to get a true sense of the Racket approach, which this overview article cannot provide due to its size and focus.


Shriram Krishnamurthi

Thanks for your comment. We've been long aware of, and are long-standing fans of, the work of Klint and others on ASF+SDF as well as its successor systems. The CACM format limits the number of citations we can include in an article, and this is by no means the only such system that merits comparison. We encourage readers to refer to citation 12, which includes many of these successor systems (some of them by Klint's intellectual heirs). Nevertheless, this article is arguing for a rather different system architecture principle than that embraced by ASF+SDF, so none of that work has been "repeated"; furthermore, as the article says, Racket is itself now a 23-year effort. We encourage you to read the article, which will clarify some of these points.


Richard Gabriel

Sigh. The title to this paper comes from John Foderaros introduction to CACMs September 1991 special issue on Lisp, but there is no mention, no acknowledgment, no reference.

Here is a quote from that Introduction:

When Lisp adopts a new paradigm it not only replicates existing practice, but goes beyond it to become a testbed for advancing the state of the art. Why has Lisp been able to adapt so easily when other languages have not? One reason is that Lisp is a programmable programming language. Not only can you program in Lisp (that makes it a programming language) but you can program the language itself.

Here is the reference:

Foderaro, John, LISP: introduction, Communications of the ACM, Vol. 34 No. 9, Page 27
10.1145/114669.114670

Richard P. Gabriel
ACM Fellow & Lisp guy


Matthias Felleisen

Thank you Dick.

With apologies to John, we think of Racket as an heir to Lisp and simply considered it obvious that this article continues the report on the long line of Lisp research. The prose of our article says so, verbatim.

We should have used one slot in our bibliography budget to tip our hat explicitly to John's article.


Richard Gabriel

Matthias: My comment is aimed at prospective authors to encourage them to make the job of future historians easier by maintaining the chains of connection between ideas. I am using your paper as a teaching opportunity.

By choosing A Programmable Programming Language as the title of the paper - instead of Language-Oriented Programming, for example - you and your co-authors have appeared to stake a modest claim to the idea of programmable programming languages. One essay I read on how to write a research paper remarks as advice that the title states the contribution of a paper in one sentence.

I have observed a number of researchers searching for the origin of an idea look for the first paper published in a scientific venue that mentions the idea; in some cases this approach has missed the mark on idea attribution by several decades. Im not a fan of this, and those who follow this practice in tracing back the idea of a programmable programming language could very well stop searching at your paper.

In fact, the idea of a programmable programming language is very old, as you know. Some of the notable - to me - programming languages and programming language ideas originally implemented in a programmable programming language are MicroPlanner, Conniver, KRL, ContextL, Qlisp, MACSYMA, lots of logic programming languages, lots parallel programming languages, and lots of OO languages, like Flavors, CommonLoops, CLOS, and LOOPS. Oh, and another language named Scheme, which was implemented in 1975 in MacLisp by Gerald Jay Sussman and Guy L. Steele Jr. Matthias, I know you know all of this.

The Racket work is wonderful and I love it. The paper does a good job of giving the right amount of credit to its Lispy ancestry. My comment is designed to encourage future authors of technical papers to help historians by suggesting those authors include at least one modest bibliographical or in-line reference to earlier incarnations of an idea when it makes sense to do so - in order to point historians and other researchers back toward the original sources for ideas.


Alvaro Videla

I wrote a critique about the article in the link below. Specifically about the section: "Turn extra-linguistic mechanisms into linguistic constructs", and your note about Sapir-Whorf.

https://medium.com/@old_sound/programming-languages-are-not-languages-c6f161a78c44


Displaying all 7 comments

Log in to Read the Full Article

Sign In

Sign in using your ACM Web Account username and password to access premium content if you are an ACM member, Communications subscriber or Digital Library subscriber.

Need Access?

Please select one of the options below for access to premium content and features.

Create a Web Account

If you are already an ACM member, Communications subscriber, or Digital Library subscriber, please set up a web account to access premium content on this site.

Join the ACM

Become a member to take full advantage of ACM's outstanding computing information resources, networking opportunities, and other benefits.
  

Subscribe to Communications of the ACM Magazine

Get full access to 50+ years of CACM content and receive the print version of the magazine monthly.

Purchase the Article

Non-members can purchase this article or a copy of the magazine in which it appears.
Sign In for Full Access
» Forgot Password? » Create an ACM Web Account