Logo




Subscribe:
RSS 2.0 | Atom 1.0
Categories:

Sign In


[Giagnocavo]Michael::Write()

 Monday, March 31, 2008
The reason VB.NET is truly a second class citizen

No support for anonymous methods/lambda statements. I first realised this when someone commented on one of my functional C# postings, asking "how can I write this in VB"? Turns out VB has no support for anonymous methods. Ouch.

This lack of capability rules out a so much functionality, I honestly cannot imagine writing anything significant today using VB.NET. But with LINQ and F# making such a big splashes, I have high hopes for the future of functional programming on the .NET languages, and I'm sure VB.NET will get itself fixed up.

Really, dropping anonymous methods in favour of stuff like XML literals? Maybe that's why it's listed as first time or casual programming ;). (No, I jest. Scheme is far better for first time programming.)

Code
Monday, March 31, 2008 9:55:56 PM UTC  #    Comments [8]  |  Trackback

Tuesday, April 01, 2008 7:29:28 PM UTC
This is a very deliberate decision I believe, it is simply more VB'ish that way. See Eric Meijer in http://channel9.msdn.com/ShowPost.aspx?PostID=273697 (5:00 into the movie).
Tuesday, April 01, 2008 8:03:34 PM UTC
I'm sure they had good reasons for the current design, but I doubt this is a long-term feature VB won't miss. I'd be very surprised if there's no lambda statement support in the next VB version.
Wednesday, April 02, 2008 7:32:51 AM UTC
Have you heard about Function? its a function in VB.net that allow anonymous methods.
Wednesday, April 02, 2008 7:35:45 AM UTC
Yes, but the syntax only allows a single expression. So, it's ok for cutesy stuff but no real work.
Sunday, April 06, 2008 5:36:06 AM UTC
Michael Giagnocavo:
When you cannot use some syntactic sugar in some scenarios that's one thing. But when you have absolutely no way to accomplish something that's much more serious. There are fundamental features VB.Net can do, but C# cannot. Does this mean C# is incapable?
how about accomplishing this simple OOP thing in C#:

Public Interface IHasChildren(Of TChild)
Function GetChild(id as Integer) as TChild
End Interface

Public Class ForumBoard
Implements IHasChildren(Of Thread), IHasChildren(Of Page)

Public Function GetThread(id as Integer) as Thread Implements IHasChildren(Of Thread).GetChild
End Function

Public GetPage(id as Integer) as Page Implements IHasChildren(Of Page).GetChild
End Function
End Class

P.S. And don't forget about
Property Color(x as Integer, y as Integer) as Color
Sunday, April 06, 2008 7:16:07 AM UTC
Wow, so fully featured anonymous methods are just "some syntactic sugar"? Wow. That's a pretty big claim. From a real project, we were able to reduce the overall amount of code by about 20% just by adding a few functional patterns. That seems to extend beyond syntactic sugar. Being able to create Expression Trees that eval to void (aka Action<T>)? Again, I think it's a bit of a stretch to call that syntactic sugar.

Anyways, I'm not sure what simple OOP thing you're demonstrating. You seem to be just implementing a generic interface twice in a class. C# has explicit interface implementation too:

interface IHasChildren<TChild> {
TChild GetChild(int id);
}
class ForumBoard : IHasChildren<FThread>, IHasChildren<FPage> {
FThread IHasChildren<FThread>.GetChild(int id) { return new FThread(); }
FPage IHasChildren<FPage>.GetChild(int id) { return new FPage(); }
}

Or did I misread the VB code?

As far as multi-valued indexers (I think that's what the Property with two parameter is), yea, that's cute but hardly groundbreaking or that common. I'd hardly consider that on the level of full anonymous methods.

If you look at some of the C# functional articles on my site, I demonstrate that just having delegates doesn't even approach the power that you get when you have anonymous methods.
Sunday, April 06, 2008 2:20:30 PM UTC
>Wow, so fully featured anonymous methods are just "some syntactic sugar"? Wow. That's a pretty big claim.
As far as I know, they are. The !same! thing is accomplished with a function [+class]. That's what compiler unwinds the sugar to. Yeah I understand that it's mighty, but you can just do what compiler does and get the same code/behavior without too much source code overhead. By comparison VB.Net code overhead of "emulating" unsupported anonymous method kind is much less than C# code overhead of using LINQ2XML (In real-world scenerios it's even more striking):
Dim x = <a><b c="d"/><e>xxx<f/></e></a>
x.<a>.<b>.@c = "g"
Console.WriteLine(x...<e>.Value)

The point is you can produce the same IL structure.

>You seem to be just implementing a generic interface twice in a class.
Yes, I am. What you forgot is that in my implementation the functions are public. Just try to add the public modifier.

>As far as multi-valued indexers (I think that's what the Property with two parameter is), yea, that's cute but hardly groundbreaking or that common.
C# lacks some other features in this area. You can think of C# indexers as incomplete syntactic sugar for VB.Net properties with parameters and <DefaultProperty> attribute that has two limitations: only one parameter and only one "indexer" per class.
>I'd hardly consider that on the level of full anonymous methods.
My point is full anonymous methods behavior and resulting IL structure can be accomplished with VB.Net. But there is no way to generate the IL structures for VB.Net construct mentioned above.
So from this point of view explicit interface implementations and properties with parameters in VB.Net are on the level of pointers in C#.

Sunday, April 06, 2008 4:48:45 PM UTC
>Wow, so fully featured anonymous methods are just "some syntactic sugar"? Wow. That's a pretty big >claim.
>As far as I know, they are. The !same! thing is accomplished with a function [+class]. That's what >compiler unwinds the sugar to. Yeah I understand that it's mighty, but you can just do what >compiler does and get the same code/behavior without too much source code overhead. By comparison

OK, well, if you believe that creating closures by hand by creating new objects all over the place isn't "much overhead"... well, go try it first :).

Remember, "everything" is syntactic sugar. But usually the term is applied where it's just providing some simple translation. Otherwise you might as well go claim everything above microcode is syntactic sugar (and then, just because you don't go set the transistors yourself).

You can write a book in Notepad, but that doesn't make it a good tool for the job even if it "works".

>VB.Net code overhead of "emulating" unsupported anonymous method kind is much less than C# code >overhead of using LINQ2XML (In real-world scenerios it's even more striking):
>Dim x = <a><b c="d"/><e>xxx<f/></e></a>
>x.<a>.<b>.@c = "g"
>Console.WriteLine(x...<e>.Value)

The XML literals in VB seems like a big hack to me -- really, mixing literal strings? But hey, if people like it, more power to them. The positive side to VB's "XML Support" is that it makes up for a huge omission in the XML APIs, the ability to ignore namespaces. But that's a screwup from the team that created the API and not something a language should be fixing.

>The point is you can produce the same IL structure.

OK, quick, go generate an expression tree in VB to match this:

int q = 7;
Expression<Action<int>> x = i => Console.WriteLine(i + q);

This is a trivial example. Yet, I think you'll find the overhead to be significant. In real world scenarios, you quickly get burned.

>Yes, I am. What you forgot is that in my implementation the functions are public. Just try to add
>the public modifier.

I made the interface and class public and it's fine. All interface implementations have to be public. Just remember, you can't add modifiers to an explicit interface implementation, but they're still there -- just call them explicitly. Do I have this right?

>C# lacks some other features in this area. You can think of C# indexers as incomplete syntactic
>VB.Net. But there is no way to generate the IL structures for VB.Net construct mentioned above.

The extended property syntax -- yea well, for the few times I need it, I can write the get and set by hand -- it's basically one more line of code. VB can't do stackalloc or use pointers. These are old arguments and so on. I don't believe any one of these features compares to the power anonymous methods brings, hence my statement of VB being "second class". I would not be able to use VB in production if I wanted to because of this huge omission (which I'm sure will be in the next version).

-Michael
Name
E-mail
Home page

Comment (HTML not allowed)  

Enter the code shown (prevents robots):

Live Comment Preview