Text-Oriented IDE

Let us now imagine how a text-oriented Integrated Development Environment could look and feel.

Let us assume a graphical environment with pointing devices and movable, sizable windows containing some dockable, sizable frames, and concentrate on the text-based user interface and the system's functionality.

Source Selectors

One could proceed this way.

You open up a new window with an empty left sidebar and an empty main frame.

You bind the sidebar to a selector, say:

projects . =myProgram . :t

and set its presentation mode to tree view. Now you see the project's outline, containing for example these chapters: requirements, analysis, specification, design, code. You click on a chapter and see its subchapters. You set the main frame's source to show the contents of the element being currently selected in the sidebar. You can edit the project's outline at place, you can easily hide and show some items of it.

Suppose you are looking for a particular place, then you change the sidebar's source selector, say:

projects
   .=myProgram
      .#emails
         ."user interface" tag
            .>timestamp

to get the list of all electronic mail messages about the user interface sorted by time descending. You click on one of them and the message appears in the main frame. The workbench knows that this is an e-mail and renders it accordingly: One sees a header containing the sender name, subject and time, and below the message's contents as prose. The message contains a reference to a particular place in code. You can easily jump to it either in the main frame or in a new one or in a new window. The system knows, this is say ”C“ code and renders it as such.

You can write selector expressions in many languages. This example uses the selector notation introduced in ”Text Query“, but it could be a complete text-query language or even plain text language. This expression could be translated between languages by the workbench.

Browsing Code

Browsing code is not limited to fixed files. You can get a whole module in one window frame, but you can get say the whole code related to a particular functionality that can be dispersed throughout modules. You can also see the code for a particular transaction, e.g. what did I yesterday? You can also see all functions that invoke a particular function. You get all this by simply changing the source selector.

Browsing code is not bound to a particular software system such as a database management system or a development platform. The presentation is the same if you watch a list of tables and fields of a relational database or if it is a list of class members. You see it with the same user interface and you can apply the same operations to it, such as renaming, sorting and filtering. How this is implemented, does not make any difference.

So-called ”code“ and so-called ”documentation“ are seen and operated through the same user interface, too. You can see the whole documentation in more or less detail at will. When you point to a paragraph, you can get details about some aspects of it, such as a discussion between developers or with the management about it, work progress status or test results. When viewing a requirements document, you can select a particular sentence and see at a glance what parts of the specification, of the design and of code are affected by it.

When you view some code, you can control through the source selector if you want to see the related paragraphs at the user's guide, the specification or some implementation notes. Each function has natural language sentences describing its purpose, arguments, return values, exceptions, etc. You can see the code with some or all these informations embedded before each function's body, or at a synchronized frame, or overlay it on demand. If you are wondering why something was done this way and you don't know if it is a bug or it has some recondite reason, you can overlay the discussion between programmers about these particular lines.

The code can be alternatively rendered and updated as diagram, for example entity-relationship and class diagrams.

It is frequent in code to have functions that call other functions, all of them being defined in the program. One can choose to see this code parts top-down (first the caller and then the called functions) or bottom-up. One can define a custom order for a code view and hide some items. One can save code views and recall them later.

You can add your comments, to do tasks or questions to clarify. You can share your code views with your team, open discussion pages about particular issues, ask particular persons about particular parts, reply the questions you have been asked and overlay the context documentation. The discussions can be seen ordered by thread, time, people or with regard to content such as concerned classes, tables, requirements or emerged issues.

Code Transformation

Code is not just shown the way it was fed, it can be transformed at will. All you have to do is change the presentation mode through the source selector.

There are equivalent languages, for example those of the .NET environment, one can see the code in any of them and switch easily. If one enters a code part written in a completely unknown language or a particularly complex expression, one can always switch to the plain text language and get complete clearness about it.

Code is not bound to particular identifiers, either. A code one is familiar with can be shown with short identifiers consisting of a few letters, thus being compact expressed. If one dives into unfamiliar regions, perhaps something one wrote a long time ago or something written by others, one can get it expressed with long, significant identifiers. One can define and update name systems at will and establish correspondences between them. Some of them are volatile, just for a single session, some are for personal use, some team-wide or organization-wide and some worldwide.