You can read this article about the "culture"
http://www.codeproject.com/dotnet/CSharpVersusVB.asp
I think the java thing as been mentioned. Take for instance a college like
North Carolina State University.
CSC (Computer Science) students code in java for most classes.
If a student wants to jump into the Microsoft world, they're going for C#,
and never Vb.Net.
My experience is that a developer who starts in c#, seldom moves to VB.NET.
A developer who starts in vb.net, and goes to c#, doesn't look back.
Those are my observations. They're not a macroview, just what I've seen.
Now, from someone who has coded in both. Here is my list:
Here is my concrete list of differences. When someone says "There are not
differences", you need to ask if they've actually coded in both for an
extended time.
Here is my list. My company was solely a VB.Net shop, and this is the list
used to show some differences.
Here is as concrete as I could get, with no commentary.
This way my best attempt. If there are workarounds, please politely list
them.
I'm not trying to start an old and dead horse war, just listing what
concrete items I have found.
*** This is a 1.1 list ***. Some may or may not apply in 2.0.
VB.NET has no "using" directive.
VB.NET does not do automatic namespacing. Whenever you put in a new folder
and/or class, C# puts in "namespace MyCompany.Technology.Args" for you.
In VB.NET you have to ~remember to put in "namespace
MyCompany.Technology.SomethingElse". Or everything defaults to the default
namespace.
VB.NET does not provide pre-build or post-build steps.
(there is a work around available for this , one is build rules ex
http://www.gotdotnet.com/Community/...mpleGuid=a3326eb3-a468-4f67-91a8-f84469fc49e2
)
VB.NET has no built-in comment->documentation generator
(see previous forum post about GhostDoc)
(there is a work around available for the default c# functionality, but
there is no equivalent GhostDoc feature)
See demo at
http://channel9.msdn.com/Showpost.aspx?postid=121822
VB.NET regions are not as flexible as c# regions.
The key here is that you can place a region ~~inside a function (in C#),
thus breaking up the implementation into logical pieces.
VB.NET does not allow the application the <NonSerialized> attribute to
events (you can in C# by using the Field: modifier).
As a result, there is no simple way of telling the runtime not to serialize
the event fields.
This results in serializing objects that you didn't expect, resulting in a
larger stream.
If the object handling the events is not Serializable, then the
serialization process will throw an exception.
( See
http://www.codeproject.com/vb/net/serializevbclasses.asp for more info
and workaround )
VB.NET has less features with its static code analysis (as in, when you go
to Build / Build Solution).
Issues like : functions that don't return values, uninitialized variables,
unused variable declarations, etc...
Development time (in c#) is slightly decreased by finding these issues at
compile time.
VB.NET does not have ... Increments/Decrements. a++;a--;
VB.NET does not have operator overloading. C# has Operator Overloading.
(see
http://www.csharphelp.com/archives/archive135.html)
VB.NET has no multiline comment syntax
VB.NET has no within-the-line comment syntax
VB.NET has no multiline string syntax
VB.NET has a limit on line continuations (I think the limit is 10?)