rb@ccird2.UUCP (Rex Ballard) (04/11/86)
There are a number of different "schools" in the compiler, debugger, enviroment debate. At one extreme is the group that would like to see a "generic" debugger that has no dependancies on the compiler (ala adb). Each "piece" should be independant. This way, they argue, you can use any editor, a variety of compilers, and a variety of debuggers. At the other end of the scale is the "environementalist" who would have you use a single integrated enviroment which was designed for that specific language. You would use the environments editor, compiler, debugger, and analysis tools. Many interpreted languages such as BASIC and FORTH function in much this way. What is really needed is both. A fully interactive enviroment allows unit testing of each module as it is written. It allows experimentation with library modules or built-ins to insure that no incorrect assumptions reguarding the calling procedures are made. many such environments allow examination of the lower level source as well. It also makes "ad hoc" tools and functionality very easy to implement. The "generic" environment on the other hand allows you to wring maximum performance out of the software. By using debug and profiler switches, using source and assembly level debuggers, the user is able to look at the "hot spots" and peculiar "assembly level bugs". The problem is, that certain constructs which are very easy for the compiler to do, are very difficult for the interpreter, and vice-versa. Try creating an interactive system capable of supporting full K&R C. Try supporting ALL of the libraries, even those for which you don't want developers hacking at source. Any "hybrid" language capable of supporting both environments requires new approaches in how software is implemented, organized, documented, and designed. Smaller modules are indicated, to allow modification of small functions without "rebuilding the world". Software must be organized to enable the developer to find existing functionality without "re-inventing the wheel". On-line documentation must be available so that the developer doesn't have do leave the enviroment to learn how to use a function. Designs must be more complete to allow the "bottom up" implementation of a "top down" design. Assemblers and linkers must be beefed up to allow the larger number of local and global variables required by such a system. They also must be equipped to handle long identifier names which will enable more self-descriptive names to be given. They must also create modules that can be used by the "interactive environment". This is a tall order, but worth considering.