How Scripting Misses the Mark

I earned a computer science degree from a decent university called MIT. And I am constantly frustrated when I try to use my programming skills and knowledge to make my everyday life easier. My life is full of scripting languages that promise easy automation, but disappoint me after painful hours of guessing and debugging.

Recently, I attended a conference workshop on a wonderful innovation from MIT in the 1980s, a learner-centered programming language called “Boxer.” Boxer was designed to supersede the learner-centered programming language Logo, and distinctively was designed with understandability and learnability as top goals.

During the workshop, presenters reviewed the history and legacy of Boxer. Principles that make a programming language more learnable came were highlighted. For example, Boxer uses the metaphor of nested, on-screen boxes to organize data, code, graphics, and more.  This is shown below in a graphics data box that contains two “sprite” objects, each with state variables. In addition, the first sprite contains custom code to change its shape from the default shape to a square.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The principle of naive realism appears, for example, in how variables are presented as named boxes that contain data. If a user directly edits the text in the box, the variable’s value changes. For example, changing x-pos to a different number moves the sprite visible in the graphics presentation box. Also, if the user executes a line of code that changes the variable’s value, the value displayed in the box changes. A user who executes “forward 30” to move a sprint forward by 30 pixels can see how this affects the xpos and ypos variables. Thus the learner can treat named boxes as if they really are the variables that explain the system.

The principle of spatial metaphor uses the containment of boxes within boxes to explain difficult-to-grasp programming concepts, like variable scoping. There can be two variables each named “xpos” on the same screen at one time without a problem, such as the presence of “xpos” in two different sprites. In another example, one “x” may be within the outermost box and thus serve as an “environment” variable; another “x” may be in an executable box and its “x” would be a “local” variable. In my experience, it is pretty easy to explain to a learner when each “x” is relevant by the simple rule “look for the variable first in the box you are in, and if you can’t find it there, look in the box that contains the box you are in.” Spatial metaphor also organizes complex data and code. Boxes can be fully open or closed, and closing a box can hide the details within the box. Graphics data boxes in Boxer can be hidden when the user no longer wants to see how the code works, and instead want to focus on making an animation on the screen.

While listening to the wonderful presentations, it became clear to me where end-user scripting language have gone wrong. They all accept the  same raison d’detre: human-friendly syntax. For example, on my MacOS computer, Apple has provided me with at least four scripting languages: AppleScript, Automator, Shortcuts and the shell. All of these have simplified syntax, but all are mind-bogglingly difficult to understand and debug—the human friendly code is easy on the eyes, but writing the code requires lots of guesswork because hidden programming concepts are not disclosed to the learner in a comprehensible manner. For example, AppleScript variables are often typed and often must be coerced to a different type to make code work, but there is no support in AppleScript to help me understand the types and the coercions; indeed, AppleScript often only reveals the value of variables, but not their types, leaving me to guess at what coercion might be required. I also experience purpose-built scripting language in home automation systems, such as systems that automate my home’s lights, music, and video. These work for me for the simplest of tasks (e.g., for demos of simple automation) but fall apart as soon as I want to attempt something realistically useful in my life.

What is needed now is on users as learners who construct understanding of their computational world as they interact with their computational environment and try to automate it. For example, the devices in my home are already spatially organized—into zones, rooms, and devices that contain named variables. Howewver, none of the the home automation scripting tools take advantage of this via a spatial metaphor; instead, I have to manage flat lists in awkward list-oriented user interfaces. Flat lists are also used for if-then rules, which makes it maddeningly complex to write useful code. Why not allow the user to use spatial containment to organize the rules within the home zones and rooms they will act upon? Why not support my learning process by supporting naive realism—for example, by letting me try out routines on a visual simulation of my rooms and devices?

We can do better. Let’s stop emphasizing simplified syntax as the most important thing for end-user programming and use principles for understandability and learnability, such as the principles found in Boxer.

Jeremy Roschelle is Executive Director of Learning Sciences Research at Digital Promise and a Fellow of the International Society of the Learning Sciences.