On integrated programming environments

[Matthew Tuck]

Ursula Dreier wrote:

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

Yes.  It would be interesting to work out how a resource editor would
work when combined with the parse tree.  I'm not convinced it should be
built into the tree since as far as I can see resource editing is
usually shorthand for the code it generates, that is, it gets turned
into normal code.

For this reason it might be possible to use the program tree extensions
I mentioned for user-defined shorthands in a previous post.  The
principle is that the nature of the extensions are stored in the file
for those who don't understand them to be able to translate them down to
code, but if they are understood they can be used in that shorthand
format.  Although in this case I think it would be easy to lose the
shorthands and then not be able to translate them back.  Will have to
think about this one.  =)

My idea of our system is that files are split into various modules. 
Modules have no information hiding at all and no namespacing.  Similar
to C, if you ignore the existence of the static keyword.  They are
basically used for allowing collections of classes to be put together,
and as a distribution mechanism.  If you don't have any reusable classes
that you're using other than the standard library you would probably put
everything in the same module.  Ideally what goes in what module will be
transparent to you if you don't care at the moment.  All information
hiding and namespacing is done with classes/objects.  I think Eiffel
does something like this.

As for intelligent editors on normal source files, I think that anyone
who tries this is barking up the wrong tree.  Trying to make intelligent
editors with text files is the reason we have few intelligent features,
including syntax highlighting and auto-indenting, which in my experience
often doesn't wrok properly anyway.

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

That's the idea.

> 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?

This is the sort of thing I liked with a went to a lecture on the
MultiView project at Flinders University last year.  They have an
intelligent editor which allows parallel views of the program.  Parse
tree view, text view, compiled output view, etc.  And the lecturer was
doing his Ph.D. on direct manipulation of programs.  There's a link on
the Ultra page to this.  I certainly want us to do this, I think that it
is definitely the way to go.  They said to me that they should have
MultiView online around the beginning of 1998, but I haven't seen it
yet.  I would really like to take a look at it.

One example of a view would be a class browser.  I think that our views
should be "plug-ins", so they can be written by anyone and plugged in if
the user desires.  We should probably put them in a sandbox too, and
give them a specific API to work with.

> If you want to have a look at the follow-up product to SqlWindows
> called Centura Team Developer, try

OK, will do.

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

I don't have any of these, but I figure you're talking about an
expandable/collapsable tree starting at class and going down to method,
etc.  That was pretty much my plan for the standard textual view.

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

Outline editors are editors that allow editing in terms of
expanding/collapsing sections you're not interested in, for those who
don't know.  Essentially you have a list of classes, and if you want to
edit one you click on an icon to expand it.

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

There is no reason to restrict this to just one view I believe.  We can
make it quite independent.  This allows distribution of different
syntaxes, and due to the program-is-tree notion, you don't care what
syntax another programmer writes in when you read their code.  Different
syntax also allows have a syntax based on another natural language. 
Furthermore, you can edit the program in a totally different way.

This is achieved by using either the Observer or Model-View-Controller
pattern to ensure that when one view is edited the others are updated.

Doing this allows us to keep up with future developments, as well as
catering for programmer tastes.

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

Yes, I've thought of this idea before, I'm not convinced though.  I
think an end marker is useful to let you know what procedure this is
when it is long, although I guess procedures shouldn't be long, and you
can put where you are on the status bar (hey, I hadn't thought of that
before).

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

This looks like a partially parse tree, partially textual
representation.

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

C-like {} has known problems, and () was never needed.  End-of-line
semantics will certainly be an interesting debate, and not one I want to
enter into at the moment.  All I will say it that a programmer should be
able to choose where they want end-of-line since it is important to be
able to break long expressions in a reasonable place.

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

I think the idea of being able to choose your own preferences is even
better than this, you don't have to be forced into doing what the editor
writer wants you to.

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

It could be, but I think a dedicated browser would be useful still as
another view.

Firstly, let me say that my idea of editing intelligent editors is that
there should be menu to do things, like change if to if-else to case and
vice-versa, for to while and vice-versa, etc.  A lot of the problem with
structured editor is if you have the wrong structure it can be very hard
to fix it, hence we should endeavour to help.  This would probably be
providing by right-click menus.

This being said, all this is irrelevant to browsing.  Browsing is
read-only by definition, and that sort of things we are interested in
are dependencies, changing the way we're browsing (e.g. from nesting
hierachy to inheritance hierachy) although this might be relevant to
editing as well, etc.  Basically I think it's just editing without the
clutter, and possibly with a little bit more information.

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

I'm not sure what you're referring to here - could you please give an
example of what you mean by "tree layout is changed".

-- 
     Matthew Tuck - Software Developer & All-Round Nice Guy
                              ***
       Check out the Ultra programming language project!
              http://www.box.net.au/~matty/ultra/