Motivation: Making some sense of VB-Visual Basic and VBA-Visual Basic for Applications


Visual Basic has been one of the most popular languages for Windows development reaching a high point in 1996-8 when Visual Basic 5 reached within 80-90% of the speed of Visual C++ across a broad range of benchmarks and with the final consolidation of VBA-Visual Basic for Applications as the macro scripting language not only for Office but also many other major Windows desktop applications like AutoCAD, Corel Draw, Visio, System Architect, Word Perfect and many others.

The popularity of VB was based on the fact that it made the complex event driven programming of the Windows GUI very approachable with some pioneering (along with Gupta's SQL Windows-) drag and drop design tools, property sheets, plus click and code aids. In addition, with unflagging efforts if not success, the VB developers also tried to simplify database connectivity; however, the problems was a proliferation of mutually incompatible data access methods: DAO, RDO, VBSQL, OLE/DB, etc. More success was achieved with simple code generation tools and database designers. And a legion of third part developers were providing literally hundreds of components for use with the VB/Visual Studio design tool.

However, VB6 and now VB.NET have introduced a fly in the ointment. VB6 moved the language clearly into the OO-Object Oriented camp. With full encapsulation, inheritance, and polymorphism capabilities; yet strict OO inheritance from single line of source was not followed. Performance took a hit relative to VC++(down to 70-85% of VC++ speeds). And ADO was introduced - causing yet another switch in "the official" database access method. However, VB6 offered improvements in security and reliability.

The introduction of VB.NET was a watershed. The basic syntax of the language was changed so drastically that Microsoft could not offer a conversion facility that would reliably convert VB6 projects to VB.NET. Some Microsoft employees started calling VB.NET Visual Fred because it was so different from the now obsolete VB6. Other developers insisted that VB.NET was too much like C#; having nearly all of its features but also complexity - notably single source of strict inheritance as VB became fully object oriented. VB lost a great deal of its simplicity and ease of development for beginners for the sake of its new role.

VB.NET is the official language for ASP.NET (but so is C# or any .NET language which supports the appropriate .NET BaseClass libraries). VB.NET supports ADO.NET; requiring yet another database access conversion for developers who have seen a rapid succession of RDO, OLE/DB, ADO and now ADO.NET become the "official" VB and/or Microsoft database access method. (Caution - LINQ may require an easy, but also another set of VB DB conversions). VBA in the meantime has a new but not totally compatible counterpart on the Server side called VSA. Client side VBA will continue to be supported but it will not produce .NET managed code - and will require special interfaces to .NET code.

We agree with the dissident Microsoft supporters , we believe that VB.NET is too close to C# and in fact dominated by it. No wonder that C#, according to TIOBE, is one of the fastest growing programming languages while VB is declining steadily relative to other languages including PHP, Perl and Java. Yet we believe that VB and VBA represent a better "safe haven" for VB developers than does VB.NET. This conclusion is predicated on 4 assumptions:
1)the major rewrite of the Windows API reflected in Longhorn, the redefinition of the Windows OS client, will not emerge until 2005/2006. This will force a continual stream of changes in VB.NET as comprehensive and drastic as the VB6 to VB.NET. Wait until Microsoft gets in finished in 2006. Do not exist on a bleeding edge of duration 3-4 years;
2)Microsoft has yet to define what it will do about VBA support in the Office product line. How will the transition be made and what is the succeeding product going to look like ? As of Office XP 2003, VBA is still the development language for Office;
3)Microsoft and developers desperately need a language orthogonal to the deeply inherited/imbedded C#/C++ object mold. Inheritance has its advantages; but the convolutions required during refactorings when OO code is modified or redesigned is not for the faint of heart. In short VB6 and VBA are much more approachable for macro and glue tasks required in many Office and other routine integration projects;
4)With Yukon on the horizon as the next 'official' Microsoft database there is the possibility of two sets of conversion tasks: VB.NET -> Yukonized VB.NET -> Vista's "Truly"VB.

Make Microsoft stand and deliver on its VB/VBA conversion efforts and most importantly upgrade path. VBx->VB.NET has been such a dastardly downloading of extra work to developers - make sure your IT developers are not going to be carrying the load for an unenviable succession of nasty upgrades.

VBA Becomes VSTO

The new Office 2007 has VBA in it but that is only a temporary fixture. The writing is on the wall. To get to Vista and Office 2007 GUI features developers will have to adopt VSTO-Visual Studio Tools for Office. However, the current version of VSTO does not support all of the specific features and APIs of VBA for the various Word, Excel, and other Office and Microsoft apps. So VBA remains in Office 2007 but with the advice - do not use it to program new macros and apps. VBA on Office for Mac is completely abandoned - creating a furor there. In short, Microsoft with Office 2007 is caught between here, VBA - and there, VSTO. The next version 3 of VSTO will support Word and Excel. No word on availability of VSTO 3. Meanwhile here is the rationales being offered for moving from VBA to VSTO:
Nine compelling reasons to move from VBA to VSTO - note lack of real why VBA could not be upgraded
About Visual Basic take on VSTO - always strong on VBA, embracing a bit hesitantly VSTO
Here is a tongue in cheek book on VBA to VSTO - Its not pretty and makes JavaScript look good
Finally the semi-official Microsoft take on VBA/VSTO- I hope John Durant gets "thankless task" extra pay
So VBA will be replaced. Some 3rd party vendors like AutoDesk with AutoCAD and Adobe with its suite of products are just coming to terms with the demise of VBA. Both vendors have deep commitments in VBA and have yet to announce

So our coverage of VB will continue but it will be confined to VB6 and VBA . It is decidedly biased towards VB6 plus VBA with only a smattering of tutorials and articles about key issues regarding VB.NET because we feel the VB/VBA model of programming was so much better. For the legion of VB/VBA developers, we shall try to remain as a support center for what was once one of the easiest entry points into Windows programming.
.