Re: Back to VB6 and .NET

On 2008-02-05, Robert Conley <robertsconley@xxxxxxxxx> wrote:
On Feb 5, 9:56 am, Tom Shelton
<tom_shel...@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
On 2008-02-05, Robert Conley <robertscon...@xxxxxxxxx> wrote:
Friend Assemblies - had that since 2.0

I'm not knocking VB.NET - but the only reason it has more "new" features
in the release is that they are bringing it in to parity with C#.

Right but are any of those feature cause an order of magnitude
improvement in the productivity of a C# programmer over VB.NET. Or
they represent a missing capability that VB.NET didn't have. I.e. can
a C# program do more than a VB.NET program in the .NET world.


No, but Cor claimed that VB.NET had "more new features" - which is true.
But, most of the new features were features that C# already had.

One reason that C# got anonymous types was the fact that it lacked the
AddHandler and the Handle syntax of VB.NET. VB.NET handled delegates
better than C# at first, and C# leapfrogged VB.NET, then they both
were brought up to the same level.


I'm not even sure how to respond to this... AddHandler is the
equivalent of C# += operator with delegates. C# has always had that,
and still does. C# also has from the begining let you override the add
and remove funtionality of events - that was added to VB.NET in 2005.
C# also had better IDE support for event at the begining (the lightning
button).

The only thing that VB.NET had that C# didn't was the Handles syntax,
which IMHO, sucks. It reduces flexability and is just down right ugly -
esspecially when you want to use the same method to handle mutliple
evetns...

sub mysub(byval sender as object, byval e as eventargs) handles
button1.click, button2.click, button3.click

Yuck!

button1.Click += mysub; // 2005 syntax
button2.Click += mysub;
button3.Click += mysub;

much better.


The answer is really no .NET program can do more or less than
another .NET program. It all gets translated down to IL which can be
retranslated back into another .NET language. The differences in .NET
languages are found in how many lines of code it takes for them to do
a job and how they deal with the environment outside of .NET.


I never claimed any different.

--
Tom Shelton
.