How does VB compare to C# part 2

How does VB compare to C# part 2

• Charl Fourie

  I thought I'd throw my 2 cents in on this never ending vb/c# debate.

  As far as the actual languages are concerned VB.NET and C# are equals. It really just depends on what the programmer likes. If they have BASIC background (like me) they like VB.net. If the programmer has a C++/JAVA background they like C#.

  Now as far as the tools go, I like VB.net better. The background compiler rocks! I really like the 'Error List' box that constantly updates as I code. It makes it easy to find problems in the code. However, I don't think this makes VB.net a better language than C#, I just like the tools in VS IDE for VB.net better. I'm not a fan of the resurrected 'edit and continue' feature in .NET 2.0. When .NET 1.0 (Visual Studio.Net 2002) came out we lost the edit and continue we had in VB6. I really don't miss it, I think it was more trouble than it was worth. Some program situations were caused because we paused the program, changed something, and continued instead of restarting it. Anyway, I think it is a good idea for most programmers to learn to get by in the 'other language' that they don't use. You never know when it will come in handy or when the top-rated book on a paricular programming subject is only available in the 'other language'.

  
  
  

• Rich Cyc

  It's been a bit since I did any coding in C#, so I can't vouch for exactly what the differences are, but I remember there being stuff missing from the windows showing tasks and compilation errors, stuff I was used to seeing updated on-the-fly by the background compiler in VB.NET.

  It would probably take me two minutes to come up with a list if I had C# installed on my machine, but...I don't. Can anyone confirm the differences that the background compiler affects

  - Mitchell S. Honnert

  
  

• Stefanie

   

  No.... but you can have an A-woman!

  " But, what is clear is that there is a lot of strong feeling against VB's syntax that does not exist against C#.  "

  If I went to a KuKluxKlan meeting, I may hear a lot of strong feelings aginst the African American People that I would not hear at an NAACP meeting.

  In the seventies AT&T gave unix and C away to schools for free. That created an ocean of people who are used to C and Unix who wouldn't have been.

  One reputation that the C world has had is that it's for people who don't like to type. If that's true to any extent, it would follow that people who don't like to type wouldn't like VB's sytax.

  I'm not sure what would constitute an answer to your question at this point. There is no technical advantage, it's about what people are used to and that's about it.

  
  
  

• Shaik Abdullah K

  I would say the main reason for there being two choices was to provide a clear path for C++ developers that didn't suffer from the stigma they would feel at any suggestion they move to VB, and a path for people used to VB syntax and looking to move into .NET. Otherwise, there is simply no reason that I can see for the two languages to exist.

  I am definately one who hates the VB syntax, but I really think there is no point in discussing it. I hate it, you like it. Great - what's the benefit in rehashing the fact It doesn't say anything about either of us as developers, so why discuss it It's a relgious choice ultimately, and therefore not subject to reason or logic :-)

  I'm sorry to hear that you've had this experience at conferences. I've also seen conferences where VB centric presenters make sarcastic comments about 'those C++ guys who love curly braces'. In my book, any real developer can convert easily between the two languages, so who cares what the examples are presented in

  It makes a lot of sense for a company to stick to one language. How does it help a company if when they move onto new projects, they need to build teams, not out of the developers who are available, but out of the developers who are available and who work best in the language that the new project uses Split language projects help no-one, as far as I can see. I should be comfortable working on any code in the project I am on, why add risk by making the code dual language

  
  
  

• Selim

  >>It's Religion.

  Can I have an amen :P

  Seriously ( to the original poster ), I don't see what question you have that has not been answered. VB.NET and C# are the same in pretty much every way, excepting syntax. If there's bias out there ( and there plainly is ), that's not a technical question, and there's really no way to resolve that. You may want to reword the question, if you have a question that is of a technical nature.

  
  
  

• Daní

  It's Religion.

  Can I have an amen :P

  I think it has been explained to me very clearly. I thank you for your unbiased, objective, helpful and technically clarifying explanation.

  
  

• geenen

  >> Also, like in a function, it will let you know if something is not returned on all the different code paths.

  This is really necessary because in VB6 especially, people were in the habit of letting the compiler return for them automatically, some Microsoft VB.NET 2003 samples even do this ( the Fotovision sample does it all over the place ). C# has never allowed this, and I don't believe C++ does either, although I know VC6 allowed it ( but that's a poor excuse for a C++ implimentation ).

  >>One thing I like about VB (however this is still a preference thing), is that VB is not case sensitive

  Funny, that is the thing about VB that I most despise.

  >> In fact, could anyone explain to me why you would want variable and procedure names to be case sensitive

  Well, apart from the obvious thing that you can create a private variable called myVar, and a public property called MyVar, you can use coding standards such as private/protected methods start with a lower case, and public start with upper case. Or, local variables start with lower case, member variables start with upper case.

  "MyVar" != "myVar" so why should MyVar == myVar

  I have to admit that I still don't see the value of the background compiler. Yes, I make mistakes, but I make few enough that I am happy to fix them when I compile my code. It's probably just another religion thing, I come from C++, I expect the compile step to be where I get a list of any mistakes that I made. At the end of the day, we all have to fix our errors, who cares if it's as we type, or when we compile

  
  
  

• y0ngb00n

  I have to admit that I still don't see the value of the background compiler. Yes, I make mistakes, but I make few enough that I am happy to fix them when I compile my code. It's probably just another religion thing, I come from C++, I expect the compile step to be where I get a list of any mistakes that I made. At the end of the day, we all have to fix our errors, who cares if it's as we type, or when we compile

  
  
  Yes, there may be the same number of errors, but if you fix them as you go, they'll be easier to find and fix. If you type a bunch of C# code (including three compilation errors) and then compile, because of cascading errors, you may actually have dozens of erroneous lines. Which one of those dozens of errors are the three root causes of all the rest You have to take the time to look through all of the errors and debug the three errors at once.

  But if you type the equivolent VB.NET code (with the three errors), the background compiler is going to tell you exactly when you've made each error and what the cascade effects are. "Oh, man. I didn't realize the function was being referenced in *that* assembly. I better add an overload instead of changing the signature."

  "Well", I can hear people saying, "I'll just compile after every change I make that might cause an error." But that's exactly what the background compiler is doing! Just to an infinite degree.

  I would think that if you did side-by-side tests, you'd find that being aware of errors as you make them makes solving them much easier.

  (I equate the background compiler to the on-the-fly spellchecking and grammar checking in MS Word. If I'm misspelling a word, I want to know about it now so I can make the corrections now.)

  - Mitchell S. Honnert

  
  

• mrb280

  I agree, it is really just what you prefer. Usually if you learn one way you don't like the other.

  Here's an scenario where the background compiler is handy.

  Okay, I've got a solutions that has about 5 or 6 projects in it. The main project is a .dll library with all of my business objects. The GUI project references the dll library and uses the business objects. Let's say for some reason I am forced to make a design change and add or delete a required parameter on a constructor. As soon as I make that change and move off of the line, the background compiler will show all the places in my GUI project where there is now an error because the constructor parameters I'm passing are now incorrect. I don't even have to recompile the dll library. Then once everything has been modified in my GUI project, I can recompile all the projects once and run. Does C# do anything like this for you

  
  
  

• SaruzzU

  >The background compiler rocks!
  JonM, I couldn't agree more. The "VB.NET vs. C#" discussion always seems to devolve into issues of personal preference, but one objective feature that makes a world of difference for me is VB.NET's background compiler. When programming in C#, I can live with the curly braces and all of the other syntax differences, but I've come to depend on the immediate feedback that VB.NET's background compiler gives. Why should I have to compile my project just to see if I've misspelled a variable name I want to know right now if there is a compilation error in my code.

  The preference for on-demand compilation probably goes back to the days of the command-line compilers, but the developers of today should have machines that are beefy enough to handle on-the-fly compilation, so what's the problem What's better, finding out about a problem now or later I'd rather know now.

  - Mitchell S. Honnert

  PS: Cue the C# developer saying "We don't make mistakes, so we don't need a background compiler." 3...2...1...

  
  

• Jakob Røjel

  "lot of strong feeling against VB's syntax that does not exist against C#. Several post indicated that they would not hire a VB programmer unless they programmed in C# syntax."

  And I strongly dislike C Syntax - So what

  It's Religion.

  
  
  

• Ratheesh*MCP*

  >>Why should I have to compile my project just to see if I've misspelled a variable name

  I am very weary of this discussion overall, but this bit has me in utter confusion. If I mistype a variable name in C#, it shows up on the error list, right away. What are you guys talking about Does the VB IDE show the error more prominently somehow

  >> PS: Cue the C# developer saying "We don't make mistakes, so we don't need a background compiler." 3...2...1...

  LOL

  
  
  

• jessie2

  No, it does not. I had to do something like that only yesterday, and I just automatically hit Ctrl-B, I knew I was wanting to be told where my changes broke the code.

  Can you turn off the background compiler For example, if you load a project that is totally broken, can you get it to leave you alone until you finish working through the list it's already provided I've got a fast enough notebook, with a gig of RAM, and I've had the VB compiler open and found it unusable because there were several errors in the code that were non trivial to fix, and the compiler just would not stop.

  I admit, I often have VC6, VS2003 and VS2005 open at once, so I end up using my gig of RAM and going to disc swapping, that's what makes it really slow.

  
  
  

• CongdonJL

  In 2005 the background compiler is better than ever. It will let you know if you are trying to use a variable that hasn't been intialized yet. Also, like in a function, it will let you know if something is not returned on all the different code paths.

  I've got one more. One thing I like about VB (however this is still a preference thing), is that VB is not case sensitive. In fact, could anyone explain to me why you would want variable and procedure names to be case sensitive

  
  
  
• How does VB compare to C# part 2