Has MS given up on us (again)?

[RobinS]

Check out the code gallery. This is where the VB team is putting their
samples now.

http://code.msdn.microsoft.com/

And there's the Visual Basic Developer Center:

http://msdn2.microsoft.com/en-us/vbasic/default.aspx

And the Visual Basic Team blog; this page also has links to the team
members' own blogs over on the right hand side.

http://blogs.msdn.com/vbteam/


RobinS.
GoldMail, Inc.

 

[RobinS]

VB supports operator overloading since VB 2005. BTW, I disagree with you.
To me, using /addition/ and /subtraction/ operators for /adding/ and
/removing/ handlers just seems semantically wrong.

I agree. The first time I saw it, I had no idea what it meant. And how the
heck to you do a search for "+=" ?

RobinS.

 

[RobinS]

Actually, IEditableObject.BeginEdit and BeginEdit are treated as
completely different methods, each being invoked depending on how the
object is being /used/ (i.e. via the object's class or via the Interface).
I find it damnably annoying that C# lacks VB's ability to have a class
method called "Bob" implement an /Interface/ method called "Wendy".


Again, agreed!


I can't remember if Operator Overloading has arrived already or if it's
"coming soon" to Visual Basic. Actually, I quite like +=; AddHandler just
seems so cumbersome.


Haven't tried it with .Net and don't look forward to doing so ...


Until the next release, when each tool catches up with what the other one
had in the release before (but it /is/ nice to be "ahead", just for once).


Regards,
Phill W.

C# will never have the new DLR stuff. It can't be a dynamic language in the
same way.

RobinS.
GoldMail, Inc.

 

[Herfried K. Wagner [MVP]]

I agree. The first time I saw it, I had no idea what it meant. And how the
heck to you do a search for "+=" ?

Well, that's a general problem ASCII art programming languages suffer from.
Overloading in general (including operator overloading) is a great feature,
but it can be easily abused. I have seen an implementation of a relational
data access layer in C# which overloaded several operators C# provides to
allow the programmer to build queries. It was horrible because the
operators had certain semantics which differed completely from their
"general" semantics.

 

[Herfried K. Wagner [MVP]]

C# will never have the new DLR stuff. It can't be a dynamic language in
the same way.

I remember the times people said that C# would never support Edit &
Continue. Well, it has been added to the IDE in the same version it has
been added to VB (sure, E&C is more limited in C#, but it is basically
available). If the DLR features in VB seem appealing enough, I am sure they
will be added to C# sooner or later.

 

[Herfried K. Wagner [MVP]]

What about vice versa? I wonder with no enough experience, is there
anything that a developer can do in C# but can't do the same in VB?

Unsafe code, unchecked blocks, and 'yield return', for example.

 

[kimiraikkonen]

Unsafe code, unchecked blocks, and 'yield return', for example.

Aren't there a way to simulate those missing features in VB? I hope so.

 

[kimiraikkonen]

Unsafe code, unchecked blocks, and 'yield return', for example.

For yield return i found this:
http://weblogs.asp.net/jgaylord/archive/2007/10/17/vb-net-s-quot-yield-return-quot.aspx
http://www.vbdotnetheaven.com/UploadFile/rmcochran/yieldreturn11142006235137PM/yieldreturn.aspx

 

[Alex Clark]

I agree with you on all of those points, and I have to say that I wish MS
would just bite the bullet and merge the two language teams. What we
effectively have today is one language, i.e. ".NET" with a variety of
dialects. C# is one dialect, VB is another, but for the most part they boil
down to the same IL (yes, I know that's not always true).

Instead of C# leaping ahead with one particular new feature for one release,
then VB playing catch up and releasing some exclusive new feature the next,
they should just merge the two in features and functionality and then
distinguish them by syntax alone. It's actually ridiculous to imagine E&C
not being identical for C# and VB.NET, among other things.

It's a shame VB still has the same old stigma attached to it when comparing
skillsets. I've seen as many hideous implementations in C# as I have in VB,
but the difference being the C# code is always that bit harder to maintain
because it isn't as intuitive or easy on the eyes a few months down the line
when the original coder has gone AWOL. It's a shame more managers don't
consider that when hiring C# coders over VB coders...

 

[Herfried K. Wagner [MVP]]

Aren't there a way to simulate those missing features in VB? I hope so.

VB is a Turing-complete programming language. Thus it's guaranteed that
there is a way to simulate the /behavior/ (separated from the
implementation). Every task which can be solved in C# can be solved in VB
too, but sometimes developing the solution is easier in one of the two
programming languages.

 

[Herfried K. Wagner [MVP]]

http://www.vbdotnetheaven.com/UploadFile/rmcochran/yieldreturn11142006235137PM/yieldreturn.aspx

LOL:

| *NOTE*: THIS ARTICLE IS CONVERTED FROM C# TO
| VB.NET USING A CONVERSION TOOL. ORIGINAL ARTICLE
| CAN BE FOUND ON [...].

 

[Cor Ligthert[MVP]]

Hi,

I am glad that we see seldom discussion like this as we see in other
newsgroups.

However, C# and VB for Net have in my idea the same parents, C++ and VB6.

A boy and a girl are never completely the same.

Some find C# more elegant most of us here find VB for Net more powerfull.

For me VB does not need all kind of operations to become a kind of C#.

Cor

 

[Scott M.]

What exactly don't we understand. If there is something we were missing
then we must have been missing it in VB and hence not important to us.

I'm sorry but I just don't believe that in one day an entire company's
development workforce completely learned the C# programming language.

For example (and this is just a short list), you're saying that in one day
you all became proficient with:

-Declaring and instantiating delegates and then manually registering the
listener delegate as an event handler for your controls (None of which has
to be done at all in VB .NET).

-Setting up indexers for your indexable properties.

-Understanding checked and unchecked expressions

-Understaning safe and unsafe code

-Verbaitim string expressions

-Understanding how the VS IDE works differently in C# and how that affects
the way you write your code

Again, I'm not trying to say that switching is any kind of monumental task.
I just think you are either embellishing your company's true experience in
switching or your company doesn't know all they think they do in C# yet.

-Scott

 

[Michael C]

Examples: When defining a class, you use the Implements and Inherits
keywords in VB. In C#, all you get is a colon.

I can understand why you don't like it but this is the beauty of C#.
Something like Dim X as Integer is much clearer and easier to read but if
you're doing this as a full time job it's better to have the shorter syntax.
Same applies to implements and inherits keywords.

For God's sake, don't start any of your base classes with an I or you'll
never know which it's doing.

I'm yet to see a class start with an I so I don't think it's a big deal.

When you do implement an interface like IEditableObject, in VB the method
says "Implements IEditableObject.BeginEdit" and your method doesn't have
to be called BeginEdit. In C#, it is just called BeginEdit, and no sign
anywhere that it implements IEditableObject.BeginEdit. Better remember it,
or comment it for the next guy who comes along.

Actually in C# you have the option of calling it BeginEdit or
IEditableObject.BeginEdit. If you use the former then it is available your
objects interface as well as the IEditableObject. If you use the latter then
you need to cast to IEditableObject to call it. Again this is just the
shorthand style of C#.

+= versus AddHandler. I mean, really.

I'm not sure += is ideal but I really don't like AddHandler at all. It hides
the fact that you're adding something to a list and gives a second way to do
the same thing.

Office Automation. Enough said.

That isn't easy in C#.

Just my opinion. I have no problem with either language; I've now become
ambilanguagedextrous.

You might change your mind after working more with C#. I've got to like the
shorthand style of C# and really don't like all the extra typing in VB.

Michael

 

[Scott M.]

I think that this perception was true prior to .NET (circa 2002), but I
think that anyone who still holds these perceptions is woefully out of the
loop on what's going on in the programming world to day.

 

[Tom Shelton]

I can understand why you don't like it but this is the beauty of C#.
Something like Dim X as Integer is much clearer and easier to read but if
you're doing this as a full time job it's better to have the shorter syntax.
Same applies to implements and inherits keywords.


I'm yet to see a class start with an I so I don't think it's a big deal.


Actually in C# you have the option of calling it BeginEdit or
IEditableObject.BeginEdit. If you use the former then it is available your
objects interface as well as the IEditableObject. If you use the latter then
you need to cast to IEditableObject to call it. Again this is just the
shorthand style of C#.

And you can actually use this to rename the methods (sort of)...

public class SomeClass : IDisposable
{
public void IDisposable.Dispose ()
{
Console.WriteLine ( "Bang! I'm dead!" );
GC.SuppressFinalize ( this );
}

public void Close ()
{
((IDisposable) this).Dispose ();
}
}

If the user has a SomeClass reference, they won't see the Dispose method
at all They will only see close. And they can still use the object
in a using statement...

I'm not sure += is ideal but I really don't like AddHandler at all. It hides
the fact that you're adding something to a list and gives a second way to do
the same thing.

Well, it makes sense if you think in terms of multi-cast delegates. You
are adding to a list, so it is just adding to the original. I like it
(I didn't at first, but once I thought about it then it made sense).

That isn't easy in C#.


You might change your mind after working more with C#. I've got to like the
shorthand style of C# and really don't like all the extra typing in VB.

Agreed. Plus - I love case sensitivity

 

[Herfried K. Wagner [MVP]]

You might change your mind after working more with C#. I've got to like
the shorthand style of C# and really don't like all the extra typing in
VB.

Especially with VB 2008 I don't think there is a significant amount of extra
keystrokes necessary to archieve the same goal as in C# because of keyword
IntelliSense and automatic code generation.

 

[Tom Shelton]

Especially with VB 2008 I don't think there is a significant amount of extra
keystrokes necessary to archieve the same goal as in C# because of keyword
IntelliSense and automatic code generation.

Aaah... Unless you don't code in the IDE

 

[Michael C]

Well, it makes sense if you think in terms of multi-cast delegates. You
are adding to a list, so it is just adding to the original. I like it
(I didn't at first, but once I thought about it then it made sense).

I did think of that and was actually going to write that it's like adding to
a list. But that would only make sense if you could use it to add to lists
throughout C#. AFAIK, this is the only list that you can add to in this way.

Agreed. Plus - I love case sensitivity

I can't say I'm a big fan of case sensitivity. I avoid defining 2 variables
of the same name with different case.

Michael

 

[Michael C]

Especially with VB 2008 I don't think there is a significant amount of
extra keystrokes necessary to archieve the same goal as in C# because of
keyword IntelliSense and automatic code generation.

Possibly, although you still need to read all that extra code and have
longer lines of code.

Michael