C# is better than VB

[Scott Penner]

I'm sure there's a bunch of people that look at that title and think this is a thread with another religious argument.

Far from it. This is facts. This goes beyond the tired arguments about syntax preference and with statements.

I realize this is probably old news to most of you:
Future features of C# (http://www.gotdotnet.com/team/csharp/learn/Future/default.aspx)

New features being added to C# were discussed by C#'s creator at OOPSLA in November. From talking to some guys on the design team, these features are just the beginning to changes / additions being made to C#. Note! These valuable new features are not going to be in VB. And, in the future, C# will become more and more of the workhorse - a language that the more serious programmers will use. VB will get new features more geared towards rapid development.

This isn't a flame starter...It's just an FYI.

[Hu Flung Dung]

I don't quite understand how their going to do this!

To add this functionality to C# means to add it to the .NET framework. If its added to the framework, VB.NET can take advantage of it. Unless their going to make C# a .NET-independant language? But if thats the case, why wouldn't people just use C++ instead?

[Scott Penner]

As you know, there is a variety of things in the framework that are not used in one language or another. For instance, C# can user pointers, while VB cannot. Also, VB can use optional parameters, while C# cannot. These are design decisions made by the language architects, not a restriction in the framework.

Gererics will be added to the framework. You can see that the nature of the annoucement was to get feedback before seeking ECMA approval on the additions. However, the VB design team will not implement generics in VB.

It's a philosophical decision from the different design teams. C# will gain more power at the cost of more complexity. VB will gain more RAD capabilities at the cost of power. The underlying framework will of course be the same...

[Hu Flung Dung]

I always thought that optional parameters turned one procedure into two or more overloaded procedures, therefore its not really an added functionality.

As for pointers, VB.NET does support them, but in a round-about way (passing variables ByRef, for example). I think C-style pointers were left out intentionally because their only beneficial in very specific circumstances, and they can cause many problems that can be very difficult to debug (memory leaks, for example).

Correct me if I'm wrong though, I'm only speculating here!

EDIT:

Here's something I saw on the MSDN documentation just now


A managed pointer, also known as a __gc pointer, is a new type of pointer available to managed applications. Managed pointers are references to a managed block of memory from the common language runtime heap. Automatic garbage collection is performed on this heap. Managed pointers are generated for method arguments that are passed by reference. Some languages provide other ways of generating managed pointers. Only managed pointers are CLS-compliant.

An unmanaged pointer is the traditional C++ pointer to an unmanaged block of memory from the standard C++ heap. Because unmanaged pointers are not part of the Common Language Specification (CLS), your language might not provide syntax to define or access these types. See the documentation for your language for information on support for unmanaged pointers.

[Lethal]

Don't forget vb.net doesn't support operator overloading..

[Hu Flung Dung]

Originally posted by Lethal
Don't forget vb.net doesn't support operator overloading..

And the benefit of operator overloading is...?

[DevGrp]

I agree. C# is better than VB.NET :p

[hellswraith]

Originally posted by Hu Flung Dung
And the benefit of operator overloading is...?

Well, you can control how operators are used when you create custom objects. When you add two int's, you use the + sign and the two int's are added together like you would think.

Now, imagine you have your own custom objects. These are cow objects. Now, lets say that these cow objects can hold how much milk each cow object has. Since this is the main purpose of the cow object (to hold the milk value), you may want to make it easier to add each of the cows milk values. But if you put cow+cow, you don't get what you would expect. That is, unless you overload the + operator. You can overload the + operator, and have it automatically add each cow's milk value without having to explicitly add the properties. Of course, you can go MUCH more in depth with it though.

This is overly simplified of course, but in programming, it is invaluable if you want to seriously develop objects and make it easier on yourself later or other developers. Just think about it, the int, string, and other classes all overload the operators to make them do what we like. Could you imagine having to type int.Value + int.Value just to add two integers!

[Scott Penner]

Anyway, my point was that just because a functionality is in the framework does not mean each language supports it.

This being said, it will happen that VB and C# begin to diverge. They are identical in many ways now. This will be less and less the case in the future. C# will have more power and VB will have more RAD stuff.

[Hu Flung Dung]

Ayecharumba, No Pimentos!!!!

Their killing the entire purpose for even having a framework!

[PT Exorcist]

correct me if i'm wrong but much of the functionality that they want to add will be things that will make no change in run time..like templates..templates if i am not wrong are just "overloaded" functions/classes that the compiler turns to each data type in compile time

[CornedBee]

No, not overloaded. Templates are what the word says: templates.
You stuff in data types and maybe constants and the compiler generates real code. Hey, you could do quite similar things in an advanced preprocessor, but it's more comfortable to have it directly in the compiler.