C# OR VB.NET

Few days back (unfortunately) I got involved in a debate with an gentleman when we were discussing over .NET programming, and he found that I am kind of biased on C#, so he asked me "Why did you choose C# as your programming language, not VB.NET ?" and then we both tried to prove our points for next half an hour.

I am sure this is the most common debate among .NET programmers( since VB.NET and C# are most dominant language in .NET platform).. the C# programmers cite heaps of points to prove C# is best language so far and VB.NET programmers follow the same route to prove that C# programmers are all unrealistic etc etc.
The mostly used points come in the discussion( read debate ) are

1) Programming style(syntax and semantics): C# is rule based<>, VB is verbose but at the same time gives flexibility to the developers.

2) Availability of futures: Like VB.NET has a feature "X" which is absent in C# and vice versa.

3) Performance of MSIL : It is believed that C# code is faster than VB.NET code( I am not sure whether it is just a myth or not ) and VB.NET group think it just a MYTH.

4) IDE support : For example when we need to define a property, in VB.NET all we need to do is write "property" and a hit on enter key, the IDE write the get and set for us.

5)Additional features : For example C# allow us to write unmanaged code and most importantly we can use "POINTER".
May be some more points which I am not aware off.

Honestly speaking there are hardly any realistic difference between these two language, I have personally worked on both the languages, and to be very frank only difference I have found is the programming style, that's all. Both the language use same class library comes with .NET framework, same OOP features supported, same runtime, same garbage collector, like in the earlier days we used to compare between VB and C++ programmers and it is a truth that, C++ programmers(mostly) looked down upon the VB programmer, to them VB programmers don't know OOP, they don't know design patterns, VB code is slow etc etc.
But that's not the case today, VB.NET allow to do almost all the features supported by C#, so why still differentiate between these two language ?

So, here comes another turn ...if there is no difference at all how to choose one of them ? As we commonly say VB programmer will choose VB.NET and C++/Java programmer will choose C#, but let us see how far this statement is correct ? If you go by a statistics( published by Evans Data Corp, Santa Cruz ), it says that C# is most popular( and used ) language in the .NET platform, VB.NET comes second, which means there are lot of C++ and Java programmer shifted to .NET environment, well this is partly true as the statistics also revels that a large part of C# developers are x VB developer.

Let us do an introspection, consider you have to start a new project and you are the project leader and you are free to choose a language( VB.NET or C# ) which one will you choose and why ? In deed this is an interesting question and as a matter of fact, I think most of the time we choose a language not thinking much, so the point here is....what are the factors a project leader should consider before choosing a language in the .NET domain ..
so far I can think of the following points,
1) Team strength : Considering there is an excellent team of VB.NET or C#.

2) Any special features needed : Say if we feel we can not develop a solution of the specified problem without "pointer" then we need to use C#.

3) Preference of the Software Architect: Honestly speaking most of the software architects has C++/Java background(well, that's what I have seen, may be my view is biased ), so they would prefer to work on a language which has C++/Java flavor, C# will be simple choice for them, but in that case may be the developers need to train C#.

Is there anything else ?? ... , please update with your comments.

I will finish this article with one confusion .. why only C# was submitted to the ECMA as an international standard, if Microsoft really think VB.NET was/will be a strategic language in long run, why don't they submit it ? anybody has any clue ??

Floating point number .. an interesting issue

Last night I was doing some work and came across a very interesting situation, I have simulated the problem with a simple example, consider I have written a class which has 3 function with the same name , all of them takes one floating point number as an argument.
class MyClass {
void Display( decimal number ) { Console.WriteLine( "{0} {1}", number.GetType(), number ); }

void Display( float number ) { Console.WriteLine( "{0} {1}", number.GetType(), number ); }
void Display( double number ) { Console.WriteLine( "{0} {1}", number.GetType(), number ); }
static void Main( ) { MyClass m = new MyClass(); m.Display( 1000.90 ); Console.ReadLine(); } }

Here, the question is which "Display" function will be get called ? I have tried out lot of numbers and I have found that every time "Display( double number)" get called.
then I have looked into the IL, it looks like the following line ..
IL_0007: ldc.r8 1000.9IL_0010: callvirt instance float64 QuestionsTest.MyClass::Display(float64)

which means it will call the routine which takes 64 bit float, i.e. double, I was wondering why does it happen .... then I have found something form the MSDN library which says "By default, a real numeric literal on the right-hand side of the assignment operator is treated as double, Therefore, to initialize a float variable, use the suffix f or F, and to initialize a decimal variable use the suffix m or M".

I have modified the main routine in the following manner ....
m.Display( 1000.90 );
m.Display( 1000.90f );
m.Display( 1000.90m );

and I found the following output ..
System.Double 1000.9
System.Single 1000.9
System.Decimal 1000.90

So the conclusion is when we have to write routines with same name and will take floating point number as argument we have to be little cautious when we will call them.
Comments are welcome.