C# vs VB ... comparison

I''ll disregaurd your comment about games not being real world stuff.

The underlying DB code is, more than likely, written in C++, so I don''t think you will see much of a speed difference no matter which language you use to call the DB functions with.

There are cases where the MSIL generated for two "identical" functions in VB.NET/C# will be a little different (sorry, I don''t have an example at hand).

In response to the second post, as far as performance is concerned, ADO.NET will provide a substantial increase in performance vs. classic ADO.

Seems to me that most of the differences are in language features, for instance, C# supports operator overlading, VB .NET doesn''t. VB .NET let''s you write procedural code in modules sort of like the way you could do it in VB6, but as far as I know, C# is more like Java in that everything has to be in a class. VB .NET seems to hide more things in the designer generated code than C#. I found VB .NET''s language quirky at first, but I forced myselft to get used to it since I have to write my next big project in it. The other developer where I work doesn''t know C# and he doesn''t want to bother to learn it and since for some damn reason my boss listens to him more than me, I have to use VB, even though I''m better with C#. The funny thing is, the other guy knows VB6 but doesn''t know much about real OOP programming or .NET, so in my mind, it''ll be just as much work for him to learn C# as it would VB .NET. He thinks because the VB .NET syntax looks somewhat like version 6 it''ll be easier, but when I had him look over some of the code I was working on, he asked me what that Sub New() thingy was and when I told him it was VB .NET''s way of making a constructor, he said ''Huh?'' what do you need that for?. I just shook my head.

There are only a few differences right now between VB.NET and C#. I use VB.NET at work, and C# at home...and the noticible differences are:
* VB.NET doesn''t support operator overloading (already mentioned)
* VB.NET does allow for Option strict and Option explicit to be turned off...basically making VB.NET into a scripting language. You''re going to want to keep these on though for actual projects.
* C#''s compiler better, it tells you about variables that aren''t used, disallows use of uninitialized variables, etc.
* C# has the built-in XML documentation
* VB.NET has a background compiler to auto-highlight build errors as you type. For small projects this is awesome, but around 15 projects in a solution with 100,000 lines of code this becomes a blocking issue. The bg compiler will just take up 100% of your CPU just to change 1 line of code. This is one of the main reasons that we''re considering changing languages at the office. This is really an IDE problem, but it really does hinder productivity after a while.
* C# has unsafe code blocks, allowing for pointer access to "locked" memory. The code is still managed, but within unsafe context the Garbage collector will be more "hands off".
* C# has some additional keywords: checked/unchecked, and a few others
* There are more C# components out there than VB. The odds of finding a C# class to do what you need is much higher, which allows for integration within existing projects. You can always build a DLL and reference it (which is what we do most of the time) but it''s just easier to get a .cs file into your source tree than to manage 15 external DLLs.
* The future. C# has an open spec and an active community that''s trying to improve the language. I''ve seen "future design ideas" for C# 2.0 around the internet for a while now, but I haven''t seen anything about VB.NET 2.0. .NET 2.0 will be the biggest deciding factor for me about language (porting 200,000 lines of VB.NET code ain''t a small task, and is certainly not worth it yet). If C# gets generics but VB.NET doesn''t then I think you''ll see a mass migration of VB.NET power users to C# (and I question the "power user" status of anyone who doesn''t thirst for generics in .NET)

But really I currently prefer C# because I prefer the C-based syntax. :-)


Epolevne

C#

It''s getting revised for generics, and (the most important thing for us lazy programmers) it requires less typing:

if(condition)
{
  // blah
}
 

as opposed to

If Condition Then
  ''blah
End If
 

quote:

---

Original post by daerid
It''s getting revised for generics, and (the most important thing for us lazy programmers) it requires less typing:

if(condition)
{
  // blah
}
  

as opposed to

If Condition Then
  ''blah
End If
  

---

While I''m no VB.NET programmer, I have seen enough of these debates to know that the usual reply to this argument is that the IDE takes care of it anyway(autocomplete/autoformat), leading to LESS typing for the VB.NET programmers.

---

"If there is a God, he is a malign thug."
-- Mark Twain

noparity: My point was, that if you use the SAME dbase API, it doesn''t matter which lanuage you call it from, either one will give about the same performance, since your app will only be as fast as the dbase anyways.

Thanks people. Some interesting points were made.

Firstly the DB performance comment. Whilst it is true that many simple apps are limited by the actual underlying DB engine, most larger projects (in my experience) actually spend a surprisingly small amount of time waiting for queries to execute etc - an awful lot of other processing goes on too. This is where a good language comes into play. The idea of efficient (read ''easy'') code reuse is vital to many successful contracts.

I was under the (MS inferred) impression that both VB & C# produced identical MSIL when compiling sufficiently similar code fragments. Is this not the case then?

I hadn''t looked into operator overloading. It''s funny that when using C++ this is an important and useful feature, yet when using VB I never actually think about it! There''s always an alternative coding approach.

The thing that swayed me away from C# to start with was the java-esque design philosophy behind it. Forcing everything to be object based seemed a bit anal in many respects - I remember when the original MFC was being developed, MS made everything an object. After two years they dumped almost all the code base and started again. They realised the error of their ways, as it were, and went back to a model where objects were only used when it seemed appropriate. Having said that, I think I''m inclined to delve into C# first, then switch to VB at a later stage. I know the switch will be childs play, but I am a firm believer in learning a language thoroughly before selling my skills with it. I''ve worked with too many people in the past who clim to be programmer, who couldn''t program a video recorder. Funnily enough, these people normally had CS degrees - no flame intened - where their arrogance was matched only by their incompetence! I digress.

Anyway, thanks again to those that replied.

Regards
Mark