Visual Basic vs. C Sharp

Hi Guys,
I've been thinking of doing my next project in C Sharp. When I loaded it up the interface for C Sharp looked just like Visual Basic. The only difference was the syntax was different. So I was wondering is there any benefits for using C Sharp over Visual Basic. What types of programs would benefit from being written in Visual Basic or C Sharp?

I'm not trying to start a language war. I'm just wondering if there is anything to gain from writing in either language.

There are only a very small set of features in C# that are not available in VB, and the same is true for VB's feature set compared to C#.

VB has things like XML literals, and C# has things like unsafe code and iterators.

There are a few others, and I am sure there are detailed comparisons of the differences if you search the web.

One thing that has changed at Microsoft somewhat recently, is that the dev teams have been realigned to co-evolve both these top languages that MS has, so that features will be added in parity, instead of this feature being given to C# and that feature being given to VB. VS2010 is a good example of this, as many new features to C# are things VB had for a long time, and VB is getting some features C# has had for a while now. Yet still, some new features are being added to the languages at the same time for this next release.

There is a little bit of reality here though, which is that:

Of the 2, C# is the dominant language within Microsoft itself. C# was used to create much of the VS IDE. Most examples you will find will either be in C# only, or C# and VB. Especially from Microsoft. You don't find too many examples that are VB only these days. VB has been around a long time, and before .NET it was lacking many features of a true OO language. Because of this, VB was long labeled a toy language not for professional use, which is totally false, but this is how lots of people (who don't use VB) look at it. So even though VB and C# are pretty much the same in capabilities now, lots of C style coders still stick their nose up at VB.

Other than that, there is no harm in learning C# syntax. If anything it will just make you better at learning multiple languages and being able to go back and forth. It will also help you to be able to look at a block of C# code, and type it out in VB, or vice versa.

Moved to General Developer

The two groups were separate within MS, which lead to a divergence between the two languages. This divergence is being corrected, and the languages are coming back together, in my understanding. I think it is easier to use events in VB, and unmanaged code via pointers in C#, but the two are virtually interchangeable.

"I'm not trying to start a language war." -- too, late... it's been started... just kidding... it's just that question will bring out the advocates of both camps.

"I'm just wondering if there is anything to gain from writing in either language." - virtually none.... there are a few things that C# can do, that can't be done in VB, but then VB has a few things that C# doesn't. since both are built on .NET framework.... they are virtually identical. It comes down to which language you are more comfortable with. VB tends to be considerable more verbose in its construct, but if curly brackets and semi colons confuse you, C# will seem cryptic.

what I've seen over the last few releases, and even with the up comming one from VS2010, VB will add a feature, the C# team goes "Oooh, that's cool" and adds it to the next version.... along with other things. The VB Team then sees that new feature and goes "Oooh, that's cool" .... and adds it to their next release.... and so the cycle continues...

One of the biggest things that C# can do that VB can't (yet) is to run inline unmanaged code... that is code that runs in it's own space and isn't part of the managed framework - like ASM or even unmanaged C/C++ code.... if you've got a graphics package that is doing a lot of calculations, this is a good thing.... IF you know what you are doing. If it's not something you need... then never mind it.

-tg

Quote:

---

Originally Posted by techgnome

One of the biggest things that C# can do that VB can't (yet) is to run inline unmanaged code... that is code that runs in it's own space and isn't part of the managed framework - like ASM or even unmanaged C/C++ code.... if you've got a graphics package that is doing a lot of calculations, this is a good thing.... IF you know what you are doing. If it's not something you need... then never mind it.

-tg

---

Just to expand on this a bit, there is also nothing stopping you from doing something like writing a DLL in C# that does some stuff that only C# can do, and reference this DLL from a VB application and use the C# function inside it from your VB code. It could even be F# or any other .NET language..

So solutions can be made up of combinations of C# and VB and any other .NET language.

Projects need to be a specific language, but solutions are just groups of projects.

I did notice one thing that was nice about C sharp that isn't so nice in visual basic. That is the multiple line comments. Visual Basic does have these and sometimes it gets in the way.

yeah... that's a bit of a bunger isn't it... I wish VB had better support for multi line commenting. What I do in that case is jsut write out the comments over the multi lines, then highlight the block and use Ctrl+K,Ctrl+C to comment the whole block.

-tg

Learn both; program in the one you are comfortable with.

Personally, I find the prolific use of curly braces and semi-colons detrimental to my eyes, so program in VB. If I have a need for features that C# offers which are not available in VB, then it's a simple matter of creating a C# DLL, for example. I've not come across any case where VB simply cannot do something that C# can, however.

I'm not sure that the 'comments' difference is a basis to choose a language, but for the lack of anything substantial, I suppose it's as good a reason as any :)

I've also noticed, while no fault of the language itself, that the Visual Studio development environment seems to behave nicer when working with VB.NET as opposed to C#. It just seems to behave "smarter" when working with VB.NET.

I find the VB.Net IDE to be much more intuitive than c#.

Here's an example, creating a sub to handle an event in the code behind window, I don't understand why c# couldn't have the objects on the form (win or web, doesn't matter) in one dropdown and when you select the control the other drop down has the events in which you select the event and if it doesn't already exist, then the IDE creates the code block (and adds the AddHandler call) automatically.

Granted it's just generating an empty sub, but I never need MSDN open to lookup event parameters when programming in vb.net, I always have it open when working in c#.

And what's with c#'s switch statement being so limited compared to vb.net's Select Case statement anyways?

I just spotted this in Tom Sawyer's sig: "(VB/C#) is clearly superior to (C#/VB) because it (has/doesn't have) <insert trivial difference here>."

Anyways, one of VB's idiosyncrasies is going away in the next version - the line continuation character. More appropriately it is going to be optional. No longer will we need to do this:

Code:

---

Private sub SomeErrorHandler( sender as Object, _
    e As SystemEventArgs)

---

We'll be able to do this:

Code:

---

Private sub SomeErrorHandler( sender as Object,
    e As SystemEventArgs)

---

And (gawd forbid) this:

Code:

---

Dim myWoefullyLongSQL As String = "Select some_really_Trivial_Item " &
    "From some_Other_Trivial_Table T" &
    "INNER JOIN Another_Trivial_Table T1 ON T.SomeField = T2.YAF"

---

When I asked about it, I was told they hit what they believe to be 95&#37; of the cases... in other words, if it's obvious there's something on the next line (because you ended the last one with a comma, or an ampersand or something else).... then it'll pick it up.... what won't fly is this:

Code:

---

Private sub SomeErrorHandler( sender as Object
    , e As SystemEventArgs)

Dim myWoefullyLongSQL As String = "Select some_really_Trivial_Item "
    & "From some_Other_Trivial_Table T"
    & "INNER JOIN Another_Trivial_Table T1 ON T.SomeField = T2.YAF"

---

-tg

Still true today: http://www.vbforums.com/showthread.php?t=539686

You should know both if you can manage it. Simply because it is very frustrating to not be able to read examples written in one or the other. Also the more you learn the .NET framework and its classes etc the more trivial the differences become!

If you code in C# with others you are one day going to see this on your screen:

Code:

---

                }
              }
            }
          }
        }
      }
    }
  }
}

---

The biggest flock of seagulls I have seen so far was 10. Any better?

No better but they do end up EVERYWHERE! take a look!

CSharp Code:

private void PopulateList(String SourceType, String OutputType)
        {
            //Populate The ListOfSubRules Property using LINQ to XML
            var XMLSubRules = from XMLSubRule 
                              in XDocument.Load("DataStore.xml").Descendants("SubRule")
                              where (XMLSubRule.Attribute("SourceType").Value == SourceType && XMLSubRule.Attribute("OutputType").Value == OutputType)
                              select new
                              {
                                  Expression = XMLSubRule.Element("Expression").Value,
                                  IsMatchExpression = XMLSubRule.Element("IsMatchExpression").Value,
                                  OpeningElement = XMLSubRule.Element("OpeningElement").Value,
                                  ClosingElement = XMLSubRule.Element("ClosingElement").Value
                              };
 
            foreach (var XMLSubRule in XMLSubRules)
            {
                ListOfSubRules.Add(new SubRule(XMLSubRule.Expression,
                                               XMLSubRule.IsMatchExpression,
                                               XMLSubRule.OpeningElement,
                                               XMLSubRule.ClosingElement));
            }
 
 
 
        }
 
        private void GetCommentCode(String SourceType, String OutputType)
        {
            var CommentFromXML = from XMLComment
                                 in XDocument.Load("DataStore.xml").Descendants("Comments")
                                 where (XMLComment.Attribute("SourceType").Value == SourceType && XMLComment.Attribute("OutputType").Value == OutputType)
                                 select new
                                 {
                                     Expression = XMLComment.Element("Expression").Value,
                                     OpeningElement = XMLComment.Element("OpeningElement").Value,
                                     ClosingElement = XMLComment.Element("ClosingElement").Value
                                 };
        }
 
 
        private void CreateMasterExpression()
        {
            String RawMasterExpressionString = String.Empty;
            foreach (SubRule SubRuleItem in ListOfSubRules)
            {
                const string AndOrSymbol = "|";
                RawMasterExpressionString = RawMasterExpressionString + AndOrSymbol + SubRuleItem.Expression;
            }
 
            // Removes the first OR from the string otherwise it will error. 
            MasterExpression = RawMasterExpressionString.Remove(0,1);
        }
    }
}

I have always noticed that the code editor for C# is not as good as the one for VB... The VB editor handles smart formatting better (I think that's what it is).. For example, if you have the following code in C#:

Code:

---

        private void Form1_Load(object sender, EventArgs e)
        {
            if (3 == 2)
            {
                MessageBox.Show("Huh?");
                MessageBox.Show("That doesn't make sense...");
            }
        }

---

And you then try to delete the second Messagebox call, ending up with a blank line:

Code:

---

        private void Form1_Load(object sender, EventArgs e)
        {
            if (3 == 2)
            {
                MessageBox.Show("Huh?");
               
            }
        }

---

Finally, you want to delete the blank line, and voila:

Code:

---

        private void Form1_Load(object sender, EventArgs e)
        {
            if (3 == 2)
            {
                MessageBox.Show("Huh?");
                            }
        }

---

The brace isn't formatted correctly.


Try the same thing in VB and it does format it!
Just a stupid example, I know, but I have found it can get very annoying at times...

Does anyone know if the equals operator is going to be overloaded in c# like it is in vb?

What I mean is in c# will be be able to do this:

Code:

---

if (SomeVar = SomeValue)

---

Instead of:

Code:

---

if (SomeVar == SomeValue)

---

I heard a joke once: What's the difference between C# and VB?
A: About 8 grand a year

OK, so it's not particularly funny but it does highlight a point. The differences being highlighted in this thread are pretty trivial and mostly revolve around the usability of the editor and readability of the syntax rather than the features which are available. Post the same question on a C# forum and I'm willing to bet you'd get devs saying that C# is more readable and the IDE is superior - it's just what we're used to.

Klienma hit on what is the major difference as I see it. VB.Net tended to get adopted by old VB6 devs while C# tended to get adopted by old C/C++ and Java devs. That means that the work available in the two languages has a tendancy to be different too. E.g. Enterprise apps tend to be developed in C# while small business apps tend to be in VB. As a consequence C# tends to be better paid.

Note the use of the word 'Tends' though. We're nearly a decade down on now and the line's increasingly blurred. I will say, though, if my recent job hunt (about 6 months ago) was anything to go by, it's still there. If you're asking because you want to pursue a career in one or the other I'd say this is a far more important consideration than whether or not you're irritated by curly brackets.

Quote:

---

Originally Posted by JuggaloBrotha

Does anyone know if the equals operator is going to be overloaded in c# like it is in vb?

What I mean is in c# will be be able to do this:

Code:

---

if (SomeVar = SomeValue)

---

Instead of:

Code:

---

if (SomeVar == SomeValue)

---

---

No.... the first one is an assignment operator.... the second is a comparison operator. Since C# is loosely based on C, I don't expect that to change ever.

-tg

Quote:

---

Originally Posted by techgnome

No.... the first one is an assignment operator.... the second is a comparison operator. Since C# is loosely based on C, I don't expect that to change ever.

-tg

---

I figure as much, but it never hurts to ask.

Quote:

---

Originally Posted by JuggaloBrotha

Does anyone know if the equals operator is going to be overloaded in c# like it is in vb?

What I mean is in c# will be be able to do this:

Code:

---

if (SomeVar = SomeValue)

---

Instead of:

Code:

---

if (SomeVar == SomeValue)

---

---

This is (for me, anyway) one of the big problems when switching between C# and VB. I've spent many an hour trying to figure out why a piece of simple code isn't working to find out that an assignment is being made instead of a comparison....urk...

Get squiggles and coderush express and all those errors will be known to you at compile time.

Quote:

---

Originally Posted by techgnome

No.... the first one is an assignment operator.... the second is a comparison operator. Since C# is loosely based on C, I don't expect that to change ever.

-tg

---

Yeah ... the function of those two is so fundamental to the language (any C-type language) that to change it would cause major problems.

-Max

Quote:

---

Originally Posted by DeanMc

Get squiggles and coderush express and all those errors will be known to you at compile time.

---

What errors?

I'm not saying they should overload the equals operator and drop the comparison operator altogether, just make it so you could use either methods for comparison, IE:

Code:

---

if (SomeVar = SomeValue)

---

and

Code:

---

if (SomeVar == SomeValue)

---

both do the same thing

As for the compile errors showing at design time, I really like how they gave c# a partial background compiler in VS 2008, it could be better but it's still better having the partial one.

The problem is that they were orinally separated out for a reson. It allowed C coders, who tend to be a bit anal about typing as few characters as possible:rolleyes:, to do things like this:-

Code:

---

If (x=1==y)

---

That will set the value of x to 1 and then return true if y is 1. Code like that already exists and is out there in use. If you make them interchangable you'll break existing code.

Cool discussion.