when is VB.Net getting anonymous delegates?

[PJ6]

Desipte volumes of fanfare to the contrary, VB.Net does not have anonymous
methods. It has lambda functions. Anonymous methods can alter the state of
reference type parameters passed to them, while lambda functions can not. MS
calls anonymous methods 'anonymous delegates' which is fine... but where are
they? C# has them. Why have they been left out of VB?

Paul

 

[David Anton]

Maybe 2010?
The 2008 VB lambda was obviously a rushed feature - it looks like the VB
team said "hey, we can figure out how to make a very limited lambda work for
2008, but it has to be one statement which must return something..." and this
was thought to be better than nothing. It's really quite embarrassing when
compared to either the C# lambda (which can be a block of statements and
doesn't need to return anything) or the 'legacy' C# anonymous method.
--
http://www.tangiblesoftwaresolutions.com
C++ to C#
C++ to VB
C++ to Java
VB & C# to Java
Java to VB & C#
Instant C#: VB to C#
Instant VB: C# to VB
Instant C++: VB, C#, or Java to C++

 

[Alex Clark]

Personally I find multi-statement lambdas to be a messy, bad practice. They
make for poor maintainability and unreadable code. If I'm writing a Linq
statement and I need a quick method for selecting a key for a dictionary,
then a single statement lambda should suffice. If I need a multi statement
lambda, I'd rather set up a genuine function for it - chances are I might
need it again in the future anyway.

As for VB and C# being out of sync with features, it's nothing new. MS
*should* just unify the development teams into one language team, decide on
a spec list for the features of the ".NET Language", and then leave it to
C#/VB specialists in those teams to implement the semantics to suit the tone
of the language. Otherwise we just continue in the merry-go-round of VB
playing catchup to C# for most things, while acquiring a few bits of icing
here and there that C# doesn't really miss (i.e. the My namespace).

 

[Michael C]

Personally I find multi-statement lambdas to be a messy, bad practice.
They make for poor maintainability and unreadable code. If I'm writing a
Linq statement and I need a quick method for selecting a key for a
dictionary, then a single statement lambda should suffice. If I need a
multi statement lambda, I'd rather set up a genuine function for it -
chances are I might need it again in the future anyway.

That's fair enough, I see where you're coming from but that is just your
opinion. I don't really see a problem with a 3 line statement for example.
Almost any feature can be abused but this is not a reason to not use it at
all. It's not just useful for linq statements, you can use anonymous methods
and lambda expressions for all sorts of things. For example, I populate some
lists by passing a collection to a function along with a lambda expression
which gets the display text from each item in the list. Sometimes that
expression is 2 or 3 lines long to build up the string to return.

One of my favourites is to do my processing at the end of a linq statement,
eg

dataGridView1.Rows.Cast<DataGridViewRow>()
..Where(r => r["xyz"].ToString() = "A")
..ForEach(r => r.Selected = true );

Both of these things I mentioned can't be done in VB. I used to think it was
because assignment (=) and comparison (== in C#) are the same thing in VB,
so the compiler can't tell whether you're executing a statement or returning
a value, however it can tell from the delegate being used, eg with the where
statement it's expecting a Func so it knows the = means comparison. In the
case of foreach it's expecting an Action so it should expect = means
assignment. However, maybe it is a problem and it can't tell in some cases
such as multiline statements.

As for VB and C# being out of sync with features, it's nothing new. MS
*should* just unify the development teams into one language team, decide
on a spec list for the features of the ".NET Language", and then leave it
to C#/VB specialists in those teams to implement the semantics to suit the
tone of the language. Otherwise we just continue in the merry-go-round of
VB playing catchup to C# for most things, while acquiring a few bits of
icing here and there that C# doesn't really miss (i.e. the My namespace).

This is clearly the fault of Microsoft, they just don't put as much effort
into VB it seems. However, considering you said VB is always 1 step behind,
why don't you use c# instead?

Michael

 

[Cor Ligthert[MVP]]

Why?

Only because C# has it, cab lead too that we get in VB tons of possibilities
impossibilities because it conflicts with anonymous delegates (or whatever
thing that is seldom used in C#).

Just my opinion.

Cor

 

[Alex Clark]

That's fair enough, I see where you're coming from but that is just your
opinion. I don't really see a problem with a 3 line statement for example.
Almost any feature can be abused but this is not a reason to not use it at
all. It's not just useful for linq statements, you can use anonymous
methods and lambda expressions for all sorts of things. For example, I
populate some lists by passing a collection to a function along with a
lambda expression which gets the display text from each item in the list.
Sometimes that expression is 2 or 3 lines long to build up the string to
return.

Whereas I still find this, and your example, to produce messy code which
becomes harder to debug, I still agree in principle with your point - even
if I never used multi-line lambdas, I'd still have liked to have had the
option to use them. I'm glad VB is due to get them for the 2010 release,
but as I stated in my previous post - watch C# get something "even better",
which then gets added to VB in 2012.

Auto-properties is something that's really bugged me. C# has a particularly
nice shortcut syntax for setting up properties, complete with a hidden
backing variable, using a one-line statement. That feature cannot possibly
have been difficult to implement in VB, and indeed will make an appearance
in 2010, but why didn't they just add it to both languages there and then?
There are no syntactical ambiguities that I can think of, and it's a neat
feature that saves a lot of code.

This is clearly the fault of Microsoft, they just don't put as much effort
into VB it seems. However, considering you said VB is always 1 step
behind, why don't you use c# instead?

I've never really found anything in C# to be such a "must have" feature for
development that I've seriously considered switching. The refactor tools
did make me think twice, however, but still weren't enough of a motivation.
I come from a VB6 background and although I've done some C# coding, I still
prefer VB's syntax and (most importantly to me) it's readability in the
future when I come back to code.

-Alex

Note to all C# fans out there - this is not intended as a C# slam. I fully
appreciate that whatever your native tongue is, it will be the most readable
to you. I just happen to speak "End Sub" instead of "}".

 

[Family Tree Mike]

Personally I find multi-statement lambdas to be a messy, bad practice.
They make for poor maintainability and unreadable code. If I'm writing a
Linq statement and I need a quick method for selecting a key for a
dictionary, then a single statement lambda should suffice. If I need a
multi statement lambda, I'd rather set up a genuine function for it -
chances are I might need it again in the future anyway.

As for VB and C# being out of sync with features, it's nothing new. MS
*should* just unify the development teams into one language team, decide
on a spec list for the features of the ".NET Language", and then leave it
to C#/VB specialists in those teams to implement the semantics to suit the
tone of the language. Otherwise we just continue in the merry-go-round of
VB playing catchup to C# for most things, while acquiring a few bits of
icing here and there that C# doesn't really miss (i.e. the My namespace).

The .Net language is ML. I would say few dive into that...

As to unifying VB and C#, that is a sure way to kill both.

I find C# anonymous delegate great for event handlers being created in the
constructor. My problem with anonymous delegates in VB would be defining a
syntax for it. VB being verbose might need delegates that look something
like the following.

AddHandler(MyOKButton.Click, Begin Delegate : Me.Close() : End
Delegate)

The changes to the compiler is probably prohibitive. It seems like a big
chnage to the syntax vs the gains that are possible for the vb comunity.

 

[Alex Clark]

The .Net language is ML. I would say few dive into that...

Which BOTH languages compile down to, producing very similar and in many
cases identical IL. The "low level" .NET language is indeed IL, but true
procedural .NET code is in my mind just one language. VB and C# represent
different dialects of that same language. To me, VB is the London Cockney
and C# is the Glaswegian. Both are speaking English, but have very
different ways of speaking it. Chances are good that if you can understand
English, you can understand most of what each person is saying.

As to unifying VB and C#, that is a sure way to kill both.

I don't see how? As long as each language's syntax stays true to its roots,
it will always command the audience which is loyal to it. If they change
things in VB like using "switch" instead of "Select Case" then yes, they'd
end up with a large migration of coders from VB to C# - but they haven't.
They've actually made some significant changes to architecture with some of
the new WPF technologies such as DependencyProperties and RoutedEvents -
these are things they made available to BOTH languages. I didn't see it
killing either one off, though.

Same is true for LinQ. The language enhancements to VB were not
insignificant, and they were shared with C# as well for the most part. That
didn't kill off both languages either, did it?

Might have been nice to have a native way of using unsafe code in VB as
well. Despite treading close to the C# boundaries, I submit that it STILL
wouldn't have killed both languages. It merely broadens the horizons for VB
coders, and allows coders to essentially dabble in either language
effortlessly.

Specialised languages like F# will remain doing what they do best. Even
having said that, we're now seeing the beginnings of merging a declarative
model into the procedural model of C#/VB courtesy of XAML. Despite such a
huge change addition, guess what? Still isn't killing both languages.

The changes to the compiler is probably prohibitive. It seems like a big
chnage to the syntax vs the gains that are possible for the vb comunity.

Then that's for MS to figure out. It's up to them and their language
engineers to roll such a facility into VB without it being ambiguous,
prohibitively complex, uselessly restrained, or requiring big changes to
existing syntax. They managed to do all of this with LinQ, Lambdas,
Generics, and various others.

This is, after all, their job. ;-)

 

[Alex Clark]

As to unifying VB and C#, that is a sure way to kill both.

Further reading on that point...
http://www.developerfusion.com/article/9576/the-future-of-net-languages/

2nd Paragraph is "Co-Evolution for VB.NET and C#".


-Alex

 

[Cor Ligthert[MVP]]

Alex,

English Cockney and what you call Glaswegian is only way the English
Language is used and spoken by the user, it still is English.

As you want to make this distinct you have to think about by intance English
and Spanish, both languages using the Latin alphabet, however are derived
from diferent base languages, where Enlish has Germanic and Spanish has
Latin as base language.

Although that English has derived many Latin derived words (French), it is
very different from Spanish.

Cor

 

[Michael C]

Whereas I still find this, and your example, to produce messy code which
becomes harder to debug, I still agree in principle with your point - even
if I never used multi-line lambdas, I'd still have liked to have had the
option to use them. I'm glad VB is due to get them for the 2010 release,
but as I stated in my previous post - watch C# get something "even
better", which then gets added to VB in 2012.

That is one of the main reasons I use C#, Microsoft's attitude towards it is
a lot better.

Auto-properties is something that's really bugged me. C# has a
particularly nice shortcut syntax for setting up properties, complete with
a hidden backing variable, using a one-line statement. That feature
cannot possibly have been difficult to implement in VB, and indeed will
make an appearance in 2010, but why didn't they just add it to both
languages there and then? There are no syntactical ambiguities that I can
think of, and it's a neat feature that saves a lot of code.

Yep, I quite like that feature

I've never really found anything in C# to be such a "must have" feature
for development that I've seriously considered switching. The refactor
tools did make me think twice, however, but still weren't enough of a
motivation. I come from a VB6 background and although I've done some C#
coding, I still prefer VB's syntax and (most importantly to me) it's
readability in the future when I come back to code.

-Alex

Note to all C# fans out there - this is not intended as a C# slam. I
fully appreciate that whatever your native tongue is, it will be the most
readable to you. I just happen to speak "End Sub" instead of "}".

I used to be a VB6er and be very against the C style syntax but after
getting into it I much prefer it now. I had to do a vbnet project recently
after not using VB syntax for many years and realised what a flip I've done.
I just don't like typing all those extra words

 

[Cor Ligthert[MVP]]

Michael,

VB 2008 uses less by you so called "extra words" then C#.

VB is a living language while C# has more the behaviour as by instance Latin
to stay consistent.
Thas does not mean that you would not like more C# then VB, however don't
use the wrong argumentation about that.

It can be that you are still writting VB 2008 as you did in the previous
milenium, but that has nothing to do with more words needed in modern VB
than modern C#.

Cor

 

[Michael C]

Michael,

VB 2008 uses less by you so called "extra words" then C#.

Hardly. While C# might have some case where you need extra keystrokes the
really common ones like Dim, As, Function, Property, Sub, End Sub etc are
most definately longer. C# might take more code to write in your own events
but this is a much less used feature.

VB is a living language while C# has more the behaviour as by instance
Latin to stay consistent.

Ironically your english isn't good enough for me to understand what you're
saying there. I'm not picking on you there I respect you for knowing 2
or more languages when I only know one.

 

[Rory Becker]

Hello Michael,

Ironically your english isn't good enough for me to understand what
you're saying there. I'm not picking on you there I respect you
for knowing 2 or more languages when I only know one.

I agree regarding Cor's knowledge of multiple languages... I am also suitably
impressed.

In this case I think Cor means "of for example" where he says "as by instance"

Therefore ... "VB is a living language while C# has more the behaviour of
for example instance Latin to stay consistent."

Apologies if I have got this wrong Cor.

 

[Tom Shelton]

Michael,

VB 2008 uses less by you so called "extra words" then C#.

Not true. Especially with VB.NET's terrible intellisense.

VB is a living language while C# has more the behaviour as by instance Latin
to stay consistent.

LOL... Really? Hmmm, every major release of C# has gotten new features, and
that will happen again with 4.0. C# is by no means a constant.

Thas does not mean that you would not like more C# then VB, however don't
use the wrong argumentation about that.

It can be that you are still writting VB 2008 as you did in the previous
milenium, but that has nothing to do with more words needed in modern VB
than modern C#.

Cor - VB.NET has wordy syntax. That's just a fact.

 

[Cor Ligthert[MVP]]

Right,



Cor

Hello Michael,


I agree regarding Cor's knowledge of multiple languages... I am also
suitably impressed.

In this case I think Cor means "of for example" where he says "as by
instance"

Therefore ... "VB is a living language while C# has more the behaviour of
for example instance Latin to stay consistent."

Apologies if I have got this wrong Cor.

 

[Cor Ligthert[MVP]]

Tom,

I am writing about the language itself, not the Net additions.

Although that C# has some changes, stays it clearly a from C derived
language.
(And you should see what I have written about that crazy in most cases
senseless Dim)

dim a = "Tom"
var a = "Tom";

dim b as New Shelton
Shelton b = new Shelton();

2 of them



I use as well both program languages and in my idea in C# I have much more
times too use the keyboard than with VB

While I agree that I like Linq in C# more than in VB (I don't understand why
that "with" was needed), however I do not see Linq as a language part.

Cor

 

[Tom Shelton]

Tom,

I am writing about the language itself, not the Net additions.

Although that C# has some changes, stays it clearly a from C derived
language.
(And you should see what I have written about that crazy in most cases
senseless Dim)

dim a = "Tom"
var a = "Tom";

dim b as New Shelton
Shelton b = new Shelton();

2 of them

On the whole, VB is still wordier. Further, you need to consider the inferior
intellisense in VB as well.

For example, in C# in a new project type:

string path = Path

and you will immediately get a underline under path, and you can hit ctrl-.
and insert the using statement. VB.Net won't do anything until after you type
in the entire expression and then hit enter - which means no intellisense on
the System.IO.Path methods, etc. So, tell me - which is more effiecient?

Further, you end up having to hit escape a lot more in VB because it's
intellisense gets confused more - especially when you have method overloads.

And now, in 2008 with the inclusion of auto-implement properties, it's even
better:

VB:
Public Class ClassWithProperty
Private _i As Integer

Public Property I As Integer
Get
Return _i
End Get
Set (ByVal Value As Integer)
_i = Value
End Set
End Property
End Class

C#:
public class ClassWithProperty
{
public int I { get; set;}
}


And what about the fact that lambdas in VB.NET have to return a value? It
makes simple things much harder. For example:

C#:
List<int> integers = new List<int>() {1, 2, 3, 4, 5};
integers.ForEach (i => Console.WriteLine (i));

VB:

Dim integers As New List(Of Integer)(new Integer(){1, 2, 3, 4, 5})
For Each i As Integer in integers
Console.WriteLine (i)
Next

No, on the whole, you can write much more concise and compact code in C#.
And, I happen to like case sensitivity

Anyway, in no way is any of this mean to be a slight on the VB language - but,
overall I find I work better and the IDE is a much smother experience in C#.
YMMV - as usual.

I use as well both program languages and in my idea in C# I have much more
times too use the keyboard than with VB

I would have to disagree.

While I agree that I like Linq in C# more than in VB (I don't understand why
that "with" was needed), however I do not see Linq as a language part.

Hmmm... Interesting. I was going to say, that I thought that overall that
Linq in VB.NET was a little better integrated - the biggest problem is the
limitations that VB.NET has on lambda's...

 

[Alex Clark]

Tom,

Whereas I agree with you about VB having a wordier syntax ("End xxx" as
opposed to "}" is a good example), if you're holding its intellisense
features against it that's really a slam on VS and not the language itself.
If you were writing both in Notepad and compiling via the command line, any
Intellisense advantages disappear. Of course if you were doing it that way,
you'd be writing an awful lot of "End Sub"'s in VB...

-Alex

 

[Alex Clark]

Alex,

English Cockney and what you call Glaswegian is only way the English
Language is used and spoken by the user, it still is English.

Which is precisely why I used this analogy, Cor. I just don't view C# and
VB.NET as two completely different languages which are worlds apart - I view
them as two very different dialects of the higher level .NET base language.

I may be wrong, but aren't there facilities in the CLR inside the CodeDom
namespace that allow a coder to programmatically generate code in either VB
or C# based on abstracted concepts like "insert a loop here" or
"conditionally do this or this"? If so, then the generator engine is
essentially proving my point - it takes a root langauge containing the
abstracted concepts and converts it into whichever dialect you choose.

-Alex