This means we needn't fully specify a system to get started, we can simply craft new pieces as we go. We end up exploring the system as we create it and do

This means we needn't fully specify a system to get started, we can simply craft new pieces as we go. We end up exploring the system as we create it and don't have to get a "complete" model to gain value. This is an essential part of the article, and why the author has a valid point. The problem with most current approaches to programming is that they don't provide good support for this partial, incremental way to build models - either your abstractions are fully developed, or they don't work at all and the program crashes during execution; there is no middle ground. Professional developers eventually learn how to build systems incrementally through testing (by building placeholders for yet-to-build components) and debugging (by exploring how the program behaves under different inputs), but these tools are complex and not really part of the programming language, and thus not adequate for basic literacy. Excel and Hypercard fall out of this requirement for perfect modelling, allowing partial execution of parts of the program, and intermixing data with the code that works on it, lowering the abstraction barrier; thus these tools work better for exploratory modelling than conventional programming languages, which keep data and commands wholly separate and require an exact specification to work. They have shortcomings, but the article is right that a tool for the wide public needs to reduce the level of formalism required to build models, and that "the computer revolution" based on that "lightweight modelling" approach has yet to come. There is an emerging movement for "live programming" that has created environments closer to that approach. This is still in its early stages, though we think we're finally close to achieve that vision. *Edit: format