From: www.itworld.com

Microsoft's C# public beta hits a high note

January 31, 2001 —

Choosing a language for enterprise Windows development isn't as easy as it used to be. C++ has always been the best choice for commercial development, but today's overburdened developers lack the time and patience for C++'s code-compile-debug cycle, made endless by leaks and potholes unwittingly written into the code. Even though Windows C++ programming has gotten easier (what was as unpleasant as a root canal is now a mere poke in the eye), Internet-time scheduling leaves no slack for programmers to fight with their tools.

Compared to C++, Java offers shorter development cycles, safer code, and cross-platform execution. Java is not ideal, being a sharp departure from C++ and generally fitting Windows like a foot in a glove, but Java seems the only smart choice for enterprise projects.

The defection of Windows developers to Java wasn't lost on Microsoft Corp., which hurriedly released a public pre-beta of the .Net SDK (software development kit). This 86MB download is a working preview of what Windows will become, and it includes a compiler for C#, a new programming language pronounced "C sharp."

This Microsoft-devised variant of C++ is relief for beleaguered Windows C++ developers. Unlike C++, and certainly unlike Java, C# provides easy access to native Windows services, including networked objects, UIs, and Internet communication. Like Java, C# greatly enhances stability by preventing common programming errors and automatically managing resources.

If you already know C++, C# is much easier to learn than Java. C# is a standards-track language, managed not by Microsoft but by the European Computer Manufacturers Association (ECMA),the same independent body that looks after JavaScript. And although the pre-beta doesn't even hint at it, Microsoft has telegraphed its intent to plant .Net and C# on non-Windows platforms.

Critics warn that C# and .Net are only pre-beta, the merest step beyond vaporware. Even though it is not cleared for production use, we've been working with C# constantly for almost a month, and the pre-beta works better than some shipping compilers we've used. In fact, the compiler works well enough that developers are already swapping C# code on Usenet and Web forums such as csharpindex.com.

What's wrong with C++?

Java's creators are critical of C++'s laissez-faire design, which gives C++ developers a free hand, including unregulated access to system resources and the power to reshape the language itself. But the language is as unforgiving as it is powerful. Coding errors can result in resource leaks, invalid or malicious memory access, and other problems that are notoriously difficult to debug.

Java, in the interest of more stable applications, eliminates access to C++ facilities such as manual memory allocation, pointers (direct access to memory), passing arguments by reference, and overloaded operators. In return, Java developers gain an easier approach to object definition and usage, automatic memory management, portability across platforms, and a huge library of predefined Java objects.

Java's brilliant design changed enterprise software development. But in doing so it deviated significantly from C++ syntax, slowing Java's adoption by enterprise C++ developers who found some of Java's design choices difficult to swallow.

In contrast, C# is C++ extended with Javalike features, including automatic memory and object lifetime management, interpreted execution, easy access to external objects, and simplified object creation. Useful C++ concepts abandoned by Java, including overloaded operators and reference arguments, are maintained in C#. Pointers, banished from Java as the most dangerous of C++'s features, are not removed from C# but are caged: Pointers may be used only in sections of code tagged as unsafe.

Adjusting from C++ to C# is like switching from a stick shift to an automatic transmission. In C++, you must explicitly allocate and free the memory used by objects, whereas C# allocates memory automatically. Memory occupied by C# objects will be freed when an object is no longer in use -- that's garbage collection, a key benefit of Java.

In C++, you must use long lists of included files to gain access to system services, the majority of which are not exposed to your program as objects. In C#, system services are transparently wrapped in C#-compatible objects. In C++, it's difficult to map C++ objects to Windows' COM (Component Object Model), but objects in C# are automatically mapped to the .Net model and can be accessed from any .Net language. .Net objects are expressed using each language's native syntax. The .Net layer makes sure that objects work across languages, so no data conversion or external object mapping is necessary.

The most difficult part of learning C# is training yourself not to pump the clutch and reach for the gearshift. Once you adjust, C# is much easier and safer to drive than C++. Although Java requires that C++ developers learn new ways of doing things, most of the transition from C++ to C# is leaving out the ugly object and memory management code written into every C++ application. Allowing the use of pointers and references gives C# developers direct, simple access to facilities outside the .Net framework, including 32-bit Windows DLLs.

We would not attempt to port any Windows C++ application of consequence to Java, but we would convert one, probably in stages, to C#. The resulting application would gain C#'s stability and .Net's cross-language portability. Microsoft seems to have invested considerable care in maintaining easy access to current Windows facilities, even those such as COM that are supplanted by .Net.

Except for modules requiring maximum performance -- that is still C++'s domain -- migrating to C# will be the smartest way to adapt existing C++ applications to .Net. We found that Microsoft's .Net extensions to Visual C++ make integration with C# code quite easy.

Let's move on

C# is so much like C++ that it provokes little excitement by itself. C# exists because Microsoft needed a Javalike language for .Net, but Java itself was out of the question.

Some of us are C++ developers and thus appreciate that C# keeps most of the quirky, powerful C++ features we like. Regardless of Microsoft's motives, we appreciate that C# flew straight into the hands of the ECMA. ECMA manages the language, so we will see non-Microsoft C# tools and compilers as well as contributions to the language from other learned sources.

Third parties creating C# tools won't have to license the language from Microsoft, so the cost of tools should remain low. In contrast, Sun withdrew Java from the standards track, so only Sun can evolve Java.

Microsoft starts the race for enterprise development mind share behind Sun because .Net, on which C# depends, runs only on Windows. Microsoft gains some ground by making the .Net framework language-independent. Even in the beta, you can write .Net applications in C++, C#, Visual Basic (VB), JavaScript, and Visual FoxPro. They produce the intermediate byte code language called IL (intermediate language), and they share a framework-defined set of architecture-independent data types.

You can mix code from several languages with impunity because there are no VB, C#, or JavaScript objects; there are only .Net objects, and they're all connected.

C++ will also remain the Windows performance champ, being the only Microsoft language that can compile directly to native code instead of IL.

Traditionally, developers choose a single language for each project so that code from different developers will interconnect; .Net makes this unnecessary. You can put C#, VB, C++, and JavaScript coders on one project and let the .Net layer ensure that all the pieces get along.

Sweetening the deal, still more languages are on the way. Third parties have already signed up to do Cobol and Eiffel compilers for .Net; your .Net developers can code in the languages they know best and like most. That means less ramp-up time, lower training costs, cleaner code, and happy, productive developers.

The first task for C# is to give C++ developers access to the .Net framework. That is no small thing, because .Net is destined to be the heart of Windows enterprise applications. At the recent Professional Developers Conference (PDC) in Orlando, Fla., where .Net made its debut, Microsoft made it clear that .Net is not only hardware-independent but also highly portable across OSes.

Microsoft is wisely keeping mum about .Net migration plans; getting .Net running on Windows is understandably its top priority. But we'd lay odds that .Net will soon roost in Solaris or Linux. Once .Net extends its reach beyond Windows, C# will become a true Java competitor. Until then, C# is a well-hewn successor to C++ for enterprise Windows applications. That's not a bad start.

InfoWorld