Variable-as-Box vs Variable-as-Name: A Mental-Model Comparison Anchored in Misconception Literature

Across four decades of computing-education research, two competing mental models of variable dominate the introductory programming literature: the variable-as-box model — a named storage location that contains a value, inherited from machine-memory and physics-classroom analogies — and the variable-as-name model (also called variable-as-label, variable-astag, or name-to-object binding) — a name that refers to an object, with the value living outside the name. The literature has not converged on which model produces fewer misconceptions about assignment. This paper synthesises Sajaniemi's roles-of-variables work, du Boulay's notional-machine analysis, Pea's conceptualbug catalogue, Sorva's notional-machine PhD and survey, Caceffo et al.'s misconception inventory, Ma et al.'s mental-models study, Kohn's Python-variable analysis, Soloway-Spohrer's plans literature, Sajaniemi-Kuittinen's role-set teaching work, RobinsRountree-Rountree's review, Holland-Griffiths-Woodman's foundational Avoiding Object Misconceptions — the earliest published call for variable-as-label in Java teaching — and concretethen-symbolic learning literature (Bruner, Goldstone-Son, FyfeMcNeil-Son-Goldstone). The paper delivers three contributions. First, a literature verdict on misconception density: the variableas-box model produces fewer misconceptions at first introduction but more and more durable misconceptions at the moment learners encounter aliasing, list mutation, or mutable-object argument passing; the variable-as-name model produces more misconceptions at first introduction but fewer downstream misconceptions, and the crossover point is the introduction of compound (reference) data — typically list assignment and list mutation in Python. Second, a per-language-family verdict: the box model is durably correct for C primitive variables and adequate for Java primitives but is catastrophically wrong for Python and for Java reference types past the introductory chapter; the name model is durably correct for Python and Java reference types but loads working memory at first introduction in C. Third, a curriculum design proposal: for a Python-first sequence, use a two-stage concreteness-fading instructional design — start with a box-as-scaffold visualisation, then introduce the name-as-target visualisation at the moment of first list mutation, then fade the box visualisation. The design is grounded in Goldstone-Son and Fyfe-McNeil-Son-Goldstone concreteness-fading evidence and in Sajaniemi-Kuittinen's role-set replacement experiment. Per the elix-researches no-cohort scope, the design is described and theoretically validated; deployment is identified as a downstream cohort node responsibility and is out of scope here.