Lambda-the-cs-concept is ofc beautiful. Lambda-the-c++-language-feature is not. The purpose of programming languages in an industrial context is to make implem

Lambda-the-cs-concept is ofc beautiful. Lambda-the-c++-language-feature is not. The purpose of programming languages in an industrial context is to make implementations of programs simple. When they utilize complex abstractions, the abstraction should simplify overall architecture. The way to measure the ‘simplification’ is how much reasoning a programmer needs to do to understand what their code does in the context of the language constraints and runtime. In the context of C++ this includes runtime memory use and execution speed. The latter requirement means C++ code must be such that it’s amenable to performance analysis and when hotspots arise, one should have an obvious strategy how to continue. C++ Lambdas make this reasoning more complex (in my experience). So the main problem is the added complexity to reasoning about runtime behaviour, resource use and performance. And this is not complexity that would add value by removing that complexity from some other area of the program. Lambdas in C++ start by looking cute and innocent. Then, when the first problems arise, you realize that by using a lambda instead of just an in-place class to capture the context, which you can reason using the same bysantine set of rules, you actually need to grok a whole new set of rules on top of that: https://en.cppreference.com/w/cpp/language/lambda https://en.cppreference.com/w/cpp/language/lambda That’s a huge mental cost in general what is a saving of few lines of code. Hence, don’t use lambdas in api design. The only way I guess to realize why the lambdas are in such bad taste is to use a programming language where they are part of the core language syntax, like python, scheme, F#… where you can use them without each time double checking that you are not accidentally shooting your foot off.