The Next COBOL
COBOL has long been the dominant programming language for creating business applications on mainframes. During the era of two-tier client/server applications, no single language dominated -- Visual Basic, PowerBuilder, and many more were used on clients, while server-side business logic was commonly written using the stored procedures built into some database management system. But as we move into the third generation of enterprise application development, where three-tier applications are the norm, chances are a single language will once again become dominant for building business logic. The question is, what language will it be?
It won't be COBOL. No major software tool vendor seriously promotes COBOL as a development language for three-tier applications. It also won't be C++. While still probably the most widely used object-oriented language, C++ is too hard for most business developers. Just as important, it's full of needless complexities, such as pointers, that aren't relevant for typical business applications. Finally, it won't be PowerBuilder or Delphi or any of the other client-focused languages promoted by smaller companies over the last few years. These languages never developed a strong server-side presence, and so they're not viable candidates to dominate the future.
This leaves two choices: Visual Basic and Java. For the typical organization building new server-side business logic, especially in the context of an application server, one of these languages is likely to be the right choice. And five years from now, one of them will probably have emerged as the next COBOL, the dominant language for building new business applications. Before looking at the chances for each one, it's important to note that using Java as a programming language doesn't imply using the Java environment -- it's possible to build Java applications for Microsoft systems that directly use Windows NT services. What I'm talking about here is purely the programming language aspects of Java, not the various interfaces its supporters have defined to hide whatever operating system is in use.
As with so many technology decisions today, this one is rooted in the choice of a server operating system. For business logic developed on NT, both languages are possible; for applications written for Unix or mainframes, VB can't be used -- it's simply not available on those systems. This makes it a foregone conclusion that Java will be the dominant language for developing new applications on non-Microsoft operating systems. IBM made clear that Java is now the most important language for development on any of its systems, including mainframes. Virtually every other non-Microsoft vendor in this space has also made a strong commitment to Java. If NT fails to become the dominant platform for building new business logic, VB will fail to become the new COBOL, and Java will take that role.
I think NT is very likely to dominate as the home for new server apps, however, which makes VB a strong candidate for the role of COBOL's successor. In VB's favor are its widespread popularity, its ease of use, and especially Microsoft's promotion of the language as its preferred tool for building server-side business logic. Go to any of the major Microsoft conferences -- TechEd, the Professional Developers Conference (PDC), and others -- and notice what language the speakers use to illustrate their points. Nine times out of 10 it's VB, even at the formerly C++-focused PDC. Support for new features in the Windows and Windows NT environments seems to show up first in VB, then appear later in Microsoft's other language environments. Although VB was once only an interpreted language, it can now be compiled as well, making it suitable for building relatively high-performance applications.
Microsoft's support for Java, by contrast, has trailed its support for VB. Even though Visual J++ is a solid product, its first release lacked a number of important features, giving the impression that VB remained Redmond's flagship language for business development. Also, Java is somewhat more complex than VB, with more reliance on threads and other programming concepts that can be difficult for some business-oriented developers. Yet the second release of Microsoft's Visual J++ greatly enhanced what the language can do in a Windows NT world, and for Microsoft, the similarity between Java's view of objects and the view defined by COM makes Java an attractive tool for building Windows applications.
Ultimately, whether Java becomes the dominant language for building applications in the Windows and Windows NT environments is in Microsoft's hands. If they commit to making Java the equal of Visual Basic for building applications, proving this commitment by adding support for new system features to Visual J++ as rapidly as for VB, Java has an excellent chance of being the next COBOL across all platforms. But can we really expect Microsoft to allow Java, a language over which they don't have total control, to become the dominant tool for Windows NT development? Wouldn't Microsoft prefer to keep VB in this role since they can unilaterally dictate its future? From Microsoft's point of view, it's hard to see why the ascension of Java as the next COBOL would be a good thing. Even if Java is technically superior to VB, an assertion that many argue is correct, sound business reasons may keep Microsoft's focus on VB.
If you're choosing a language for a new business development project today, what's the best choice? For applications on non-Microsoft systems, I'd start with Java, if only because it's what your operating system vendor is likely to recommend. On Windows NT, however, I believe the safest choice is still Visual Basic. If Microsoft's commitment to Java gets stronger—if, for example, more than half the code examples at the next TechEd are in Java—I'll change my position. But as long as the creator of the dominant server operating system seems to push it as their primary language for business applications, my bet for the next COBOL remains on VB. --David Chappell is principal of Chappell & Associates (Minneapolis), an education and consulting firm. Contact him at david@chappellassoc.com.