I'll hazard the guess that hazzen is interpreting 'lambdas' to involve closures.

Yes and no. If a library assumes a lambda is easy, you will see a lot of code like this (using somewhat bastardized OCaml types):

  interface 'a collection {
    void sort(lt:'a -> 'a -> bool);
  }

So, if you want to use lambdas, you would get:

  foos.sort(fn x y -> x.bar() > y.bar());

And if you don't want to use lambdas, you would get:

  bool sort_by_bar_gt(x:Foo, y:Foo) {
    return x.bar() > y.bar();
  }

  foos.sort(sort_by_bar_gt);

And that is assuming you can nest functions, but chances are you will have to put that function somewhere removed from the actual call to sort. This is the exact problem the STL hits: it assumes, for many things, you want a functional style - and then it doesn't give you a way of writing lambdas. You are left with one-off functors littering your code, wishing you could write that lambda.

I would like to stress: I think lambdas are a requirement for any language, I just take issue with the argument presented to convince lambda haters.

Since no GC is a given, a lambda with a closure maps nicely to the C idiom of a function pointer and a void* user data parameter.