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"
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 ??
1 comment:
I have posted the same article in the Kolkata UG site and my friend Palash has given some nice comments.... I am just copying it here as a comments of Palash
..............................
I have couple of things to add here –
Performance – C# is faster than VB.NET; it cannot be a myth. There is a possibility that performance of same program might vary from language to language. Though finally it is MSIL which will be executed, but it is language-compiler who generates this code. It is possible that compiler of X language generates more crispy & efficient MSIL code than compiler of Y language. Obviously X will be faster than Y in that case. So it is possible that C# is faster or slower than VB.
Popularity – Though C# is the most popular one as of now; VB (actually future version of it) will take the pole when normal people will start writing their own code. The reason is C# is much more structured where VB is more verbose. For a normal user (for example my dad who doesn’t know anything about programming) it’s very easy to write & read something in verbose languages (like any human language). This is the extreme target of language writers’ community & that is what VB is heading towards.
Why only C# was submitted to the ECMA? – It is not because of C# is better or worse than VB; it is because HP, Intel & few other companies had participated in standardization of it before submitting it to ECMA. Whereas VB.NET is completely owned by Microsoft. I guess Microsoft wants to go a long way with VB before submitting it for any standardization. By the way, MONO is not C# specific; it is another .NET CLI (& CLR) implementation – MSIL code written in any languages will work on it. Since C# specification is open; they also implemented one C# compiler; but that doesn’t mean compiled VB code will not work on MONO.
Choosing one between C# & VB – It should be done by developers only; not by architect. That is the whole concept of CLI - a project can be mix of languages. At architect-level, C# or VB doesn’t make any difference; it is only .NET framework which he/she has to consider.
And finally MI (Multiple inheritance) – We have mainly two kinds of inheritance … MI of Implementation & MI of Contracts (Interface). All modern languages (JAVA, C# & any other NET.CLI based languages) stop supporting MI of Implementation; but they do support MI of Interface. I don’t know how many of us are from C++ background & how many of them have used MI of Implementation. I never feel the need of it in C++. The reason of discontinuing the support of MI of Implementation is very less ROI (Return On Investment). It has few disadvantages –
It produce less-readable & ambiguous code (I guess we all know the Inheritance-diamond problem)
It reduce the performance because of extra dynamic bindings
Implementation of a compiler; which will support MI of Implementation; is more complex & it has to sacrifice few code-optimization tricks
Moreover, there is no rock-solid requirement of it; so it doesn’t pay for itself.
Post a Comment