Can anyone help me understand some of the pros (and some of the cons if they are constructive) of using VB.NET over say, C#?
-
Syntax can be a bit more concise, but harder to follow.
Really, for most of us, there's not a whole lot of difference...
From Brian Knoblauch -
Pros:
- there are a lot of VB.NET developers on the planet
- VB.NET developers tend to charge less than C# developers
Cons:
- VB.NET syntax is verbose
- VB.NET cannot do unsafe (i.e. pointer-based) operations, which are rarely necessary but do occur in special circumstances
since they both rely on the .NET framework, they're theoretically equivalent; otherwise, it's really a matter of comfort and style after that
in general, people from a VB background tend to prefer VB.NET, people from a C++/Java background tend to prefer C#
personally, i find VB.NET syntax to be overly complicated, and much prefer C#
BTW, it doesn't hurt to be fluent in both
Scott Alan Miller : Those are pros if you are a development manager, cons if you are the developer (lots of competition, less pay.) As this is a developer forum I think that that is the perspective.Steven A. Lowe : since i prefer C#, i like to encourage the competition to learn vb.net ;-) [just kidding!]From Steven A. Lowe -
COM interop is much better in VB.NET (compared to C#), partly because VB.NET supports optional named parameters.
http://www.publicvoid.dk/NamedParametersInVBNET.aspx
The most obvious place you run into this is in Office automation.
Jeff : Question requested information about the comparison of the two languages, not suggestions for different languages. Suggesting 'superior' tools is fine...but you should still answer the question.Lou Franco : COM interop is much better in VB.NET -- not suggesting another languageSteven A. Lowe : read the link, this is a vb.net only feature and thus a proLou Franco : edited to clarifyJeff : Ok, now that it's clarified, I'm understanding the response much better.AlexCuse : They're supposed to be adding this to the next version of C#. Yay!From Lou Franco -
XML Literal
http://blogs.msdn.com/wriju/archive/2008/02/07/vb-net-9-0-xml-literal.aspx
From Lou Franco -
There is a pretty comprehensive Codeproject article covering the technical differences.
From John Sibly -
There's no real disadvantage or advantage in either, though there's a few minor feature differences.
They both compile down to the CLR, though, and can easily be translated between.
The only major difference is an advantage for C#: C# developers make more money.
Evidence (and further discussion) can be found here.
From Jeff -
Here are a couple of web posts that are pretty comprehensive, and come at VB.Net from a C# perspective:
Even as a VB.Net developer (as I am) there's some very interesting stuff in there!
From Andrew -
Having worked in both languages I can tell you this:
VB.NET:
- The lack of anonymous delegates is annoying at best.
- The event handling syntax is kick arse.
- The lack of unsafe has been somewhat of a hitch
- Attribute syntax is annoying
- Using the Excel Interop is painless
- Casting tends to be tedious
C#:
- The event syntax for me is annoying.
- Anonymous delegates are a life saver.
- Attribute syntax cleaner then VB
- The LINQ syntax is cleaner
- Better addins to VS available.
- R#: more addins available
- R#: more features available
- ==
- The Excel Interop is PAINFUL
- Casting is easier
Lastly, even in the my language is better then your language argument, there are zealots on both sides. I find that for UI, I program better in VB then I do in C# most of the time. If doing back end, or complex UI, or unit testing VB tends to slow me down where if I do it in C#, it takes less time.
MagicKat : Thanks Rob for the spelling edit!dr. evil : Event syntax in C# is a total WTF! to me :)AMissico : Attribute syntax is the same. What Differences?AMissico : I find that C# tends to slow me down.From MagicKat -
- VB.Net support static members inside functions, C# does not (I ran into this just today)
- I don't know the name of the feature, but when you import a namespace in VB.Net the namespace is "in scope". It can really come in handy. For example, if I'm going to use exactly one regex in an app in C# I'd either have to add a using statement for
System.Text.RegularExpressionsthat's only going to be used by one class instance or type outSystem.Text.RegularExpressions.RegEXin the variable declaration (and I might even need to do it twice for one declaration). Now let's say I also have a StringBuilder or two and have already imported System.Text. In C#, nothing changes. In VB.Net I have the additional option of just sayingRegularExpressions.RegExin the declaration. Also, you get a very nice intellisense prompt after entering the period in VB.
I think VB.Net takes a lot of flak from C/C++/C# developers who (rightly) remember the travesty that was VB6/VBScript, and the effect is amplifed via group-think. We need to put it to rest: VB.Net is not VB6.
I wonder how many C# programmers spend any significant amount of time with VB.Net code? I mean, more than say one week of solid production work? I'm sure there are a few who came in initially from the Classic ASP world, but all in all not that many. I came originally from a C++ backgound, I have spent significant time with both VB.Net and C#, and I can tell you that after a while the VB.Net syntax really has a lot to recommend it over the curly-braced languages.
You probably also want to see this question:
http://stackoverflow.com/questions/102084/hidden-features-of-vbnetFrom Joel Coehoorn -
This is very similar to a question I asked and got negative votes for...
As far as I can tell, more people use VB.NET Its closer to VB6 syntax wise Some people look down on VB developers but I like it as much as C#!
From WACM161 -
I haven't done much VB.NET programming but I saw a difference in how to handle LINQ to XML in VB.NET, where you can use an interesting syntax to refer to XML elements. An example is shown here: LINQ to XML in VB.NET and Using the Right Language for the Job
Secondly I have heard that multi-line lambdas are not possible in VB.NET in the current version. Further pointers here: No multi-line lambdas in VB 2008
From flq
0 comments:
Post a Comment