On integrated programming environments

[Ursula Dreier]

IDEs are an important means to simplify programming. They should make it
easy to view the structure of a program, to find things and to edit
graphical aspects of your program ("resource editor", "window painter").
But they usually don't mix well with the fact that most programs are
stored in plain text files in some rather unstructured manner, while
graphical resources are stored in some other files using another format,
and so on. This leads to problems in keeping things in sync, to an
unnecessary amount of administration work and to a rather fragmented
user interface. Also, to write an intelligent editor that is supposed to
provide an up-to-date view of the program structure in real time is
quite a challenge when based on normal source files.

If things were stored in a structured way (say, a tree), all this would
be strongly simplified.

This is what appealed to me when I worked with Gupta's SqlWindows: They
pack everything into one big binary file and provide an editor with a
tree-like view into this, as well a window painter and some tools (such
as a compiler and a wizard to automagically generate a database editor's
source). Strictly speaking, these two facilities are sufficient for
every day work. If you do no programming to a GUI, even the window
painted can be omitted. Why make it unnecessarily complicated?

If you want to have a look at the follow-up product to SqlWindows called
Centura Team Developer, try
http://www.centurasoft.com/products/downloads/
or (if you don't want to give your personal data away to receive that
evaluation copy)
http://www.centurasoft.com/products/development/sql_windows/

If you look at MSVC++ (class view) or Delphi, this may also give you a
clue how it could look like.


Here is my suggestion for an IDE:

The important part is an outline editor which allows editing a tree that
contains ALL aspects of the application in text form.

All editing takes place in that tree view (having the conventional +/-
signs to indicate whether there are child items) and is guided in a way
that you cannot disrupt the tree structure.

This goes down all the way from the uppermost name space to the
statement level of methods. So there need no be an open form or closed
form for conditions and loops, but rather some kind of indentation
(which is not achieved by use of tabs and spaces in the text, but by the
editor itself, graphically).

How does this interact with the user? Lets look at an example:
(I omitted the +/- signs of the tree view for the sake of clearness)

The user hits the Return button in a line where a declaration can be
entered, say, a method declaration. A new blank line is inserted.
He types:

 Function: myFunc

As he hits the Enter button (or tries to leave the line), child items
are being inserted below at the next indent level automatically:

 Function: myFunc
  Description:
  Parameters
  Local variables
  Returns:
  Code

If there are editable areas, they generally start behind those
automatically generated labels, so the user cannot change those. Only
Description and Returns have editable areas at all. But some items may
have to ability to host subitems.

The user now is in the Descption line, the insertion point being at the
start of the editable area behind "Description: ".
He enters a descriptive text, moves on to the Parameters line and hits
the Return button there. A new blank item is inserted.
He types aString: sMyParameter  ! this an inline comment

 Function: myFunc
  Description: a descriptive Text
  Parameters
   aString: sMyParameter  ! this an inline comment
  Local variables
  Returns:
  Code

He moves on to the Returns: line and enters aBool: to indicate that this
function will return a boolean, then goes to Code and enters some code
(after hitting return to produce an empty item). The final result will
look like this:

 Function: myFunc
  Description: a descriptive Text
  Parameters
   aString: sMyParameter  ! this an inline comment
  Local variables
  Returns: aBool
  Code
   if sMyParameter == 'Hello World'
    return true  ! this an inline comment
   else
    MessageBox ("Please pass 'Hello World' as a param!")
    return false

Please note: There is no {}, and no () is needed around the argument of
the "if". The editor will indent automatically. If you are done with a
{} clause, you enter a blank line or hit Backspace or maybe the editor
is smart enough to automatically undent when you enter "else". No
semicolons are needed because the end of the statement is clearly
recognisable (one statement per item), so you can't forget 'em. If you
need more than one line, just hit Ctrl+Enter to enter a newline INSIDE
the item, or have a backslash at the end of the line before hitting
Enter, or something like that. (Of course, automatic line wrapping by
the editor itself, based on the window margins, should also be an
option).

Because the whole thing is being "laid out" automagically, anybody who
is familiar with it should not have any problems to read anybody else's
code - it all has the same look & feel. I think this is an advantage
over having people fret about other people's placement of curly braces
or packing lots of things into one line...

Because the tree view is collapsible at arbitrary indent levels, this
editor is also very useful as a browser.

Up to this point the editor and the edited tree could be viewed as two
separate entities, the edited tree being the passive object of the
editor.

But that need not necessarily be so. The real fun starts when the
editor, the runtime environment and the application(s) being developed
are packed together into a single "program". This allows for much more
flexibility, the editor's behaviour to be influenced by the application
under construction, while editing takes place (on the fly): You change
the layout of a class and add a new property (an instance variable that
is initialized at edit time) and the editor's tree layout is changed
immediately to accomodate the new property.

More on this in "On memory management".