Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

Part 1

Since .NET was first announced several years ago, an often touted benefit of the technology has been the ability to mix code written in different (and supported) languages such as VB.NET and C# within the same application. Because these .NET languages are compiled down to an intermediate form (MSIL) that is then interpreted/compiled by the .NET Runtime (CLR), it is possible for very different languages to not only interoperate (as in the COM era) but to interact at a much richer level—sharing classes, data types, interfaces, enumerations and so on. This makes it possible for development teams with skills in multiple languages to use the language that best suites the task at hand while allowing for bundling the code into a single application. Of course, it also allows development teams which have members more comfortable with a specific language to keep working in that language and still contribute to the application without forcing language uniformity.

That's the theory...

Reality is a bit different. The vast majority of development teams tend to concentrate in the use of a single language based on their shared past, the predominant language used in the organization, or a corporate directive. Although intermixing languages works in .NET (and is indispensable when needed), it is very seldom the preferred choice of development teams. Most developers, even if they've had formal training in a university, start out in a single language. At one time, this was Pascal or Basic. Very often now it's Java since that is the preferred language in many universities now. Assuming that the language is found to be reasonably useful and enjoyable by the developer, they likely get centered on that language family. I've found that developers tend to (these days) either prefer a language that leans towards being concise and frugal with syntax at the expense of intelligibility, or a verbose language that is easy to understand at the expense of more typing.

In times past, nothing could get developers more worked up than by starting a conversation with the statement "I think language X is better than language Y." Often these arguments boiled down to perceptions of performance or productivity. The arguments between C++ and Visual Basic developers are a classic case: Is it more important to have code that runs very fast and is close to the hardware platform offering multiple optimization opportunities, or to have code that can be written quickly and delivered to market orders of magnitude faster? Both sides have a point and neither is wrong. Sometimes performance matters greatly even today with typical business applications, and sometimes getting the job done as quickly as possible is the highest concern. However, in .NET (particularly when using Visual Studio .NET 2005) many, if not most of these considerations are now moot and obsolete.

How so, you ask?

As I stated earlier, one of the first things you learn about .NET when you first begin to dig into the technology is the idea that code written in a .NET language is not compiled down to machine code as with previous technologies. Instead, it is compiled down to a byte code or intermediate language (also known as IL, or MSIL to be accurate) that is interpreted by a runtime. In the case of the .NET CLR, this IL is actually just-in-time compiled down to machine code for the target platform and cached as needed rather than strictly interpreted. This results in performance close to what you would see with a true compiled application. One of the ways this just-in-time compilation can actually be superior in terms of performance to a natively compiled application in, say, C++ is that the CLR can make use of information about the processor to optimize the instruction set (or pipelining or any other CPU feature) on-the-fly without intervention by the developer. With a natively compiled application, you have to make this choice up front and most applications just stick with the baseline Pentium instruction set (or Any CPU option) because it can be impossible to know in advance when using anything else is acceptable. Delaying this decision until it is known can result in superior performance.

Since all .NET languages are compiled down to MSIL, it is much less of an issue how expressive or concise the specific language may be. Although there have been statements periodically on the Internet that language X is faster (or generates smaller code) than language Y, in reality these assertions are misleading. There may be corner cases where a specific syntax in language X generates smaller amounts of IL than another language but that can be due to the optimization capabilities of the language compiler itself, or the fact that a language has a keyword or expression that mirrors an esoteric aspect of the IL that another language does not. But these are exceptions that developers will rarely encounter.

The issue of language verbosity (or conciseness) used to center around statements like "I don't want to have to type more than I have to" or "I like english words and clear structure rather than a lot of symbols in my code." The former is mostly taken care of these days by technologies such as Intellisense in Visual Studio .NET 2005—keywords, statements, and even whole snippets of code can be auto-generated as the developer types, significantly reducing the actual amount of typing. The latter is again a matter of developer preference, and as I mentioned at the outset, is often rooted in their initial language exposure and natural inclination.

For development teams who prefer or insist on working in a single language as much as possible, the prospect of inheriting or acquiring an application that was written in an alternative .NET language can be unacceptable. For organizations that have invested time and effort in training developers in .NET (often in a single language), the long term costs of finding, training and keeping developers who understand multiple languages at an acceptable level of competence can be prohibitive. The decision then becomes one of "do we rewrite the application in the preferred language," or "do we port/migrate the application to our preferred language"? Before .NET, this was often not even an option due to the dramatic differences between languages and little to no support for migration in third-party tools. Fortunately, because of the IL and CLR, .NET provides a means to migrate many .NET languages from one to another. Be forewarned, though: this is not an absolute statement—some .NET languages may have syntax or expression capabilities that exceed those of the target language (the proverbial square peg in a round hole) and it may be either impossible or impractical to accommodate these differences.

However, the majority of developers in .NET use one of two languages at the present time—VB.NET or C#. With the release of .NET 2.0 and VS.NET 2005, VB.NET is now VB.NET 2005 and C# is C# 2.0, with 3.0 on the horizon. These two workhorse languages come from very different beginnings and philosophies although they are both rooted in the same language ancestor—Algol—so they share many of the same assumptions about statement syntax and program flow.

VB.NET 2005 is the latest version of the popular Basic language that was developed at Dartmouth University in the 1960s as a teaching language. Since that time, Basic has evolved to include additional keywords, statement rigor and expressiveness and modern capabilities such as classes, callbacks, interfaces, enumerations, functions, properties and a host of access modifiers such as ReadOnly, WriteOnly, Public, and Private. In the current VB.NET incarnation, Microsoft has pushed VB.NET to be a full-fledged development language on par with other traditional languages, and partially away from a pure focus on ease-of-use and approachability.

C# 2.0 is the latest version of the C# language, designed and developed at Microsoft for .NET, although it has been submitted for standardization, similar to C++ and C. C# is rooted in the "C" family of languages first developed in the early 1970's at AT&T Bell Labs, and which now includes C, C++ and Sun Microsystems' Java. The early C family, including C++, is focused on staying close to the available hardware and allowing for maximum developer control over how that code is interpreted by the compiler. The terseness of syntax in this family of languages is a historical design feature that developers either highly prefer or highly dislike. C# furthered this evolution of the 'C' family by building on top of C++, Java and a variety of other languages that evolved in the 1980's and 1990's. Because it is very close to the earlier C and C++ languages in syntax and expression, most developers who are working with or familiar with C/C++ find C# to be a natural next step in .NET.

The fact that VB.NET and C# are rooted in the same language ancestor, and that Microsoft has expended a huge amount of effort to keep these two languages at nearly feature parity means that the idea of migrating from one to the other is perfectly reasonable. Having said that though, there are areas where VB.NET and C# differ in syntax that requires a bit more effort on the part of any development team who wishes to migrate an application from one language to another. This series of articles will explore some of these differences and how developers can anticipate and reduce the effort they will need to expend in any migration.

Whether you are moving to .NET from Win32 or have been using .NET since 1.0, I encourage you to listen to .NET Cast an Internet radio show that I host and produce for CMP Media. Hear from the people behind .NET and key experts in the industry working with it. For those of you with RSS readers, you can find the feed at http://syndication.sdmediagroup.com/feeds/public/cmp_podcast_dotnet.xml.

Mark M. Baker is the Chief of Research & Development at BNA Software located in Washington, D.C.
Do you have a Windows development question? Send it to dotnetcast@sunburstsoftware.com.

RELATED ARTICLES Are Server Controls Still Useful? Microsoft Kicks Off Embedded Device Competition Microsoft, Universities Launch Game Institute Microsoft Unveils Next Version of Visual Studio and .NET Framework ASP.NET and Design Patterns		TOP 5 ARTICLES No Top Articles.