Columns

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 Framework’s 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 Fujitsu’s NetCOBOL for .NET. Despite the product’s unwieldy name, it’s 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. It’s not just a recompile, however—the port will take some work. This shouldn’t be surprising: Some parts of current COBOL applications, such as calls to CICS, aren’t available for the .NET environment; whereas other parts, such as user interfaces, are so different that they can’t 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, it’s 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 that’s semantically very close to C# and VB.NET. The primary difference is that it uses a COBOL-derived syntax.

Why is this useful? Retraining today’s COBOL programmers for the wholly different world of .NET is such a big job that it’s 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 library’s functionality. Other smaller issues exist, too. NetCOBOL for .NET doesn’t generate verifiable MSIL, for instance, which means that the CLR’s built-in code security features can’t be used. While using this tool to port existing COBOL applications to Windows will make sense for some organizations, I’d be surprised to see it move much beyond that niche.

But, of course, COBOL isn’t 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 aren’t 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 doesn’t generate MSIL. Developers can use these tools to build Perl and Python applications that interact quite effectively with CLR-based code, but they don’t qualify as .NET Framework-based languages.

In the end, the diverse set of languages announced for the .NET Framework probably doesn’t matter much. Because of Microsoft’s 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 they’re 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.