3.4 Microsoft .NET Languages

---

Language choice is probably one of the most contentious debates among developers from whatever background. Partly fueled by fear (i.e., my language must be in demand, because I need a job) and partly fueled by dislikes for language deficiencies (i.e., my language has better semantics), many hours have been spent arguing the importance of different languages. Professional developers have often besmirched, those they consider amateurs, for using 'toy' languages, such as Visual Basic.

In all this, it is important to remember that code is written to build solutions for organizations and businesses. Most business people I speak to don't know one end of Visual C++ from the other, and why should they? It has no bearing on the solution, other than the likely elapsed time to write the code and possible postdevelopment support concerns. Certainly Visual C++ has been held to be the superior development language for building packaged software applications, and Microsoft uses it for most of its development work.

The problem is that it takes most people two to three years to reach a proficient level of skill in Visual C++, which in turn leads to a more costly skills shortage.

Languages like Visual Basic, on the other hand, can be picked up by most IT literate and motivated individuals within a couple of weeks, and certainly within a year, one would expect a developer to have become quite proficient in Visual Basic development. The reason for this is that the development environment and language remove the need for the developer to get involved in complex problems, such as memory management (although the Common Language Runtime [CLR] in Visual Studio .NET has removed this for managed code written in Visual C++ as well). The end result is that there are lots of developers writing Visual Basic code (6 million worldwide according to Microsoft), but there also a lot of dreadful applications with spaghetti code and atrocious performance.

This language debate has now been halted with the release of Visual Studio.NET and its support for language interoperability.

Language interoperability is the ability for a piece of code to interact fully with another piece of code, irrespective of the programming languages used. The end result is maximum reuse of code but, more importantly, maximum reuse of developer expertise.

Visual C++ developers can now work proactively alongside Visual Basic colleagues on the same project, sharing chunks of code to be written, in the knowledge that the CLR will pull the solution together.

Each language that targets the CLR needs to follow some strict rules that permit this interchange of code. These rules are defined in the Common Language Specification, or CLS.

The CLS has a common type system that puts in place a set of rules defining the types that a programmer can use, ensuring type consistency across all languages. A set of metadata rules enables language interoperability by defining a uniform way for storing and retrieving information about these types. Compilers store type information as metadata, which the CLR then uses to provide services during execution. Without this it would be impossible to read values into and out of the memory stack, and types would be overwritten in the heap, leading to program crashes.

The level of code interoperability is tremendous. Types can inherit implementation from other types, pass objects to another type's methods, and call methods defined by other types. Exception handling is now consistent and exceptions raised in one language can be trapped and dealt with by an object written in another language.

The following examples carry out the exact same task, selecting data from a SQL Server database, but they are written in different CLS- compatible languages:

• Visual Basic.NET

Dim s as String  s = "loconumbers"  Dim cmd As New SqlCommand("select * from " & s, sqlconn)  cmd.ExecuteReader()  

• C#

string s = "loconumbers";  SqlCommand cmd = new SqlCommand("select * from "+s,  sqlconn);  cmd.ExecuteReader();  

• Visual C++

String *s = S"loconumbers";  SqlCommand cmd = new SqlCommand(String::Concat  (S"select * from ", s),sqlconn);  cmd.ExecuteReader();   

• J#

String s = "loconumbers";   SqlCommand cmd = new SqlCommand("select * from "+s,  sqlconn);  cmd.ExecuteReader();  

• COBOL

ENVIRONMENT DIVISION. CONFIGURATION SECTION. REPOSITORY.       CLASS SqlCommand AS  "System.Data.SqlClient.SqlCommand"       CLASS SqlConnection AS  "System.Data.SqlClient.SqlConnection".  DATA DIVISION.   WORKING-STORAGE SECTION.  01 str PIC X(50).  01 cmd-string PIC X(50).  01 cmd OBJECT REFERENCE SqlCommand.  01 sqlconn OBJECT REFERENCE SqlConnection.  PROCEDURE DIVISION.    *> Establish the SQL connection.  MOVE "loconumbers" TO str.  STRING "select * from " DELIMITED BY SIZE,     str DELIMITED BY " " INTO cmd-string.  INVOKE SqlCommand "NEW" USING BY VALUE cmd-string sqlconn  RETURNING cmd.   INVOKE cmd "ExecuteReader".  

• Mondrian

ExecuteReader = invoke  System.Data.SqlClient.ExecuteReader(); SqlCommand = create  System.Data.SqlClient.SqlCommand(String,\                   System.Data.SqlClient.SqlConnection); query = sqlconn -> let{ s = "loconumbers"; } in {    cmd <- SqlCommand ("select * from "+s, sqlconn);    cmd # ExecuteReader(); };

---