views:

1008

answers:

7

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?

A: 

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.

MichaelGG
Yes, they still allow single line anonymous methods.
Jonathan Allen
A: 

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.

Jonathan Allen
"Need"? :) You could just create a method and pass it in as a delegate to Parallel.For. But sure, it's nicer this way.
MichaelGG
Trust me, that is far more painful than it sounds.
Jonathan Allen
@MichaelGG: You can't, if the inline sub references local variables from outside the For loop.
Heinzi
+1  A: 

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
+8  A: 

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

Konrad Rudolph
I would say I have to totally agree with you, I like writing in VB, but I just wish they would make it a little bit more short hand.
Nathan W
+1 from me. I am more excited that F# is now a first class citizen in Visual Studio.
Jim Burger
What's the problem with `AddressOf`? Parenthesis are easy to overlook (and, unfortunately, not even required in VB.NET), so I think `MySub(AddressOf MyFunction)` is much clearer to read than `MySub(MyFunction)`, which is easy to confuse with `MySub(MyFunction())`.
Heinzi
First off, `AddressOf` is complete bogus. We don’t take an address of a function, we’re converting a function group to a delegate (although technically, `AddressOf` doesn’t even do that, it just disambiguates syntactically). Secondly, that is a completely uninteresting implementation detail. What we *want* to do here is treating a function as any old object. And this may rub some VB programmers the wrong way but that’s just too bad. No sympathy from me. I want to use a powerful language, not one catering to people who are afraid of useful and fundamental concepts.
Konrad Rudolph
Addressing your readability concerns: In theory you could be right. In practice, however, this is simply not an issue in other languages, other things being equal. Parentheses are certainly *not* easy to overlook. – If they were, most modern programming just languages wouldn’t work.
Konrad Rudolph
@Konrad: Nobody asked for sympathy. ;-) Anyway, thanks for the clarification. Of course, `AddressOf` doesn't *take* the address of a function, it (figuratively) *returns* a handle to the function (as an analogy. Of course, under the hood, it's different, but -- as you correctly point out -- that's an implementation detail). I still think that some kind of `quote` keyword eases reading, be it `AddressOf`, `'` (like in Lisp) or something else, to easily differentiate this case from the "more common case" of a function call. But I guess that's just a matter of taste...
Heinzi
PS: Remember that one of VBs goals is to be easy to understand for beginners. Of course, experiences computer scientists like us are familiar with the concept of functions being first-class citizens from lots of other languages. For a beginner who forgot about the '()' and has no clue that passing functions is even possible, the error message `Cannot convert Func(Of Integer) to Integer` might be a bit hard to interpret.
Heinzi
@Heinzi: True, but being beginner friendly is no longer the aim of VB, according to Microsoft. And if a language is beginners friendly *at the expense of* professional programmers, then it’s simply no longer apt for professional programmers – which would be a pity for me, since I really like VB.
Konrad Rudolph
+3  A: 

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.

pettys
A: 

There are no easy ways to manage this:

http://stackoverflow.com/questions/1568526/convert-c-statement-body-lambda-to-vb

without multiline lambdas.

sigh

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

Adam Davis
A: 

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

Erx_VB.NExT.Coder