Visual Basic: A standard for graphical scripting?

Last week at Spring Comdex, Microsoft unveiled a brand-new Windows 3.0 scripting language called Visual Basic. The reaction from the press was generally lukewarm, but we'll venture a prediction: Visual Basic will rank as one of the two or three most influential products of 1991, and it could have as much long-term impact on software design (and industry politics) as the Macintosh and Windows graphical interfaces. To understand the importance of Visual Basic, it's probably helpful to look back to the 1987 introduction of HyperCard. HyperCard popularized two fundamental concepts of graphical applications development: direct manipulation of screen objects (buttons, dialog boxes, menus etc.), and simple "English-like" scripting. HyperCard also triggered an immediate and passionate debate over the right" way to support graphical programming. Should Apple endorse a single system-level standard (by bundling HyperCard with every Mac)? Or should developers be encouraged to create many proprietary scripting languages?

In the end, the debate just fizzled out. Apple continued to bundle HyperCard, but didn't quite endorse it as a system-level standard. Meanwhile, individual graphical scripting tools proliferated, both for the Mac and (with the arrival of Windows and Presentation Manager) the PC. A few of these products--like Asymetrix's ToolBook, BrightbillRoberts' HyperPad, and Spinnaker's Plus--were little more than HyperCard clones. But an even bigger array of tools--graphical front ends, control programs, macro recorders, multimedia authoring systems, "smart" document assembly programs, and a rich collection of prototyping and development tools--sprang from the object-oriented graphics and scripting techniques that HyperCard popularized.

The result, four years later, is that graphical scripting is now widely accepted as a reasonable method to build, control, and modify applications. But at the same time, there's a growing sense that developers have created a new Tower of Babel for users. Scripting languages and objects turn out to be very much like pre-GUI software interfaces--each one is unique, and the conventions a user learns from one language rarely transfer to other languages. Which brings us to Visual Basic. By itself, Visual Basic is a general-purpose development language based loosely on Basic syntax. Judging from early reviews, it's a well-crafted product that will put most of its immediate competitors (particularly ToolBook) on the defensive. But the real importance of visual Basic is that it allows microsoft to define a universal standard for graphical end-user programming--a standard that eventually will influence the look and feel of every programming environment from application-specific macro facilities to inter-application control languages and even to commercial development tools. Microsoft still isn't talking much about its ultimate plans for an industry-wide Basic standard. But the company's own Basic strategy has never been much of a secret. The macro languages in Word and Excel have continued to evolve toward a common Basic syntax, and Bill Gates' "Information At Your Fingertips" speech Soft-letter, 11/30/90) clearly pointed to a common application control language that would seamlessly integrate individual applications. Perhaps the only real surprise about Microsoft's Basic strategy is that a key ingredient, Visual Basic itself, is a lot more than vaporware.

First, however, Microsoft has to convince a reasonable number of people (end users, corporate applications developers, and commercial programmers) that Basic is plausible as a marketplace standard. Here, Microsoft seems to have learned a useful positioning lesson from Apple, which never managed to establish HyperCard as much more than an entry-level environment. Microsoft insists that Visual Basic isn't a toy; instead, the product is positioned as a serious development environment for creating a very broad range of applications. Our guess is that most users will adopt Visual Basic first as a control language, to build Windows-based interfaces that drive other software engines--databases, spreadsheets, communications programs, and the like. These are applications that don't take much programming skill, and the performance of the control language matters much less than the performance of the underlying engines.

But Visual Basic is also a reasonably powerful development language for creating stand-alone applications (and Microsoft charges no run time fees, so distributing those applications is painless). In fact, Microsoft says its own programmers have been using Visual Basic internally to produce small utilities, including a rather nice icon editor that is part of the Visual Basic demo. We don't expect Visual Basic to make much headway among commercial C and C++ programmers-- except perhaps for prototyping--but otherwise it probably has enough depth and performance to be taken seriously as a professional development environment. Moreover, one of Visual Basic's great strengths is that specialized functions don't have to be part of the core product. Visual Basic applications can tap into an almost endless number of dynamic link libraries (software modules that link seamlessly will an application's core code). This capability is supposed to spawn a whole new marketplace for cottage developers of DLLs and component software." We doubt that anyone will actually get rich selling software components, but there's bound to be a flourishing DLL aftermarket that will make Visual Basic even more attractive to developers. If Visual Basic manages to attract a reasonable following among professional developers, Microsoft can argue that the software industry should adopt a Basic-like syntax for all graphical scripting languages. With a consistent standard, neophytes could learn elementary programming skills by writing simple macros, then move on to progressively richer tools. Our guess is that corporate customers will put enormous pressure on software companies to make end-user programming features work just like Visual Basic, and we expect that most developers will begin to draw heavily on Visual Basic as a scripting model, just as they have relied on GUI interface conventions even for character-mode applications. Microsoft is likely to make the case for a Basic standard even more convincing by embedding a subset of Visual Basic into future versions of windows itself. we doubt that an embedded Basic will appear much before 1993, but even a vaporware announcement would convince corporate standards committees that Basic is the graphical scripting language of the future.

To be sure, there's likely to be some stiff resistance to any scripting standard that Microsoft sponsors. IBM is perhaps the most important antagonist: The latest and most persuasive positioning for OS/2 is as an integrating platform for individual DOS and Windows applications, with non-Microsoft programming tools Borland's C++, and IBMIS mainframe REXX macro language) as the glue that holds everything together. Visual Basic doesn't entirely conflict with this strategy, but IBM is now acutely sensitive about Microsoft's control of software standards. IBM certainly won't help shift the balance of power in Microsoft's direction.

Similarly, Apple is likely to view visual Basic as an part of an ongoing turf war with Microsoft. A new system-level scripting language for the Mac wasn't ready in time for the long-deferred release of System 7, so so Apple is now scrambling to catch up by announcing an "open scripting architecture" that draws heavily on a third-party control language, UserLand's Frontier. But Microsoft will almost certainly ignore Apple's vapor standard in favor of a Mac-based version of Visual Basic, backed up by Basic-like macro languages in Excel and Word. Thus, Apple--which pioneered the whole notion of graphical scripting--may find that it faces a hard fight to retain control of its own scripting standard. Finally, Microsoft's applications competitors aren't likely to welcome a market dominated by visual Basic. Some have products (like Borland's ObjectVision) that will compete head-to-head with Visual Basic; others (notably Lotus) see their native macro languages as a unique competitive feature. There's already a growing sense of paranoia about what will happen if Microsoft controls yet another marketplace standard--but this time, the outcome seems almost inevitable.