In short, it seems that second-order controls, especially those that do something other than toggle the presence of first-order controls, aren’t very common. Although they can be difficult to implement, I think that many developers and designers are simply not consciously aware of second-order controls and the power they can have.

What do video games and interactive drawings have in common? State. They can be in one of a number of states, and move between them either with time or by human action (i.e. a control). A second-order control affects the state of the state. A button cannot be checked or unchecked if it doesn’t exist. A conveyor cannot have a location and orientation if conveyors are forbidden in this puzzle. The player’s location is affected by the location of the walls and floor. A file can’t have an index in a list of files if it’s not visible to that user. An active reader can adjust a number and see the system react, but the author must first create that number and define its default, maximum, and minimum values. State depending on other state is everywhere.

Therefore, it’s unsurprising that second-order code is quite common. The most familiar example to an office worker would be an Excel spreadsheet with formulae that recalculate based on new input. The Global Forecast System is first-order code, but the code that runs it every six hours is second-order. Many small programs have resource files that contain code that affects how they run. A Makefile is second-order code which controls whatever is being scripted, and if it’s generated by a configure script, then that’s third-order code.

Then there’s the text editor vim. (If you’re not familiar with vim, just skim over this paragraph.) If you consider normal mode commands to be code, then they’re second-order code. dap, delete all paragraph…of code in this file. Therefore the code in my .vimrc is third-order code: it is code that controls code (vim commands) that controls code (in the file). That’s assuming the code I’m editing is the “bottom”; if it’s a configuration or deployment script there may be more layers. And if I use vim to edit my .vimrc then I have a near-loop, with the old version controlling how I edit the new one.

It seems pretty clear that code can control code for as many layers as one likes, at least theoretically if not practically. Having multiple layers of code is frequently advantageous. But so far I’ve only seen controls nested two layers deep. Every example of a second-order control that I know of was itself created with code.

In 1984, Apple introduced the first Macintosh on the premise that computers should learn about people. Now, the Learn to Code movement says that people should learn about computers. I agree that being able to create software is empowering, but it takes a lot of knowledge and effort to get there. Second-order controls don’t offer nearly the power of code, but they are instantly usable by anyone. If coding is like climbing a mountain, second-order controls are like climbing stairs: you won’t get as high, but it’s done by more people, frequently and safely.

I think that software developers can greatly empower the public by providing them with second-order tools rather than expecting everyone to code.