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