Just because it comes in your size, doesn’t mean you should wear it.

I found Guido van Rossum’s meditation on Language Design Is Not Just Solving Puzzles quite on target and relevant to what we’re going through right now as we consider how to design the myriad of language features that make up LINQ. (Thanks to Lambda the Ultimate for the pointer.) If you look at all the possible kinds of language features that you can stick into a programming language, it often seems like there’s an inexhaustible supply of them and many of them are quite interesting or compelling. But the problem is that, in the end, a programming language has to have some kind of semi-coherent style or design vision associated with it or else it starts to collapse into an unintelligible mess.

This fact often puts extremely annoying constraints on what you can do when designing new language features. The example we’re struggling with right now is lambda functions. The whole point of a lambda function is to create a really terse, inline function, but Visual Basic is, by nature, a wordy language. Which means that most of the “obvious” designs for a lambda expression involve something that looks worse than not using lambda expressions at all. Multi-statement lambdas are also a problem due to our line-oriented nature (and, ironically, this is what motivated Guido’s entry as well). What’s the answer? Right now, it’s not clear. But when you get boxed in like this, sometimes you have to sacrifice functionality you’d really like to have but just can’t find any particularly good way to express. Some things just can’t be done within the overall framework of past design choices. It’s just the way it is.

(The title of this entry is something my wife likes to say when confronted with someone wearing something clearly not designed for their body shape (e.g. someone with a pronounced gut wearing a belly shirt). Just because you can wear something doesn’t mean that you should.)


7 thoughts on “Just because it comes in your size, doesn’t mean you should wear it.”

  1. Lambda or anonymous methods are highly welcome in our VB community. This could lead an entire new style in VB programming. We all support a simple, meaningful and short form of lambda expressions. It will be much happier writing

    Dim r = list1.FindAll(Function(v) v > 0 AndAlso v <= 90)


    Nested Function Condition1(ByVal v As Integer)As Boolean

    Return v > 0 AndAlso v <= 90

    End Function

    Dim r = list1.FindAll(AddressOf Condition1)

    Of course, the nested function syntax is useful in other situations too. Many of us think that the nested functions could take the place of GoSub, which we’ve lost for 4 years.

  2. Paul, perhaps you could post come c# code the uses lambda functions and invite your readers to provide you with equivalent VB code. Also, I don’t mind using colons to place multiple statements on the same line (if I must).

  3. Never give up! Never surrender!

    Get rid of the damned line continuation character and set VB free. Equallity for all whitespace! What a coup to accomplish that without ;’s!

    Then ":" wouldn’t be needed as a statement concatenator and could look really cool in a lambda expression – "f(v): v > 0 and v <=90"

  4. My first impression is that anonymous functions don’t belong in VB. (I also never want to read code that uses ‘:’ to defeat the line oriented nature of VB. )

    I’m a little rusty on VB right now, but does it allow nested functions and/or classes? If so, it seems you could use a function/functor for anything that anon funcs would be good for. You wouldn’t have to pollute a namespace with your function, because it would be scoped within the method where it is used, just as would be the case with an anonymous version. It would also be obvious how to pull the code out if you later determine that it’s more generally applicable than you first thought.

  5. We’re definitely started with nested functions and working our way forward, since nested functions give us at least the variable capture semantics that we need to properly do stuff like LINQ. So I would expect (but won’t promise) that nested functions will make an appearance in VB.

    The question really is about the next step — moving the nested functions inline. True lambda functions might not be so bad, and we’re looking at some options. What looks really difficult is multi-statement lambdas. It’s not so much an issue with line continuations (although we’re looking at that issue too, give the length of LINQ query statements), but more with block delimiters. The fact that VB uses words for block delimiters makes inline multi-statement lambdas look pretty wordy. I’m not saying the issues are insurmountable — we’re still designing it — just that it’s not an entirely obvious piece of work…

    Stay tuned…

  6. Can you just support lambda function of the single line expression for query and other simple tasks, then support nested function for multi-statements scenarios? The nested function seems more powerful than an anonymous function — it can be generic, it has a name so can be recursive, etc…

  7. I can’t imagine if that VB doesn’t get at least single line lambda expressions support. When Orcas releases, many third-party providers will take advantage of the lambda and the partial function programming style in their new software products. They often consider C# users first. VB users will not able to enjoy the convenience brought by them if VB9 doesn’t have a short and concinnity syntax of lambda.

Leave a Reply