If you want to know where applications and platforms will enable us to go in the future, look at the best-paved paths of software development today. For example, Borlands new C#Builder and the development life-cycle tools that come with it will go a long way in helping developers along the road to the Microsoft .Net environment. However, Borlands joining Microsoft in the .Net journey gives me concern, as well as hope.
Some will argue that Borlands efforts represent the beginning of toolmaker competition on the .Net platform and that this is good. But what I see is something that looks more like the end of competition between .Net and other network application models. In fact, it could be the beginning of the end of the Internet as an application-neutral infrastructure.
The forks in the development road present enterprise IT buyers with important decisions. Those include at present a range of choices that Sun hopes to broaden with renewed efforts to establish a Java-based desktop offering. Borland is also keeping choice alive with its multiplatform C++BuilderX tool set, which is built on its own Java-based JBuilder framework.
Microsoft, meanwhile, consistently shows the importance of affordable, intuitive, capable development tools in establishing and maintaining platform dominance. As we near the 20th anniversary of Apples original Macintosh, imagine how different things might be now if the first Mac in 1984 had an approachable programming tool, as well as MacWrite and MacPaint, in its software suite.
Apples HyperCard, in 1987, suggested that development for graphical environments could be much easier and hinted that Apple might make ease of programming as important in its strategy as ease of use. Early versions of HyperCard, though, were aimed more at hypermedia publication than at general development: By the time Apple expanded its vision with HyperCard 2.0, in 1990, the companys platform innovation lead had been slashed by the release of Windows 3.0 and by the IBM PS/2s elevation of the basic level of PC graphics hardware. It was Microsoft that wound up redefining ease of development with the first release of Visual Basic 1.0 in 1991.
In some ways, Visual Basic was the worst thing that could have happened to application development. Users needed more automation of routine tasks, but Visual Basic made it easy for developers to write applications that demanded tedious point-and-click repetition. Former text-based applications were easily scripted, even across applications from different vendors, with tools like Quarterdeck Office Systems DESQview. Indeed, multivendor application integration was arguably easier a quarter-century ago than it is today.
With its convenient but shortsighted component model, Visual Basic paved the way to the hell of dueling versions of such key components as THREED.VBX—with different applications each demanding that a preferred version of a control be visible for that application to run. Visual Basic also led the way in building inherently insecure applications, with capabilities such as sending e-mail from inside an application with no system-level facilities for maintaining user control—or even surveillance—over that function.
These are the flaws that .Net addresses with component versioning, with convenient exposure of application functions as Web services and with truly impressive facilities for writing applications that guard their own resources and that shun access to anything that theyre not intended to use. With the .Net Framework reducing developers need to reinvent such wheels and with Borlands acquired stable of technologies in requirements definition, testing and performance optimization, theres hope that developers might enjoy substantial improvements in their ability to meet enterprise needs.
Theres much to like in .Net. But no one should take that route—no matter how much developers may whine, “Can we please go this way?”—without considering the appeal of the destination as well as the ease of the journey. It would be a terrible irony if the open- and standards-based network, using nonproprietary service discovery and invocation protocols, wound up merely being the best way to handle services that only a Windows server will be able to perform and that only a Windows client will be able to use.
Technology Editor Peter Coffees e-mail address is peter_coffee@ziffdavis.com.