Beyond C# and VB.NET: Should You Care
About Other .NET Languages?
David Chappell - June 25
, 2002
One of the advantages of .NET over the Java world is that developers can choose their language. Unlike the Java virtual machine, the .NET Frameworks Common Language Runtime (CLR) was designed to support multiple languages, and it does. COBOL, Perl, Python, Eiffel, and many others are available in versions based on the CLR..
But should you care? C# and VB.NET are all but certain to be the dominant languages for building Framework-based code (with Managed C++ in third place), so who needs more choices? And are those choices really viable for mainstream development?
Take Fujitsus NetCOBOL for .NET. Despite the products unwieldy name, its an admirable effort, and it certainly does have a market. NetCOBOL supports COBOL 85, the conventional procedural version of the language. This makes it possible to port existing COBOL code from IBM mainframes, or retiring HP3000s or other older systems to the modern Windows world. Its not just a recompile, howeverthe port will take some work. This shouldnt be surprising: Some parts of current COBOL applications, such as calls to CICS, arent available for the .NET environment; whereas other parts, such as user interfaces, are so different that they cant effectively be moved. Ports are always imperfect, though, and NetCOBOL certainly makes the task possible. For organizations that wish to preserve existing COBOL business logic, NetCOBOL for .NET looks like a fine solution.
Yet even though NetCOBOL for .NET is certainly useful for some kinds of porting problems, its hard to see why anyone would choose to write a new application using this tool. Along with COBOL 85, the product also supports an object-oriented superset of the base COBOL language, much like C++ is a superset of C. Although a nearly completed standard exists for an object-oriented COBOL, the creators of NetCOBOL for .NET faced the conflict that confronts anybody who tries to put an existing OO language on the CLR: Whose semantics win? The CLR effectively mandates a large set of behaviors, some of which differ from those defined in the forthcoming COBOL standard. Faced with this problem, the creators of NetCOBOL for .NET choose to model their object-oriented version more on the CLR than on the COBOL standard. This choice makes good sense, but the result is a language thats semantically very close to C# and VB.NET. The primary difference is that it uses a COBOL-derived syntax.
Why is this useful? Retraining todays COBOL programmers for the wholly different world of .NET is such a big job that its hard to see why letting them use a familiar syntax would help. And because the documentation for the .NET Framework class library shows examples only in the standard Microsoft languages, those developers would likely face challenges when exploiting the librarys functionality. Other smaller issues exist, too. NetCOBOL for .NET doesnt generate verifiable MSIL, for instance, which means that the CLRs built-in code security features cant be used. While using this tool to port existing COBOL applications to Windows will make sense for some organizations, Id be surprised to see it move much beyond that niche.
But, of course, COBOL isnt the only non-Microsoft language choice. What about Perl and Python, two more modern languages in wide use today? ActiveState, a Canadian company headquartered in Vancouver, provides CLR-based subsets of Perl and Python. Yet ActiveState explicitly says that this code should be characterized as a research effort, and that the implementations arent intended for doing serious work. While ActiveState does provide Perl and Python plug-ins for Visual Studio.NET, the resulting code is not based on the CLR, and so doesnt generate MSIL. Developers can use these tools to build Perl and Python applications that interact quite effectively with CLR-based code, but they dont qualify as .NET Framework-based languages.
In the end, the diverse set of languages announced for the .NET Framework probably doesnt matter much. Because of Microsofts strong support, expressed most powerfully in Visual Studio.NET, C# and Visual Basic.NET will be dominant for creating new CLR-based applications. The other languages might be interesting for universities or for specialized markets, but theyre unlikely to hold much attraction for professional developers. Most Windows developers today believe that Visual Studio is the best tool for building code on Windows. Just as in the pre-.NET world, I expect the languages it supports to be the dominant choices for Windows developers in the future.