Is C# more powerful than VB .NET?

[Carl]

I just heard that C# is more powerful than VB .NET. But I thought it was
at the same level. Please clarify.

[Mattias Sjögren]

Carl,

>I just heard that C# is more powerful than VB .NET. But I thought it was
>at the same level. Please clarify.

It depends on how you define "powerful". There are definitely
differences between the languages. Which one you find most powerful
will likely depend on your background, the what kind of problems
you're trying to solve with the language.


Mattias

===
Mattias Sjögren (VB MVP)
mattias @ mvps.org
http://www.msjogren.net/dotnet/

[C Acheson-Crow]

It is not necessarily more powerful, however it does make the greatest use
of the functionality that .NET makes available. A language can be defined
as a .NET language if it just implements the core functionality in order
to be compiled into MSIL (Microsoft Intermediate Language). There is a whole
range of functionality that a language can implement and C# being specifically
written for .Net makes the most of that. At present VB makes the second greatest
use of the framework.

Given that, there are still things you can do in VB that you can't do in
C# and vice versa

Charlie

Senior Developer
Burges Salmon

Mattias Sjögren <mattias.dont.want.spam@mvps.org> wrote:
>Carl,
>
>>I just heard that C# is more powerful than VB .NET. But I thought it was
>>at the same level. Please clarify.
>
>It depends on how you define "powerful". There are definitely
>differences between the languages. Which one you find most powerful
>will likely depend on your background, the what kind of problems
>you're trying to solve with the language.
>
>
>Mattias
>
>===
>Mattias Sjögren (VB MVP)
>mattias @ mvps.org
>http://www.msjogren.net/dotnet/

[Mattias Sjögren]

Charlie,

>There is a whole
>range of functionality that a language can implement and C# being specifically
>written for .Net makes the most of that. At present VB makes the second greatest
>use of the framework.

Well, that's your opinion, not facts. Not everyone will agree with
you.


Mattias

===
Mattias Sjögren (VB MVP)

[Jonathan Wood]

Burges,

> Given that, there are still things you can do in VB that you can't do in
> C# and vice versa

Can you give an example of something you can do with VB .NET that you cannot
do with C#?

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Patrick Troughton]

The two languages are about 99.99999999999% identical but there are some minor
differences. Here are few (of varying degrees of usefulness)....

- Optional parameters
- Background compilation (more of an IDE issue than a language issue)
- Ability to hookup an event procedure to an event declaratively
- Late binding
- Loose type checking

In addition to optional parameters mentioned above, VB.NET also has a couple
more syntax short cuts that let you write less code...

- With...End With
- Ability to create an object by declaring the type only once

This isn't necessarily a complete list, it's just what I could come up with
off the top of my head. Also, before anyone says anything, let me say I don't
necessarily think that late binding and loose type checking are good things.
Like I said, they're about 99.99999999999% equivalent.

/Pat

>
>Can you give an example of something you can do with VB .NET that you cannot
>do with C#?
>
>--
>Jonathan Wood
>SoftCircuits Programming
>http://www.softcircuits.com
>
>

[barknee@westrew.com]

It depends what you mean by "powerful". The languages themself are not equal.
I have seen cases where the IL is different with the same code from VB.NET
and C# look different. And I am not talking syntax issues.


"Michael \(michka\) Kaplan" <former_mvp@nospam.trigeminal.spamless.com> wrote:
>Don't forget ones that pushed me to C# for my managed needs:
>
>-- unsigned types (C# only)
>-- bit shifting (C# only)
>
>There are also things like code comments that only work in C#. In truth,
I
>think the difference is more than your 99%+ and will be moreso in future
>versions per the public statements that they will follow the customer base
>for each language.
>
>
>--
>MichKa
>
>Michael Kaplan
>Trigeminal Software, Inc. -- http://www.trigeminal.com/
>
>International VB? -- http://www.i18nWithVB.com/
>C++? MSLU -- http://msdn.microsoft.com/msdnmag/issues/01/10/
>
>
>"Patrick Troughton" <Patrick@Troughton.com> wrote in message
>news:3cfa3923$1@10.1.10.29...
>>
>> The two languages are about 99.99999999999% identical but there are some
>minor
>> differences. Here are few (of varying degrees of usefulness)....
>>
>> - Optional parameters
>> - Background compilation (more of an IDE issue than a language issue)
>> - Ability to hookup an event procedure to an event declaratively
>> - Late binding
>> - Loose type checking
>>
>> In addition to optional parameters mentioned above, VB.NET also has a
>couple
>> more syntax short cuts that let you write less code...
>>
>> - With...End With
>> - Ability to create an object by declaring the type only once
>>
>> This isn't necessarily a complete list, it's just what I could come up
>with
>> off the top of my head. Also, before anyone says anything, let me say
I
>don't
>> necessarily think that late binding and loose type checking are good
>things.
>> Like I said, they're about 99.99999999999% equivalent.
>>
>> /Pat
>>
>> >
>> >Can you give an example of something you can do with VB .NET that you
>cannot
>> >do with C#?
>> >
>> >--
>> >Jonathan Wood
>> >SoftCircuits Programming
>> >http://www.softcircuits.com
>> >
>> >
>>
>
>

[Duane Douglas]

"Carl" <lostinw@hotmail.com> wrote:
>
>I just heard that C# is more powerful than VB .NET. But I thought it was
>at the same level. Please clarify.

vb.net doesn't support unsafe code or operator overloading.

[Michael]

"Duane Douglas" <ddouglas@mindspring.com> wrote:
>
>"Carl" <lostinw@hotmail.com> wrote:
>>
>>I just heard that C# is more powerful than VB .NET. But I thought it was
>>at the same level. Please clarify.
>
>vb.net doesn't support unsafe code or operator overloading.
>
Actually --- you can do operator overloading in VB.NET. It is a requirement
if you are doing custom error objects.

Also -- while VB allows you to build a method with the OPTIONAL parameter,
overloading is the better way to implement that. It also avoids the eventualy
spaghetti code when optional is used.

As for unsafe code......I'm not sure I would want to use that feature of
C#. Seems it would be safer (pun intended) to rewrite the unsafe code.

[James]

Overloading has much less overhead
--
James
"Patrick Troughton" <Patrick@Troughton.com> wrote in message
news:3d077dc5$1@10.1.10.29...
>
> "Michael" <theRealCondor@yahoo.com> wrote:
> >
> >Actually --- you can do operator overloading in VB.NET.
>
> How?
>
> >Also -- while VB allows you to build a method with the OPTIONAL
parameter,
> >overloading is the better way to implement that. It also avoids the
eventualy
> >spaghetti code when optional is used.
>
> That's an odd statement. I find that optional parameters improve code
clarity.
> How exactly are you using them that leads you to write spaghetti code?
>
> /Pat

[Patrick Steele [MVP]]

In article <3d077dc5$1@10.1.10.29> (from Patrick Troughton
<Patrick@Troughton.com>),
> >Also -- while VB allows you to build a method with the OPTIONAL parameter,
> >overloading is the better way to implement that. It also avoids the eventualy
> >spaghetti code when optional is used.
>
> That's an odd statement. I find that optional parameters improve code clarity.
> How exactly are you using them that leads you to write spaghetti code?

Don't know about spaghetti code (you can find that jusy about anywhere!
-- but optional parameters can lead to versioning problems. See:

http://discuss.develop.com/archives/...=DOTNET&P=9945

--
Patrick Steele
Microsoft .NET MVP

[Patrick Troughton]

"Michael" <theRealCondor@yahoo.com> wrote:
>
>Actually --- you can do operator overloading in VB.NET.

How?

>Also -- while VB allows you to build a method with the OPTIONAL parameter,
>overloading is the better way to implement that. It also avoids the eventualy
>spaghetti code when optional is used.

That's an odd statement. I find that optional parameters improve code clarity.
How exactly are you using them that leads you to write spaghetti code?

/Pat

[Michael]

"Patrick Troughton" <Patrick@Troughton.com> wrote:
>
>"Michael" <theRealCondor@yahoo.com> wrote:
>>
>>Actually --- you can do operator overloading in VB.NET.
>
>How?
note: syntax may not be totally correct since this is from memory...
public class MyApplicationException implements System.ApplicationException
public sub new()
mybase.new()
end sub
public sub new(Message as string)
mybase.new(Message)
end sub
public sub new(Message as string, EmbeddedError as System.Exception)
mybase.new(Message, EmbeddedError)
end sub

public class MyClass
dim Delimiter as Char = '*'
Public Sub New()
end sub
Public Sub New(DelimiterOverride as Char)
Delimiter = DelimiterOverride
end sub

public class MyClassMethod

[Patrick Steele [MVP]]

In article <3d079cd3$1@10.1.10.29> (from Michael
<theRealCondor@yahoo.com>),
>
> "Patrick Troughton" <Patrick@Troughton.com> wrote:
> >
> >"Michael" <theRealCondor@yahoo.com> wrote:
> >>
> >>Actually --- you can do operator overloading in VB.NET.
> >
> >How?
> note: syntax may not be totally correct since this is from memory...
> <snip!>

You're showing overloading of methods. Operator overloading allows you
to redefine how the operators (+, -, /, etc...) will act upon your
class. In other words, you can take a custom class of yours, say
MyPoint and define a custom addition operation (via operator
overloading) and do this:

MyPoint p1 = new MyPoint();
MyPoint p2 = new MyPoint();
....

MyPoint newpoint = p1 + p2;

--
Patrick Steele
Microsoft .NET MVP

[Patrick Troughton]

Patrick Steele [MVP] <patrick@mvps.org> wrote:
>
>Don't know about spaghetti code (you can find that jusy about anywhere!

> -- but optional parameters can lead to versioning problems. See:
>
>http://discuss.develop.com/archives/...=DOTNET&P=9945

Two points....

First, *anytime* you change the interface you risk versioning problems. You
can just as easily introduce versioning issues changing the signature of
an overloaded method as you can with optional parameters. In fact, the problem
is potentially worse with overloaded methods than it is with optional parameters
as we'll see in my next point....

With all due respect to Anders Hejlsberg, the example he gives does *not*
present a versioning issue. In fact, it's exactly the opposite. Because the
default value is compiled into the calling object, if the author of the callee
object changes the default value of the optional parameter, it does not break
the calling code. All client code will continue to run as originally intended.
The issue doesn't really surface until *after* the client has been recompiled,
and that's only if the author of the callee fails to notify those affected
by the change. But that just leads us back to my first point...anytime you
change the interface you risk versioning problems.

/Pat