By: Cary Jensen
Abstract: The language wars are over, the developers have won. In the new world of .NET development, a common class library provides freedom of choice.
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.
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.
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.
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.
Cary Jensen is President of Jensen Data Systems, Inc., a Texas-based.
) 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.
Server Response from: SC1