Under review are these documents, but others are mentioned.
Once again, I delved into the ruins of VPRI, in search of interesting work. These documents about a ``Text Field Specification'' program involved the idea of a simple text editor, having few rules and being friendly towards simple changes from a naive user. The documents are very unpleasant to read, so unpleasant that I'm surprised they found them to be suitable for release, but they're also short.
The second document is quite similar to the first document, and the differences are generally minor.
In the first, the program is expressed as a collection of methods, each arranged into a table; three columns are used: the first for the name and then comments; the second for guard statements; and the third for the code guarded. In that second document, rather than take this separation further, they reduce it by collapsing the latter two columns and using a special syntax for guard statements; this is the opposite of what they should've done. The code fragments already use cute little tricks like having three names for an important value, ``I'', ``Me'', or ``My'', to trick the particularly naive user into thinking any enforcement of using these properly be put in place. Rather than building up a system that uses less text, which has fewer opportunities for misspelling errors, they added more.
These documents remind me of my work, regarding my machine code development tool, Meta-Machine Code. Although, for that program, I seek to relentlessly reduce its total size as the method of allowing a user to customize it. I've also learned an interactive program will have a hard time separating its interface from its internal mechanisms, at least sometimes, and such differences should be embraced.
I can't see this toy as anything but a failure, and the very idea is perhaps misguided; I expect not myself to be able to service an automobile's engine with little training, so why should users expect themselves to service a program with little training? Further, an automobile mechanic works in more contexts than an engine or connecting pipes; he may service fuses, reservoirs, or the like. Yet the programmer is expected to use text for everything; it may be dressed up in bold or italics, it could have autocompletion, or templates, but it will still be text. The future of programming, especially programming for those not versed in the art, will be simple and weak systems which barely suffice to carry out their tasks and which will have interfaces permitting no errors and very little confusion.
In all of their work I've seen, it is always about text, always about creating some new language for some problem; about creating a new method finder, for when the method's name be unknown, rather than finding a way to remove the need to name them at all; about representing code as little boxes filled with character sequences of bespoke grammars; and this is called ``The Reinvention of Programming''.