As far as software development goes, there have been a number of critical milestones in the past 50 years. Some of the most significant include the transition from machine language to more human-readable assembly language instructions, the introduction in the 60s of third generation languages where a compiler generates the lower-level instructions, the development of object-oriented languages in the 70s, and the evolution to component-based programming beginning in the late 80s. Arguably, the adoption of the .NET framework represents a similar paradigm shift, that while maybe not quite as radical as some of the earlier transitions, will undoubtedly directly affect more programmers than most of the previous changes.

As with many of the past advancements, this period of change is accompanied by an uncertainty, a lack of direction. Sort of like what happens when coastal waters reach low tide, pausing before the inevitable surge of the incoming tide.

For many software developers and project managers, this sense of insecurity has been lingering for several years. But lately, as .NET accelerates towards the mainstream, the need to prepare for the coming change has likewise increased.

For two groups of information technology professionals, the sense of urgency is particularly strong. Specifically, both project managers and the front-line developers responsible for building Windows software have been asking the same pressing question. "What programming language should I use to best leverage the .NET framework?"

I've been asked this question many times over the past year or so, but the frequency has increased significantly since summer, spiking recently at the Borland Conference in San Jose, California and the European Borland Conference in Amsterdam, the Netherlands.

I might be wrong, but I think I know the answer. And the news is very good. In fact, as far as Windows developers are concerned, I believe that the adoption of the .NET framework signals that the language wars are over, and the developers have won.

The Language Issue

Until now, there have been fewer issues in the world of software development as strategic, political, and contentious as the choice of programming language. But this choice was critical, in large part because choice of language also equated to the choice of class library or framework. 

Consider this question. What is the difference between a Visual C++ developer and a Delphi developer? Better still, what is the difference between a Visual C++ developer and a Visual Basic developer? 

The answer is not syntax. Syntax is programmatic garnish. While we live within the syntax of a language, it constitutes one of the easiest aspects of a programming language to master.

The answer is also not entirely the integrated development environment (IDE), though this issue has far more influence than syntax. The IDE is the programmer's virtual workbench, and a better IDE can make a developer more productive. But while the features of an IDE are important, there is another factor that has had a far greater influence in distinguishing between languages.

What has traditionally separated language from language is the supporting libraries. These include runtime libraries, class libraries, third-party libraries, and the like. In object-based development environments, like Visual Basic, MS Access, and Paradox for Windows, the selection of available objects plays a role similar to the libraries in third generation languages.

While the specific syntax of a language is something that can be mastered in a matter of days, the libraries and objects that you program with represent your real investment in a language. The more productive and successful developer is usually the one who has greater mastery of the supporting libraries, classes, and objects, and this competence is often the result of years of experience. 

Knowing which procedures and classes already exist within your libraries can save countless hours of research. Likewise, proficiency with a library saves a developer from unnecessarily re-inventing the wheel, instead relying on existing, time-tested code.

The .NET Influence

As a .NET developer using a first-class .NET language, you are using the same class library as every other developer using a first-class .NET language. What once accounted for the greatest individual difference between programming languages, and the greatest source of investment, experience-wise, goes away in the world of .NET development. 

For example, regardless of which language you develop in, be it C#, Delphi 8 for .NET, or Fujitsu NetCOBOL for .NET, the DataSet class in the System.Data namespace of the .NET framework class library (FCL) is the same. It has the same methods, same properties, and same events. And it works the same, independent of the .NET language used to manipulate it.

But the benefits of .NET extend well beyond the commonality of the native FCL. It also extends to third-party components, vertical market libraries, and even to your organization's proprietary code. Specifically, code written in one .NET language can seamlessly interact with code written in any other .NET language. 

This interoperability extends as far as the class hierarchies themselves. A class written in one .NET language can be extended by any other .NET language, so long as the ancestor class declaration does not specifically prohibit descendants.  

The impact of the .NET framework will be remarkable. For one thing, any developer sufficiently familiar with the FCL should have little trouble maintaining or debugging .NET code, even if it is not written in their preferred language. Since most of the custom code in component-based development involves the configuration and manipulation of existing components, there will be more similarities between code written in different languages than ever before. While the syntax may differ, the classes being used will be the same.

This convergence represents a major evolution in software development, one that was not really possible before now. Only with the lessons learned from past frameworks, including MFC (Microsoft Foundation Classes), VCL (Visual Component Library), OWL (Object Windows Library), and of course Java, to name of few, was it possible to construct a framework comprehensive enough to satisfy the essential needs of most Windows software developers. We are indeed the benefactors of more than 50 years of advances in software technology.

Choosing a .NET Language  

Given the common features available in all first-class .NET languages, given the unparalleled interoperability afforded .NET developers regardless of the language they develop in, does it matter which language you choose for your .NET development? You might be surprised by what I think. I firmly believe that the answer is yes.

Yes, it matters. Why? Because two different languages are just that, different, even if they both support the .NET framework. For example, Delphi 8 for the Microsoft .NET framework includes full support for the FCL, just as any first-class .NET language must. But it includes support for what Borland is calling the VCL for .NET, as well as support for a .NET version of the Delphi runtime library (RTL) and the Borland Database Engine (BDE.NET). This means that a great volume of existing code written in Delphi can be easily compiled into IL (intermediate language, the common source code used by .NET just-in-time (JIT) compilers).

Even though individual .NET languages are different, I stand behind my previous assertion that the language wars are over. No longer should there be an argument over which language is better, one that all too often takes on religious overtones. Instead, it is replaced with a more level-headed conclusion that, besides their similarities, different languages have different strengths.

In the end, the question is not which language is better, but which language is appropriate for a particular solution. In some cases, it doesn't matter at all. When any first-class .NET language can do the job as well as any other, other factors enter into the equation, such as the built-in features of the IDE as well as available IDE add-ons. 

If you manage software developers, this means that you have greater flexibility. In some situations you can simply put your next available developer on the job and let them use their tool of choice, be it VB for .NET, C#, Delphi for .NET, or whatever. As long as they know what they are doing, they can get the job done, without building any barriers to interoperability between the various pieces of your project. 

You also have the power to be more efficient. While C# might be adequate for the job, a Delphi 8 for .NET developer, being familiar with the .NET versions of both the VCL and RTL, may be able to complete the job significantly faster with less custom code. (Any time you reduce the amount of custom code, you benefit from a correlated reduction in the amount of code that must be maintained). 

If you are a software developer, there are many advantages for you as well. For example, any experience with a .NET language will make your skills valuable. Over time, you should see project managers expressing less concern over which language you use (old habits are hard to break), and more appreciation for the skills that you and your tool set bring to the job. 

And, if circumstances beyond your control require that you change to another .NET language, you will quickly learn that the time you have invested in the .NET FCL was time well spent, regardless of which language you used. Your experience and knowledge will transfer nicely to any .NET language you need to employ. Of course, you might have to become familiar with a different syntax, or a new IDE, but these are minor obstacles, compared with having to learn a completely new class library.

About the Author

Cary Jensen is President of Jensen Data Systems, Inc., a Texas-based training and consulting company that won the 2002 and 2003 Delphi Informant Magazine Readers Choice Awards for Best Training. He is the author and presenter for Delphi Developer Days 2004 (www.DelphiDeveloperDays.com) and Advantage Developer Days 2004 (www.AdvantageDeveloperDays.com), information-packed seminars that tour North America and Europe. Cary is also an award-winning, best-selling co-author of nineteen books, including Advantage Database Server: The Official Guide (2003, McGraw-Hill/Osborne), Building Kylix Applications (2001, Osborne/McGraw-Hill), Oracle JDeveloper (1999, Oracle Press), JBuilder Essentials (1998, Osborne/McGraw-Hill), and Delphi In Depth (1996, Osborne/McGraw-Hill). For information about onsite training and consulting you can contact Cary at cjensen@jensendatasystems.com, or visit his Web site at www.JensenDataSystems.com.

Copyright ) 2003 - 2004 Cary Jensen, Jensen Data Systems, Inc.
ALL RIGHTS RESERVED. NO PART OF THIS DOCUMENT CAN BE COPIED IN ANY FORM WITHOUT THE EXPRESS, WRITTEN CONSENT OF THE AUTHOR.