A recent discussion got me to take this book off my shelf and give it a reread, and I found I got more out of it than I did on my first reading almost ten years ago.
To give away the ending up front: Bonnie's thesis is that allowing end-users to write their own applications requires task-specific programming languages embedded in appropriate visual frameworks and in collaboration with others.
The author's background, before writing this book, was in two academic studies, one of spreadsheet users and a second of CAD users.
Task-specific programming languages
The book begins with a couple of chapters rebutting ideas that apparently were common in the '90s (and may still be so in the general population), but I think we don't need convincing of them (particularly since we have almost thirty years of hindsight), so I'll just mention them and move on.
- "Intelligent agents will soon exist to just do what we want."
- "People should program computers using natural language."
The emphasis of natural language stems from fear of formal systems. In fact, people engage with formal systems all the time. Baseball scorecards. Knitting patterns. Following the rules of a game or sport. The book describes several others.
If formal languages aren't the bottleneck to learning programming, what is?
- Interest. People only care about formal systems when they have an _immediate_
interest in the relevant domain.
- The number of building blocks isn't too large.
- The building blocks are composable. [Not the word Bonnie uses.] You can do
a lot with _small_ combinations of building blocks.
Commentary
A well-designed task-specific language can't be at the topmost layer of abstraction, because there the goal is very specific and concrete. It also can't be at too low a level of abstraction, because then the distance to the domain of interest is too great, and motivation falls away. So the picture the book paints in my mind is one of limited reach:
"easy to make"
primitives
Computer stacks have lots of layers. There's room for multiple such task-specific languages at different levels.
How to choose good building blocks? You have to understand in great depth the universe of tasks some target community of people want to perform. Bonnie outlines research in 2 areas that helps with this process:
- Activity Theory
- Distributed Cognition
I haven't heard much elsewhere about these, so it's not clear how well they've aged in the past thirty years.
Commentary
Designing a task-specific language seems like a _lot_ of work. Is it possible it would be less work if our computing stacks were designed differently? Better, more parsimoniously, making it easier for programmers to bounce between levels? Then we wouldn't need a huge amount of up-front research. We could draw multiple candidate lines through the stack, build something for them, see if people come. Adjust the lines based on feedback.
Visual Frameworks
Once again, this section begins by rebutting some competing ideas:
- Visual rather than linguistic notations. The book rebuts claims that they're
more natural, and that they obviate the need to learn syntax. The book also
claims that limited screen space is a challenge. [I wonder how that situation
has changed with larger monitors.]
- Form-based systems. Too special-case, usually work only for a rigid class of
problems thoroughly anticipated by designers. Again, they're found to be less
dense on screen than text.
- Programming by example modification. Key challenges: scaling the corpus of
example programs, and making sure people start with the right example for
a given goal. Can people truly understand the programs they create this way?
- Programming by example. Key challenges: representing termination conditions
and branching. General difficulty of designing such systems [but isn't that
true for everything in this book?]. Confidence in generated programs is low.
Getting a good signal on intention is hard, because intentions fluctuate over
time. [Learning regular programming seems to be at least partly about learning
to control intentions, and being deliberate about 'scope creep'. If people
need to learn this, are we really simplifying anything?]
- Informal program specification. Again, programs created in this manner tend
to not be very trustworthy and therefore not very trusted. It's easy to ignore
fundamental problems early on, later requiring extensive rework. [Learning
programming seems to be at least partly about throwing away drafts and
starting over. That's a difficult lesson to learn, psychologically.] Don't try
to avoid the iteration process.
The crucial distinction between the above ideas and the book's notion of "visual framework" seems to be that you're still programming in text, but embedded in some new visual metaphor. Examples [leaning into the author's background]:
- Spreadsheets
- Logo
- CAD systems
Again the book identifies drawbacks of each system (interestingly, Logo gets zero drawbacks but quickly passed over), and suggests programs of work for each. [How's this different from the state of competing ideas? This section seemed weak.]
Collaborative Work Practices
[I couldn't get through the final section because of fundamental unquestioned assumptions of the way work must be structured that caused me to break out in hives. I'm sorry. It seemed waffling to the extent I read it, for what that's worth.]
Comments gratefully appreciated. Please send them to me by any method of your choice and I'll include them here.