P.S. This question, admittedly less inspiring questions than most around here, arises from the claim of a friend of mine that Ctrl-Z is the best invention in computing since the computer itself.
I'm tempted to point out that Ctrl-Z, while commonly used for an "undo" feature, is just a keyboard shortcut. Back in the CP/M and later the DOS days, Ctrl-Z (or more accurately character 0x1A, often displayed as the bigram ^Z
) was often use to indicate end of file in text files and input. Not quite the same thing!
That said, there seems to be two aspects to your question: what could cause computer software to never gain "undo" features, and what would using that software be like?
What could cause computer software to never gain "undo" features?
One possibility that I can see would be if computer memory (and storage) was very expensive. Keeping track of several states and allowing you to undo to work your way back through those states requires memory of some kind. The exact amount of memory required and the memory speed required depends on the type of data you are working with, how efficiently the changes themselves can be represented and how fast you need the undo feature to be to the user; all these are going to be different for different types of applications. A bitmap graphics editor is going to need a lot more and likely faster memory for a usable undo feature than a plain text editor, for example. A specialized financial application might be able to make do with storing only a few small pieces of information and recomputing everything else on undo/redo, if memory is scarce but computing resources are relatively plentiful. Or you could simply re-run any computations based on corrected input, discarding any previous results; this appears likely to have been the approach taken by early computers, which simply did not even have persistent storage (although they quickly followed, even paper tape readers for use with computers were a later invention).
If computer memory is very expensive, then you are going to want to conserve it as much as you possibly can, because any memory used for "undo" state data is going to be memory you cannot use for useful current state. And the more memory your program requires to run, the less people are going to be willing to buy and run your program. Hence, memory-hungry features will be at a disadvantage. Since undo requires both code and data, and potentially lots of particularly data, such a feature would be at a disadvantage. This doesn't necessarily mean "undo" features would never be invented -- someone, somewhere, would almost certainly start thinking "man, I really wish I could get back what I had two minutes ago!" -- but their use and perhaps even availability would be restricted to niche use cases and applications.
What would using software without "undo" features be like?
You would most likely focus on fixing any mistakes in place, rather than undoing back to a previous state and applying new changes from there. This is easier for some types of software than with others. For example, with some sort of text editor, fixing in place is relatively simple. (Yes, this includes programming, because most modern forms of programming at the core is about manipulating text representations of programs.) With advanced graphics or design, fixing in place is going to be more involved, but still certainly possible. (Lots of great art has been produced on media which does not allow any type of undo other than fixing in place.)
Which leads us to that you would think before you leap. You would probably spend more time considering the impacts of any change, because you would be reluctant to have to fix any mistake you make.
Saving regularly when you have something that you are happy with and keeping several revisions stored would likely be a common use pattern, although that also runs up against memory and storage requirements plus the problem of how long the fresh save itself takes. But it would give the user a limited form of undo functionality on computers that don't natively support it.
Using such a computer would likely be similar to how one uses a typewriter or paint canvas: focus on making the initial revision as good as possible, then either live with mistakes being present, or correct them in place and perhaps make a new "corrected" copy for distribution.
For a perhaps extreme example: does your (computer-controlled) washing machine have an undo feature? Mine doesn't. It does have an abort feature (so I can stop the washing program at an arbitrary point), but it doesn't have undo (no built-in way to make the laundry dirty again).
ctrl-Z
? And when you do, how often is it the same amount of time to hitctrl-backspace
? $\endgroup$