Visual Age Visual AgeVisualAgeSmalltalk exists in name only -- the newest version (6.0) is literally impossible to purchase. VisualAgeJava will not be enhanced beyond its current version (4.0).
Wow! Excuse the personal comments, but I have been looking for user experience with IBM VisualAge ever since I heard of its existence, and was not able to find any until this, right under my nose on the Wiki!
My comments are not based on experience with IBM VisualAge, but are, rather, based on my musing about how an IDE should work, my dissatisfaction with most IDEs for C++ and Java, my long and deep experience with software configuration management tools like SCCS, RCS, and CVS, and my passing familiarity with the "other style" of version control tools.
Most of the development environments for C++ and Java show evidence of descent from UNIX file oriented tools. Yes, even the PC based tools like Visual C++: Microsoft still uses a file oriented compilation and build model. UNIX based IDEs such as Cygnus Code Fusion are mainly just wrappers around the UNIX tools.
The problem is that these tools are file oriented. File orientation is even part of the C++ semantic model, with #include and translation units appearing in the ANSI C++ standard.
File orientation *was* fine as a way of quickly creating such tools. Unfortunately, it is too coarse grain for future work.
For example, C++ ,h header files often include information for many different functions. If the declaration of one function is changed, every .c that includes that header file needs to be recompiled, if a file based build system like Make or Microsoft BUILD is used. Even .c files that do not use that function. Similar statements are true for layout of data structures in header files, and inline functions: unnecessary recompilations occur even if the .c file does not use the facility that got editted. Even something as innocuous as embedding automatically generated version numbers in files can lead to 2X the number of recompiles.
This is well known in the community, and books such as John Lakos' "Large Scale C++ Software Design" describe many ways of minimizing such redundancy. The overall approach is to make files contain only one physical component, minimizing but not eliminating the problem. Even if a header file contains only one class, a change to an inline method forces recompilation of .c files that do not use that method. Similarly, tools such as AT&T BellLabs "incl", CIAO, and ACACIA have been used to show that much of the code included during a compilation is unnecessary, and many #includes can, in fact, be eliminated.
As a further example, version control systems like CVS are file based. Many different functions and methods are placed inside the same .c file. (If you ever try to place each method in a separate file, even in the year 2000 you will find that link times kill you.) If you use exclusive locking, e.g. in RCS, the lock prevents other people from making non-overlapping edits to different functions in the same file. CVS optimistically handles this by allowing multiple edits in the same file, and automatically merging changes together, warning if they overlap. Although the CVS technique usually works, it does not always; bugs *have* occurred because of it.
The problem is that files are too coarse a granularity, and different tools need different granularity. Files need to contain multiple methods and function for linker efficiency, but file based locking is too coarse.
There have historically been alternatives to file based systems. Early Cray systems had a "deck of cards" model for version control, where locks applied to a possibly discontiguous set of lines. For example, a function body, and all callers of the function. Ada systems had non file based edit and library management. The ubiquity of the file based model seems to be related to the ubiquity of UNIX.
IBM VisualAge seems to have taken the non-file-oriented several steps further. The entire source code lives in a relational database, integrated with a language parser. It can be managed at line granularity. (Q: does VisualAge permit management at statement or expression granularity, smaller than a line?) Locking can accordingly be done at fine granularity. Individual methods can be locked. Similarly, individual methods can be version controlled. When code is changed, only the code that depends on the change needs to be recompiled, *not* code that happens to live in the same file.
The reports of IBM VisualAge are quite exciting. I wish VAC++ was available on LINUX. Lacking direct experience with IBM VisualAge, I can only conjecture as to its full potential. Its full potential is significantly beyond that of traditional UNIX-like file based tools, even when an IDE is created on top of them.
-- AndyGlew
You might want to have a look at VisualAgeJavaGripes.
This page mirrored in WikiPagesAboutRefactoring as of July 17, 2004