A Review of more Documents from the Viewpoints Research Institute

Under review are these documents, but others are mentioned:
http://www.vpri.org/pdf/m2010001_pobjects.pdf
http://www.vpri.org/pdf/m2010002_lobjects.pdf
http://www.vpri.org/pdf/tr2008004_steps08.pdf

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''.
.