Visual Age

Whatever good or bad things might have been true about VisualAge, IBM retired the brand.

VisualAge Smalltalk exists in name only -- the newest version (6.0) is literally impossible to purchase. VisualAgeJava will not be enhanced beyond its last version (4.0).

IBM announced "end of service" for VisualAge Smalltalk in 2006 http://www-01.ibm.com/software/awdtools/smalltalk/transition.html But don't worry, a small Oregon company, Instantiations, has a global source license from IBM, and, as of 2009, continues to develop and support it as VaSmalltalk? 8.0 ( http://www.instantiations.com/VAST/index.html )

Other VisualAge IDEs and compilers were renamed in the 2000s, and continued to be developed under the new names, notably the EclipseIde.

EnvyDeveloper was also part of IBM's Smalltalk offering.

There are a lot of VisualAge's around:

- VisualAgeJava

- VisualAge Smalltalk

Wikizens noted their VisualAgeJavaGripes .

http://www-4.ibm.com/software/ad/

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 edited. 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 JohnLakos' "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++ were 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.

IMO, the problem isn't that some languages are file based but that the compilers and build tools are file based. See ApacheAnt for example; the very reason that it was created was that make wasn't good enough. C/C++ combined with make isn't the best but it's good enough. There're times where the use of special tool can never restore the time it took to develop that special tool. CVS or SVN with three way merge works well enough for me, at least.

-- MikkoRantalainen?

How well does VisualAgeSmalltalk / EnvyDeveloper handle geographically dispersed teams?

CategorySoftwareTool CategoryLanguageImplementation CategorySmalltalk