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 have been long awaited(auto properties and Collection Initializers), one that caught my eye was the multiline lambdas like in C#.

In the video he used an example like this:

Dim scores = {10,20,30,40,50}
Dim thread as new Threading.Thread(Sub()
                                   For Each o in scores
                                     console.writeline(o)
                                     Next
                                   End Sub)

Now I like VB in all it verbosity but I'm just a bit worried that writing sub...end sub inline could get a bit messy, I can see some merit in inlining when you are writing C# when you only have to use something like c => {....} and you can cut out a lot of code.

What are your throughts of multiline lambdas in VB?

Would you find them useful and where?

Answer 1

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).

Answer 2

By preference I'm a C# developer, but have been using VB 9 almost exclusively for about a year now. The #1 thing about VB 9 that breaks my heart is the limited lambdas. Lambdas in VB 9 are limited in the following ways:

• Only one statement.
• They must return a value.

So the ForEach method on collections will not work with lambdas, and only the very simplest of operations will work. So most of the time you have to move your logic to some other method and use AddressOf. Many times this cleaves the readability of the code in a dramatic and heartbreaking way.

It's something that I feel many would not pick up on unless they've used anonymous methods fluently in another language that fully supports them (C#, JavaScript, etc.), rather than the crippled support they have in VB 9.

I'm extremely relieved that they're fixing lambdas in VB 10.

Answer 3

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 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

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 6

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 7

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.