Read an Excerpt
From Chapter 20: Programming Tools
...20.6 Ideal Programming Environment
This section's description of an ideal programming environment is an excursion into programming fantasyland. Although such a vision is not immediately practical, this book about construction has a responsibility to define where construction tools should be going. All of the capabilities described in this section are easily within the reach of today's technology. Perhaps the description will serve as inspiration for an ambitious toolsmith who will create a programming environment that towers above the ones currently available.
For this discussion, the fantasy environment is called "Cobbler." The name is inspired by the old saying that the cobbler's children are the last to have new shoes, which is true of today's programmers and programming tools.
Integration
The Cobbler environment integrates the programming activities of detailed design, coding, and debugging. When source-code control is needed, Cobbler integrates source-code version control too. If the detailed-design practices suggested in this book are followed, the primary detailed-design tool required is PDL, which can be handled easily, even in text environments.
Language support
During code construction, Cobbler provides ready access to cross-referenced help on the programming language. Help discusses nuances of the language as well as the basics and mentions common problems in using features of the language. For error messages, Help lists the common problems that might give rise to each message.
The environment provides templates for language constructs so that youdon't need to remember the precise syntax for a case statement, a for loop, or a more unusual construct. The help systems provides a well-organized list of all available routines, and you can paste the template for a routine into your code.
Detailed cross-referencing
Cobbler enables you to generate a list of all the places in which a variable is used or receives a value. You can get help on a variable declaration the same way you's get help on any other topic, with ready access to the variable definition and comments about it.
You can retrieve information on routines just as easily. You can follow a chain of calls to routines up and down--pointing at the name of the routine you want to view in more detail. You can check variable types in a call to a routine with the touch of key.
Interactive views of program organization
The Cobbler environment radically changes the way you view program source text. Compilers read source files from beginning to end, and traditional development environments force you to view a program the same way. This is sequential and flat--far from what you need for a meaningful view of a program.
In Cobbler, you can view a tangle of routine names, graphically presented, and zoom in on any routine. You can choose the model that organizes the tangle of routines: hierarchy, network, modules, objects, or an alphabetical listing. Your high-level view isn't cluttered by a routine's details until you want to zoom in on them.
When looking at the guts of a routine, you can view them at any of several levels of detail. You can view only the routine's definition or only the comment prolog. You can view code only or comments only. You can view control structures with or without a display of the code they control. In languages with macro commands, you can view a program with the macros expanded or contracted. If they're contracted, you can expend an individual macro with the touch of a key.
In writing this book, I've used a word processor with a powerful outline view. Without the outline view and the ability to study an outline and then zoom in on its detailed contents, I'd have a weak sense of each chapter's structure. The only view I'd see of each chapter would be flat, and the only sense of structure I'd have would come from scrolling from beginning to end. The ability to zoom between low-level and high-level views gives me a sense of the topology of each chapter, and that's critical to organizing my writing.
Organizing source code is as difficult as organizing writing. It's hard to believe that I lack any capability whatsoever to view the topology of my programs, especially when I've had a similar capability in my writing tools for more than five years.
The kinds of components that make up a program can also be improved. The semantics of source files are hazy, and the concept is better replaced by the ideas of modules, packages, or objects. The concept of source files is obsolete. You should be able to think about the semantics of your programs without worrying about how the code is physically stored.
Interactive formatting
Cobbler provides more active formatting aids than existing environments do. For example, it's graphical user interface makes outer parentheses larger than inner parentheses, as they have been displayed in mathematical texts for a hundred years.
The environment formats code according to user-specified parameters without resorting to a separate pretty-primer program. Any environment that knows about your program already knows where all your logical structures and variable declarations are. In Cobbler, you don't need to resort to a separate program to format your code. Some current environments provide feeble support for automatic indentation of control structures as you enter them. But when they're modified and 45 lines need to be shifted out six columns each, you're on your own. In the ideal programming environment, the environment formats the code according to the code's logical structure. If you change the logical structure, the environment reformats the code accordingly...
