Right on. Also, "Interactive Programming Environments" by Barstow  
should be required reading for anyone dabbling in that area (e.g, it  
contains the PIE paper). I saw it for 85 cents recently at Amazon,  
everyone seems to think "old" computer books are worthless ... sigh ...

- Bert -

On Feb 19, 2007, at 8:45 , Darius Clarke wrote:

> Some points I believe to be missing is modern programming  
> environments:
>
> 1. Making "why" a property to be populated by the programmer in all
> programing artifacts. Like a Jr. programmer, if the "why" property is
> not populated, the interface should gently, non-disruptively ask
> "why". Some say that the answer to "why" is already in the programming
> source code. I rather disagree. Often, even Sr. Programmers experiment
> with the code to discover the chosen way that is eventually preserved
> for the record in the distribution. However, the learning process
> itself, and hence the reason why, is thrown away. "Why" often
> documents the code that shouldn't be there, rather than the code that
> is. A system without "why" preserved in it can exhibit the problem in
> the form of many different programmers submitting a "fix" for the same
> "problem" and only told "why" the fix won't work after they went
> through the effort of "fixing" it. Reflexive, logic programming
> languages like Prolog have the advantage of describing "how" they've
> reached some conclusion which is similar to explaining "why".
>
> 2. Check out Jef Raskin's book, "They Humane Interface" for some very
> insightful observations from a cognitive psychology perspective.
>
> 3. Along with "why", I believe "who", "what", "where", "when", and
> "how" should be configurable properties of all programming artifacts.
> They imply many important questions often left unanswered but are
> necessary for understanding and modifying other programmers' code.
> These need not be just "text" or "tag" properties, but full fledge
> objects and code that can be extracted, examined, programatically
> reasoned from, or modified programatically. Something like the
> semantic web.
>
> 4. Zoomable names/labels. Because programing languages have most often
> been expressed in text (for the advantage of the compiler) a lot of
> burden has been placed on the meaning of a field name. In fact, and
> enormous burden is placed on field names. This fact can by illustrated
> by some who need to use Camel Case, Hungarian Notation, quotation
> marks for  names with white space, type systems, scoping rules, dot
> notation, syntax highlighting, autocompletion lists, name spaces,
> globals, method-name/property-name/database-field-name confusion,
> defs, source code readability, etc. These names and labels are often
> defined far from where they are used placing a burden on the
> programmer's memory or spend the programmer's time to jump from one to
> the other. Rather, I believe, as long as we program in a _GUI_ we
> should allow labels to be dynamically zoomed, in-place, to the level
> of detail required by the programmer's memory and experience... any
> level of detail. Even after the code is persisted to storage,
> subsequent programmers should still have the dynamic freedom to
> re-zoom the label to the same degree as the original programmer.
>
> 5. Continuous unit testing and integration testing should be built-in
> to even the tiniest artifacts of coding so that such things become
> visual, automatic, unconscious to the developer. (cf Raskin).
>
> 6. I would include audio documentation to be a normal part of source
> code documentation. This would be a crutch for the "documentation
> writing challenged" among us. Such things could me setup to be
> programatically translated to other languages, accents, or dialects.
>
> More later.
>