towards a modern programming environment

[Kragen Sitaker]

One of the nice features of Common Lisp is that you can define new
data types that not only have their own contents and methods and
stuff, you can even define new data types that have their own input
and output syntax as expressions.  This has a couple of nice effects:
- your program can become easier to read and edit because you can just
  directly specify the value of some variable instead of having to write
  code to construct it
- your program can become easier to debug because it can easily output things
- your program can easily input and output values of this type, even when
  embedded in some other data structure or containing some other data 
  structure, using just READ and WRITE

So it occurred to me (after my experience with displaying JavaScript
with embedded HTML in a web browser) that such a system, in the modern
post-teletype world, could perhaps benefit from compound documents a
la OLE.  For many things, of course, it's hard to better text as a
source code format, although plain ASCII text is easy to better.  If
you built a GUI for editing programs, it might be beneficial if new
data types could describe not only how to convert them to text and how
to parse expressions representing them, but also how to display a GUI
to edit them.

JavaBeans and OCXs are part of the way down this path; IIRC a Bean can
contain code to display a property sheet you can use to customize it.

Some data types that could benefit from a non-textual display and
editing GUI:
- images, of course; for buttons, backgrounds, whatever
- finite state machine flowcharts and other graph data types; 
  credit to Josh Levenberg for explaining why this matters
- GUI widgets in general
- GUI layouts (this row of buttons here, then these two columns below it, etc.)

I had in mind that, just as a textual value in source code exclusively
occupies a certain amount of space on your editor screen, but parts of
that space might be devoted to other values, possibly of other types,
embedded in that textual value, so might a graphically-edited data
type exclusively occupy a certain amount of space on the screen and
control what happens to mouse clicks and such things, and delegate
part of its display to other things.  For example, a GUI layout might
contain other widgets, or at least their names.

I've been playing with KSEG recently, and it illustrates graphically
that programming environments need not allocate space in this way.
Indeed, I can't imagine a geometry program as useful as KSEG that
allocated a small parcel of screen space to each geometric item in a
sketch; the way they intersect and visually interact in a single
sketch makes it possible to visualize their interactions.

I don't like the UI of the compound document systems I've used; each
data type (spreadsheet, word processor, etc.) has a fairly specialized
UI --- or interaction mode --- and the transition from one to the
other is quite jarring.  Too, they don't share data in important ways;
things like text search can't effectively search through most compound
documents.  I think careful UI and API design can ameliorate this
problem, but I think it might persist.

I'd been pondering an outliner functional programming environment [0]
in which subroutine calls would be expandable out to see the variable
assignments inside the subroutine; each line of the outline would
contain a name, a definition, and a current value.  I wasn't sure how
to display the current value of aggregate data structures, and I
thought that perhaps you'd need to expand out the outline to
understand anything useful about them.  But if each object defines its
own displayValue method, that could be displayed; furthermore, if the
displayed value is editable, it might provide an alternate and often
more convenient mechanism for modifying the contents of that value.

[0] "functional programming for amateurs in an outliner", Kragen
Sitaker, 2002-05-27, posted to kragen-tol@canonical.org;
http://www.mail-archive.com/kragen-tol@canonical.org/msg00058.html
http://lists.canonical.org/pipermail/kragen-tol/2002-May/000713.html