I last heard they were considering making lambdas arbitrarily passable, and I'm glad to hear they've decided not to. Hitting the allocator everytime you invoke a lambda would be really suboptimal. It had me worried that I couldn't use them in many cases!
As to people not using lambdas in the C++, many embedded systems don't yet have any compilers that support C++0x features. Some people don't want to use lambdas until they become part of standard C++. Additionally, I think that lambdas require allocation
from the heap, causing cache misses and memory fragmentation (although that might only be true when passing the lambda above the current scope).
I've leveraged his ideas to create a DSL development facility in my embedded C++ game engine. The facility enables end-users to quickly define new external DSLs for their specific game requirements. Once the DSL is specified, they can concentrate directly
on their game-specific problem(s). It takes the concept of 'data-driven' engine design to a whole new level. However, implementing the language building facilities in C++ presented some very novel challenges
Most game engines expose a single monolithic imperative scripting language such as Python or Lua. While initially a very simplifying solution, anyone who has used those on a non-trivial game project can attest to what a mess their game's scripts turns out
to be in toto. I think the types of DSLs my engine offers keeps things much cleaner due to their generally declarative style and exact fit to each specific problem. Not only that, but the intermediate tree representation of each DSL document is exposed, making
it available for inspection, transformation, and projection at runtime. Very lispy and very powerful.
I love intentional programming, and I wish the best to all of us trying to effectively leverage Simonyi's ideas in practice!
I've been thinking about how badly imperative programming tends to scale. But we can't forget about the added machine efficiency of going imperative. Perhaps once it becomes necessary to program to multiple cores in the general case, abstracting over the
physical machine with lambda programming will become more viable in my domain (embedded development). Maybe then my partners won't yell at me for using functional programming and immutability idioms in our C++ code base.