The lowest common denominator

There's a lot of discussion about functional programming these days. Not everyone might think that functional additions to a language are such an essential benefit. But as you might know until now I think it really is. I think that a functional programming style can lead to a higher form of abstraction. And more abstraction in your code leads to lesser lines of code which leads to fewer bugs.

In our current project we're working with C# 2.0. But some us are really looking forward taking advantage of the C# 3.0 features. Though we all agree, that not everyone might have the ambition, the time or the interest to make himself deeply familiar with the new features within a narrow time frame. This leads me to another currently much discussed topic in the blogosphere: the lowest common denominator. Does a feature lead to better code if there are still a lot of people not understanding it?

Well, it depends. Do you actively try to leverage programmers which are behind? Do you have a review process in your SDLC? Do you have a critical mass on programmers in your project already familiar with the technology or at least willing to adopt and master the new features? Do you have a culture in your company where fascination is getting nurtured?

What do you think? Do you have own experience in adopting new technologies within a project lifetime?

Ambition vs. LINQ

If you would be given the opportunity to choose your data query abstraction language from those two examples:

LINQ:
products.Where(p => p.Category == "Food").OrderBy(p => p.Price).Select(p => p.Name).Take(2);


Ambition:
Product.select {|p| p.category == "Food" }.sort_by { &:price }.map{ &:name }.first(2)


Which of these implementations would you prefer? I really like them both, though the second one is even more concise.