What do you think of multiline lambdas in VB 10

Question

I was just watching a video on MSDN Channel 9 which can be found here, about some of the new features in Visual Basic 10. Now I like most of the new features, some of which hav

Answer 1

Full anonymous method support in VB means you can start taking a more functional style with things. If the Sub() End Sub need to go on separate lines... that hurts. I'd hope they'd allow single-line anonymous methods, so long there was only one statement.

Answer 2

I can think of two reasons off the top of my head why I love it! Been waiting too long for this.

First:

 Private Sub SomeMethod()
     Dim SomeVariable as String = "Some text."

     AddHandler SomeButton.Click, Sub()
                                      SomeVariable += " Some more text"
                                      MessageBox.Show(SomeVariable)
                                  End Sub

Second:

 Private Sub SomeMethodRunningInAnotherThread()
     Me.Dispatcher.Invoke(Normal, Sub()
                                      'Do some other stuff '
                                      SomeTextBox.Text = "Test"
                                  End Sub)
 End Sub

Answer 3

There are no easy ways to manage this:

Convert C# statement body lambda to VB

without multiline lambdas.

sigh

So yes, I'm anxious for this to be fully released.

-Adam

Answer 4

Same here, I love vb. Most of the time you are thinking and not actually writing code anyway, so the verbosity argument fails in my opinion, as you are usually staring at code or editing it, and imagine The time you are saving understanding your code when you read it in its verbosity in vb? Much easier and less error and bug prone as opposed to c#.

Also, c# still has no with clause, and vb has had this even prior to the .net days.

With obj.class.methods

   .property = 1

   .attribute = 2

End with

Imagine this with 10 things that need to be set? In c# you'd have to create a reference to obj.class.methods and use that for shorthand expressing, which is wasted memory and inefficient, so in that respect vb does use less memory and you are not punished for using less memory unlike with c# .

And the "using" keyword argument fails since using doesn't work with most objects or objects that don't implement idisposable which is absolutely annoying.

Then, think of all the explicit castings you have to do in c# as opposed to vb. C#errs will argue that is encourages better coding but that is nonsense, as any good developer doesn't need to explicitly cast something 500 times a day to understand that if he didn't an implicit casting would take place (as it does in vb).

Most c#errs use it because they come from a c background, which is fine, but I find a lot of them started with it because it contains the letter c and they think its cooler because it lacks the language innovation that vb has, making it harder for the developer, and that makes them feel smarter and cooler and above everyone else - lol, they don't understand that hiding complexity at 0 cost is the ultimate goal, which is what vb can do for you. Notice the at zero cost part, as it would not be a good thing if it was at above zero cost.

Answer 5

You are going to need multi-line once we get the ParallelFX library.

For example, lets say you wanted to make this loop parallel:

For i = 0 to 100
  '12 lines of code'
Next

The parallel version would be:

Parallel.For( 0, 100, sub(i)
  '12 lines of code'
  End Sub )

It works by turning the guts of the loop into a brand new sub. That new sub is called by N threads, N usually being the number of available cores.

Answer 6

Personally, I think that VB's syntax for delegates and lambdas is completely bogus. I mean, come on, AddressOf! This was fine in VB6. It is definitely not fine in a language such as VB.NET where functions should be treated as first-class citizens (although they really aren't, of course) and where conversion from method groups to delegates is more or less transparent.

Now the introduction of inline functions is horribly verbose. I actually believe that the C# approach – x => f(x) would fare very well in VB because it shows exactly what it does. At the current state, I prefer C# for any functional programming work, which is a pity because I generally favour VB.

Now, I really rejoice that VB finally gets multiline lambdas and statement lambdas because they're still useful sometimes (take the case of Parallel.For). But the syntax is messed up. The same goes for iterators, by the way (if they should make it into VB10).