As a .net programmer at some point in your life, you probably have gotten into a discussion or at least faced a choice between VB.net and C#.net. Though the argument is never ending on both sides, how do programmer that are bilingual or someone who is just learning feel? What long term productivity impact does this have in development shop or team in general?
Well for me, I clearly have choice in mind, but instead of presenting my views today, I will publish the following list our good friend Jeff Lanning compiled from various sources few years back. Though some of the points have changed with new version of .Net, I hope it provides a good reference for anyone dealing with such a choice. Here it goes; don't forget to put in your two cents:
Reasons to Choose C# over VB.NET:
C# was designed expressly for the .NET platform and Microsoft is standardizing their company on it, which means they have a much deeper investment in C# technologies (language features, compilers, dev tools, etc) than they do in VB.NET. In fact, both Visual Studio and the .NET Framework where written in C# (using C++ as a backend). Furthermore, C# was submitted to, and standardized by, the ECMA group as an open standard while VB remains proprietary.
The C# language is very similar to the other major languages (like Java, JavaScript, C/C++, PHP, and Perl) and shares many of the same concepts, keywords, and syntactical elements. These similarities means a C# programmer will be more able to read, write, and borrow code from those other languages. Most programming books not specific to any one programming language (e.g., books on UML, data structures, OOP concepts, etc.) are likely to include examples in Java.
Outside of the endless language features debate, C# has become the defacto standard for .NET development. A majority of third-party and open source components are written in C#. A majority of advanced programming articles are written in C#. Microsoft's application blocks and other development resources are also provided first in C#, and later converted to VB.NET. If anything, .NET developers owe it to themselves to learn C# for that reason alone (even if they think VB is still the greatest thing since the Apple IIe). As long as they never have to modify or inspect anyone else's .NET code, it may be fine to ignore C# for the time being, but chances are that isn't going to be the case for very long if they want to take advantage of the rapidly growing .NET community's resources.
Most students coming out of college have experience with Java and/or C++, making the transaction to C# quite natural. In addition, these young professionals will likely see VB.NET in the same light as COBOL with its legacy-ridden, verbose BASIC syntax, and be drawn to C# as the best long-term choice for professional grown.
The learning curve going from VB6 to either VB.NET or C# is about the same given that 95% of the effort will be spent learning the object model of the .NET Framework, the new development tools, new OOP concepts, and all the new techniques involved in developing Windows or Web applications in .NET. While VB.NET might seem to be just an improved version of VB6, they are really two languages that are eerily similar, but perversely different. In fact, many experienced VB developers may find C# easier to learn (although a bit more uncomfortable at first) because it helps draw a clean distinction between the two development platforms and avoids many pitfalls associated with bringing a VB6 mindset into the .NET world (like using "On Error GoTo"). There is much to be said for starting with a clean slate.
VB.NET does not have native support for XML embedded documentation, which is used by IntelliSense and to auto-generate class reference documentation directly from the code (with tools like NDoc, DocGen, and many others). The absence of this feature alone is a strong reason to avoid VB.NET on large development projects. This limitation will be fixed in the VS2005 release.
Over the next few years, Microsoft will be differentiating the VB.NET and C# product lines. VB.NET will diverge to provide a better RAD (Rapid Application Development) experience, while C# will diverge to provide a better experience building complicated business frameworks, backend services, application architecture, and reusable object-oriented components. For smaller projects, either language will be a fine choice, but as the size and complexity of applications increase, the productivity gain from C# will likely outweigh that of VB.NET.
Language-specific reasons C# is a better choice…
- less verbosity (e.g., easier to find the "important" words in the code)
- assignment operator is not the same as the comparison operator
- Native XML code documentation (which drives IntelliSense notes)
- does not hide "Advanced Members" of classes
- simplified type casting syntax (instead of directcast(), ctype(), cbool(), etc...)
- case-sensitivity (allowing for better variable names in many cases)
- 'OnError GoTo' is impossible
- option explicit by default (enforces correct type usage)
- cleaner null test expressions ("obj != null" rather than "not obj is nothing")
- better variable scope containment in loops and code blocks
- automatic logic short circuiting (streamlining common test/use logic)
- 'using' blocks for clean/safe resource management
- continue / break statements supported in loops
- embed special string characters ('\n', '\r', '\t', etc…)
- string escaping ('@')
- comment support is just better (multiline comments, XML comments, single-line comments, etc…)
- as operator (string s = obj as string)
- native increment/decrement supported ('--' and '++' )
- intellisense is much less interfering
- arrays are defined with number of elements, not the upper bounded index
- hierarchical constructor calling (ctor() : ctor("defaultValue"))
- array/collection indexer is not the same as a function call ('[0]' vs '(0)')
- 'ByVal' is very misleading (it passes a pointer (ie reference), not a value; whereas 'ByRef' passes a pointer to a pointer)
- unsigned values (uint, ulong)
- P/Invoke makes much more sense, and is uberly easier to figure out
- doesn't hide delegate usage (AddressOf)
- more optimized MSIL generation
- operator overloading
- pointers
- event syntax
- delegate syntax
- unmanaged/unsafe code supported
- 'Default Namespace' doesn't just prefix your classes namespace
- EntryPoint isn't hidden ([STATThread] static void Main(string[] args))
From a discussion thread:
Actually I'm little concerned about VB's future with the graduating generation of programmers. Most of today's universities are teaching Java as a primary learning tool. And usually the academics view VB as a clumsy language for lazy programmers. Decades ago the most supreme business language was COBOL. Those who had a chance working with it know it is an outstanding language that is dead meat, not because it is not used anymore (70% of World's applications remain bounded by it) but because the new generations learned from their teachers that computer science is science, COBOL is for business and C is for math (math is science). Some may argue that there is COBOL.Net, however, seniors can't stand OO way of thinking, juniors can't stand OLD language stigma so it is also dead before it is born. Having C language culture and nowadays Java transferred from teachers to students, what do you think IT managers will prefer for their departments growing potentials if they choose to acquire .NET?
If I was a manager I would surely choose C# for several reasons:
1) So I can get the brightest of new (low paid) grads up and running in no time.
2) So I can get to that C++ like language fame surrounding my projects and yet get it RAD.
3) So I can leave infamous VB lazy clumsy programmers gossips roam as they wish without feeling their sting.
But I am a developer so I choose C# for:
1- No job is secure, so I'd better get used to curly brackets and once I learn most of XML, web services, SOAP, etc., then I am empowered to switch easily to that other half of corporate world that is using J2EE.
2- It's more stylish and attractive (yes it does matter if you are going to spend most of your day on something then better love it).
3- Because VB's parents Bill and Mic seem to undermarket it in favor of C# (could it be they are trying to abandon the ship?).
From a discussion thread:
We chose VB.NET a year ago and we regret it. We have 25 very bright developers and a substantial ecommerce web site with plenty of traffic. One year ago we kicked off our port to .NET and we chose VB6 because our existing code base was VB6 and ASP. A few of us here had significant C# expertise from previous jobs and warned the bosses that the "advantages" of VB.NET were a mirage and that there were some clear disadvantages. They actually thought the "automatic conversion" tools were going to buy us some time. The pointy-haired contingent won out and not a day goes by that we don't curse them for forcing VB.NET on us.
As other's have said, you take a big hit moving to .NET at all. The tiny additional hit of moving talented VB6 developers to C# is more than offset (IMHO) by the increased developer productivity achieved over the medium to long term in C#. (If your team is not very talented -- or not talented in that way -- YMMV.)
Why do I think I am more productive in C# than in VB.NET? Here are a few reasons:
1. VB.NET has abysmal static code analysis: functions that don't return values, uninitialized variables, unused variable declarations, etc... This is what a compiler is *for*. I wish VB.NET had an "Option ReallyStrict On" so it would check things as thoroughly as the C# compiler does. You can spend hours trying to track down which uninitialized variable or non-returning pathway in a function is the source of a bug, when the compiler could just tell you.
2. VB.NET has more aggressive background compilation that you can't turn off or control in any way and which is buggy! We have solutions for our web site with 30 projects and some projects with hundreds of files. You can't add a method to a class without taking a coffee break while intellisense chews up a CPU. We're reduced to having to buy double cpu machines for developers so that they can just type at full speed. And even then all that CPU is wasted because the background compilation just can't keep up. I wish there were an option for intellisense so that you could *tell* VB.NET when to recompile and when to just chill out because I'm typing a raft of code.
3. VB.NET (still) has lurking intellisense bugs whether you use project dependencies or file dependencies. Whichever you choose, you're stuck with a different set of problems ("can't copy dll X [v1.1.3000.1] over dll X [v1.1.3000.2]" or "dll A requires a reference to dll B" or "can't copy dll Y to c:\foo\bar\y.dll because it is locked")
4. VB.NET has no "using" directive. I know it's just syntactic sugar... but I want more sugar. The truth is that interacting with non-managed resources (ie. the OS or the database) in .NET sucks even in C#. But having to write "Dim x ... Try ... Finally .... x.dispose EndTry" all the time is just pouring salt in the wound.
5. VB.NET has no multiline comment syntax
6. VB.NET has no within-the-line comment syntax
7. VB.NET has no multiline string syntax
8. VB.NET has a limit on line continuations (what is it, like 10 lines)?
9. VB.NET projects cannot have pre-build or post-build steps (large, real-world projects inevitably need them)
10. VB.NET has no built-in comment->documentation generator
And in case anyone is still reading... it's hard to think of any advantage we've seen in using VB.NET. Maybe one: it made some COM coding easier because we could use late binding. I'd say if you are doing lots of COM interop especially if you need late binding, VB.NET is necessary. But I don't recommend doing any more COM interop than you absolutely have to and late binding is worse than evil.
I think that pointy-haired types think that VB.NET will make it "faster". That the learning curve will be less steep or that fewer changes will need to be made to the code. It just doesn't work that way. Your project will take 2 or 3 times as long as you anticipated, even if you pick VB.NET. And when you choose VB.NET you may get started faster but you'll be paying a tax forever, because the language and tools just aren't as good as C#. I'm crossing my fingers for VB improvements in 2005, but I'm not holding my breath. Doubtless something else will be "missed" (like multi-language projects were this time) and we'll still be stuck in a VB.NET ghetto.