Boxer

Boxer is a programming language and environment that its designers called a “reconstructible computational medium”. Andrea diSessa and Hal Abelson started it at MIT in the early 1980s as a successor to Logo, and from 1985 it was developed at the University of California, Berkeley. In Boxer, everything is a box: a region of the screen that can hold text, graphics, programs or other boxes. Variables, procedures, records, sprites and whole documents are all boxes, and the position of a box on the screen shows where it belongs in the program. The aim was a medium that ordinary people, from children to teachers to adults, could read, change and extend in the way they use written language. Boxer never reached the mass audience its authors hoped for, but it influenced later thinking about live, visible programming for learners. Its original code is still being developed as the open-source Boxer Sunrise project.

History & Origins

From Logo to Boxer at MIT

diSessa and Abelson both came from MIT’s Logo work. Together they had written Turtle Geometry: The Computer as a Medium for Exploring Mathematics (MIT Press, 1981). According to Leigh Klotz’s 1989 MIT thesis, the two “formed and headed the Educational Computing Group, in the Laboratory for Computer Science, at M.I.T., where the Boxer project was centered from 1981 through 1985.” Klotz, who worked on the language from 1983, also records its earliest implementation:

“The first language implementation of Boxer was done in 1981 on an MIT CADR Lisp machine, with the editor and compiler both developed by David Neves. The compiler was a Boxer-to-Scheme translator.”

Other early contributors named in the thesis and papers include Eric Tenenbaum, who wrote a Boxer-to-Lisp compiler that produced native Lisp Machine code; Gregor Kiczales, who worked on the variable mechanism and the editor’s redisplay algorithm; Jeremy Roschelle, who wrote an undergraduate thesis on Boxer’s graphics system; and Michael Eisenberg and Ed Lay. In diSessa’s 1985 paper Abelson is credited as “co-founder of the Boxer project.”

diSessa later summed up the motive in a 1997 paper, “Twenty Reasons Why You Should Use Boxer (Instead of Logo)”: the design “emerged over a dozen years ago, from within the Logo project at MIT. It was an attempt to design a successor to Logo, capitalizing on all we had learned using Logo with children and teachers.”

The founding papers

Boxer’s first full published description was diSessa’s “A Principled Design for an Integrated Computational Environment”, in the first issue of the journal Human-Computer Interaction (volume 1, 1985, pp. 1–47). The journal’s editorial record shows the manuscript was first received on 7 January 1983 and in final form on 27 August 1984. The paper describes “our prototype system, built on a Symbolics 3600 Lisp Machine.”

The best-known paper followed in September 1986: “Boxer: A Reconstructible Computational Medium” by diSessa and Abelson in Communications of the ACM (vol. 29, no. 9, pp. 859–868). It stated that “Boxer currently exists as a prototype, including all of the features described below, implemented on Symbolics and Texas Instruments Lisp machines,” and that the team was “about to start implementation on a more modest machine.” The work was funded by the National Science Foundation and DARPA.

About the year. The encyclopedia master list gives 1984. That year matches the final manuscript of the HCI paper, but it is not when Boxer first appeared. A participant’s account (Klotz 1989) puts the project’s start and first implementation in 1981, and the first published description appeared in 1985. This page uses 1981.

Berkeley and the Macintosh era

In 1985 the project moved with diSessa to the Division of Education in Math, Science and Technology at UC Berkeley’s School of Education. By January 1989 Klotz could report that Boxer “has been implemented in Common Lisp on Symbolics 3600, Sun, and Hewlett-Packard computers.” Klotz had rewritten the interpreter as an explicit-control evaluator so that a stepper and a debugger could inspect its state.

Boxer later moved to the Apple Macintosh. The Boxer Manual V2, first compiled by Rafael Granados in September 1994 and revised in December 1999, covers “Berkeley Macintosh Boxer”, which is “implemented with Digitool Macintosh Common Lisp.” By then the University of California had assigned its copyright to diSessa and Edward H. Lay. The software was free for educational, research and non-profit use, and diSessa’s 1997 paper lists “It’s Free!” among its twenty reasons.

diSessa set out the ideas behind Boxer at book length in Changing Minds: Computers, Learning, and Literacy (MIT Press, 2000; often cited as 2001).

Design Philosophy

The 1986 CACM paper argues that “within a generation, programming will also be a part of the everyday lives of many people who do not have expert programming skills,” and that languages for such people must be designed differently. It explicitly downgrades several traditional goals of language design:

• Formal simplicity: “A better criterion is accessibility to a seven-year-old child.”
• Efficiency: “If present-generation machines are not powerful enough, we can wait for the next.”
• Verifiability and uniformity are also treated as secondary.

In their place the paper puts understandability, direct usefulness for everyday tasks, ease with small tasks, and rich interaction. Two principles shape the design.

The spatial metaphor

“All computational objects are represented in terms of boxes, which are regions on the screen that contain text, graphics, or other boxes.” Containment on the screen means containment in the program. A procedure’s internal subprocedures are boxes inside it, a record’s fields are boxes inside the record, and entering a box by moving the cursor into it gives access to what is defined there. The CACM paper credits MIT architecture department work on spatial data management as an encouragement for this approach.

Naive realism

This extends “what you see is what you get” to programming: “users should be able to pretend that what they see on the screen is their computational world in its entirety.” Any text on screen, whether the system printed it or the user typed it, can be edited, moved or, if it is code, run. If a program changes a variable, the variable’s box updates on screen. If the user edits the box, the variable changes. There is no hidden workspace to query.

Key Features

Kinds of boxes

According to the Boxer Structures guide (diSessa, 1994–2021), the main kinds of box include:

Every box also has a closet, which the guide describes as “an invisible first row that you can make visible when you want to see it”, used for definitions a box needs but does not normally show.

Procedures look like Logo

Simple Boxer code deliberately looks like Logo. The 1985 paper’s example is a polygon procedure. On screen it is a box named POLY with a data box LENGTH in its local library. As plain text:

1
2
3
4
5

POLY:
  INPUT NUMBER
  REPEAT NUMBER
    FORWARD LENGTH
    RIGHT 360/NUMBER

(Plain text cannot show the nested box borders that are Boxer’s actual notation. The indentation here stands in for them, and the syntax of the 1985 prototype differs in detail from later releases.)

The 1999 manual documents the core commands in this Logo-like form, for example repeat <number> <action>, if <condition> <action> <optional-alternate-action> and for-each-item <variable> <data box> <action>.

Variables are boxes you can see

Because a named data box is a variable, input and output often come for free. The CACM paper’s PHONE-BOOK example has a NAME box, a NUMBER box and a database box LIST of records. A procedure bound to a function key loops over the records:

1
2
3
4

function-1-key:
  for x in list
    if x.name = name
      change number x.number

This follows Figure 3 of the paper. On screen, the if line and the line under it sit in a box nested inside the for line. The figure prints x.number, but the record’s field is labelled phone in the same figure, and the paper’s text says the NUMBER box is set from “the corresponding PHONE field.” The published figure itself is inconsistent here. The user types a name into the NAME box and presses the key, and the number appears in the NUMBER box. Dot syntax (x.name) selects a named sub-box. The manual defines change <box> <new-box> as replacing a box’s contents, and notes that the box’s closet is deliberately left unchanged.

Scope is containment

Definitions are visible inside the box that contains them and in the boxes nested within it, but not outside. The manual explains lookup this way: Boxer “looks for that action or variable starting in the box you’re currently in. If it doesn’t find the variable, it looks in the box that contains the one you’re in, and so on outward.” The CACM paper presents this as the computational notion of scoping made to match the everyday idea of “inside.”

Objects and message passing with tell

tell <box> <action> (with ask as a synonym) runs code inside another box. The CACM paper’s example has two sprites, Minnie and Mickey, each told to draw the same STAR procedure. They draw different shapes because each has its own local STEP procedure. The paper links this to object-oriented programming as popularised by Smalltalk, with the difference that in Boxer the object’s structure is visible as nested boxes.

A reconstructible interface

Users can rebind keys and mouse clicks from inside Boxer. In the 1986 paper, a procedure named FUNCTION-1-KEY is automatically bound to that key, but only while the user is inside the box that defines it. The Boxer Structures guide also covers triggers, redefinable box icons (“boxtops”), file boxes that load their contents on demand, and a build command that constructs new boxes from templates.

Implementation

Klotz also describes some of the internals. The 1980s evaluators used deep binding for variables on the Symbolics 3600 “both for portability and for context switch speed.”

The Boxer Sunrise README says current builds use LispWorks 8.0 and have been tested on Intel Macs (macOS 10.14 to 12), Apple M1 Macs (macOS 11 and 12) and x86 Windows 10, with Windows still needing further testing. It also records that the Linux version of LispWorks “runs out of heap when loading Boxer.” The project website offers the macOS build as the current release and describes the Windows 10 build (last issued as 3.4.15 in October 2023) as “highly experimental.”

Evolution: Boxer Sunrise

After the Macintosh era Boxer went through what the project website calls “a period of dormancy.” In November 2019 Steven Githens began Boxer Sunrise, bringing the historic Lisp source into a public repository one file at a time. On 29 January 2020 the code was released under the BSD 3-Clause licence, copyright “Andrea A. diSessa and the Estate of Edward H. Lay.” Version 3.4.0 was released on 6 October 2020, and alpha builds have followed every few months since.

Recent release notes describe a large refactoring:

• 3.4.24 (22 August 2025) separated rendering and platform-specific code. It enabled prototypes of a headless text-only Boxer and a Boxer core compiled with ECL as a C/C++ shared library. Proofs of concept used it with three.js in a web browser and with the Godot game engine.
• 3.4.28 (31 August 2026) continued work on the Godot front end, added video primitives (open-video, pause-video, seek-video and others), and bound a new search toolbar to Command-F.

Each release is labelled a “very alpha development in-progress release.” Separately, Bruce Sherin has described building a web-based JavaScript/React reimplementation, BoxerJS, in a 2022 paper.

Current Relevance

The encyclopedia master list gives Boxer’s status as Historical. That describes its classroom role: Picciotto’s school stopped using it in 2007 and moved to Snap!. It does not describe the software, which is still being developed. The Boxer Sunrise repository received commits in September 2026 and made its most recent release on 31 August 2026.

Boxer’s ideas are also still discussed in computing education. In 2022 the conference hosted a Boxer-themed Convivial Computing Salon. Mark Guzdial wrote there that his group’s “Teaspoon languages owe a design debt to Boxer.” Chris Hancock described his later Tertl Environment as “a broader, more Boxer-like elaboration” of his real-time programming work. Henri Picciotto gave a candid teacher’s view: Boxer made variables and program structure visible in a way Logo did not, but by the mid-2000s students used to standard laptop software “hated Boxer,” and his school switched to Snap!.

Why It Matters

Boxer was one of the most thorough early attempts to answer the question of what a programming language designed for ordinary people, rather than for professional programmers, should look like. Its answer was a medium rather than a language: no hidden state, one uniform structure (the box) for code, data, documents and interfaces, and programs that users could open up and modify. Several ideas that later became familiar in educational and live programming environments appear in Boxer’s 1985–1986 papers: seeing and editing live variable values, direct manipulation of sprites whose properties are ordinary variables, making scope visible, and letting users rebind their own interface.

Boxer is also an unusually well-documented case study in what makes such systems succeed or fail in schools. The same researchers who designed it have published candidly about where it worked, such as sixth-graders building physics simulations and teachers building their own tools, and where it did not.