But the limitations... they almost make it not worth the trouble. Most obviously, VB.Net doesn't support true lambdas. In a true lambda environment, I could do something like this:
In true lambdas, you can put any code you like inside of your function. C# and F# allow this. VB.Net does not- VB.Net only allows expressions (you can't do ifs or loops or anything like that).
f = Function(x as integer) if (x % 2 = 0) then return x / 2 else ... some other code ...
Still, there's a lot you can do with expressions, so that's not too bad. Since you get closures, you can work around that without too much trouble.
But then you start running into the bizarre things. I wanted to do a patterned call. In many functional languages, you can create functions like this:
f(1) = 1; f(2) = 2; f(x) = f(x - 1) + f(x - 2);. Calling f(13) will print out the 13th number it the Fibonacci sequence.
Now, I accept that VB.Net wouldn't have an architecture like that built in- it's a somewhat obscure functional trick. But I was hoping I could roll my own. My first attempt at it was to come up with a compiler macro- oops! VB.Net doesn't support pre-proccesor macros. C# does, of course.
Well, okay, what about Attributes? .NET has the ability to define metadata on code, that you can "reflect" on to change runtime behavior. I could do something like this:
Module 1 '"fib" is the function name, the second parameter is the pattern- if it returns true, execute this 'operation, otherwise, go find another operation named "fib" to execute. <PatternedFunction("fib",function(x as Integer) x = 1 or x = 2)> Function f1(x as Integer) Return x End Function <PatternedFunction("fib",function(x as Integer) true)> Function f2(x as Integer) Return PatternedCall("fib")(x - 1) + PatternedCall("fib")(x - 2) End Function End Module
Not as concise as I would like, but hey, it works, right? Wrong. Turns out, since Attributes are evaluated at compile time, you can only pass constant expressions into them. Since a function may possibly contain a closure (even though this one does not), you can't ever treat a function like a constant.
I'm being an FP snob, and I know it. My reason for wanting to do this is less because I have a specific need and more because I want to. I get frustrated when a language implements a potentially awesome feature in a half assed way, but as I think about it, "Potentially awesome, practically useless" describes VB.Net to a "T". If I had my druthers, we'd be a C# shop if we were doing Microsoft at all- I think a big portion of our business would be streamlined by a real RAD language, like Ruby or Python.
All of my complaints would be patched if VB.Net supported compiler macros. I'm stunned that it doesn't- it's not exactly the hardest thing on earth to implement; your average C compiler has had a macro pre-processor since before I was born. C# has one. And here's the real kick in the teeth: most macro engines are language agnostic, so there's no reason they couldn't have wired the C# engine onto VB.Net.
Basically, this is an exercise in driving home the flaws of the language that pays my bills.