4 ms·

Strong disagree. It’s not about the syntax, it’s about understanding the resource management model lambdas add on top of the existing mess. There is no good r

by fsloth 3y ago

Strong disagree. It’s not about the syntax, it’s about understanding the resource management model lambdas add on top of the existing mess. There is no good reason to use lambdas except parametrization of stl algorithms. Don’t use them as part of api design. The only thing you gain is one more level of complexity on reasoning resource management. Yes, to be specific, one should know how they work, and then not use them. This is in the context of C++ being a minefield of practically infinite complexity, in which the only way to survive is to pick the language subset you know you are able to handle, and stick with it. Of course, every party picks their own subset :)

fluoridation 3y ago
Would you mind being a little less vague about what's so bad about lambdas?
- fsloth 3y ago
  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.
  - gpderetta 3y ago
    Lambdas are just very thin sugar over local classes. I'm not sure what do you find so complex.
    - fsloth 3y ago
      Exactly, but using a different set of syntax, plus a new ruleset of capture semantics. The capture syntax especially is a minefield. And are the runtime guarantees exactly the same as that of a local class instance? The question is - what does this extra complexity buy us? Is it worth it?
      - fluoridation 3y ago
        >The capture syntax especially is a minefield. Functors are no easier to use. Either you initialize captured values through a constructor or by manually setting each member. In both cases you have to name the same values several times and ensure that you're doing it correctly. With lambdas, if capture by value or by reference is enough for everything you need, the code is much more succinct and readable. It seriously reduces useless, error-prone boilerplate. >And are the runtime guarantees exactly the same as that of a local class instance? Yes. >The question is - what does this extra complexity buy us? Is it worth it? It buys us more readable and straightforward code. Yeah, I'd say it's worth it. I haven't written a functor in years.
  - fluoridation 3y ago
    >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 No, I don't agree at all. Unless the callee accepts an std::function, passing a lambda is exactly equivalent to passing an ad hoc functor. There's no problem you'll run into with one that you wouldn't have run into with the other.
AnimalMuppet 3y ago
> There is no good reason to use lambdas except parametrization of stl algorithms. IIRC, there are usually several alternate ways to parameterize STL algorithms. If lambdas don't add enough value to be worth the additional complexity in other places, then they don't as STL arguments either.

by fsloth 3y ago

fluoridation 3y ago

Would you mind being a little less vague about what's so bad about lambdas?

fsloth 3y ago
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.
- gpderetta 3y ago
  Lambdas are just very thin sugar over local classes. I'm not sure what do you find so complex.
  - fsloth 3y ago
    Exactly, but using a different set of syntax, plus a new ruleset of capture semantics. The capture syntax especially is a minefield. And are the runtime guarantees exactly the same as that of a local class instance? The question is - what does this extra complexity buy us? Is it worth it?
    - fluoridation 3y ago
      >The capture syntax especially is a minefield. Functors are no easier to use. Either you initialize captured values through a constructor or by manually setting each member. In both cases you have to name the same values several times and ensure that you're doing it correctly. With lambdas, if capture by value or by reference is enough for everything you need, the code is much more succinct and readable. It seriously reduces useless, error-prone boilerplate. >And are the runtime guarantees exactly the same as that of a local class instance? Yes. >The question is - what does this extra complexity buy us? Is it worth it? It buys us more readable and straightforward code. Yeah, I'd say it's worth it. I haven't written a functor in years.
- fluoridation 3y ago
  >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 No, I don't agree at all. Unless the callee accepts an std::function, passing a lambda is exactly equivalent to passing an ad hoc functor. There's no problem you'll run into with one that you wouldn't have run into with the other.

AnimalMuppet 3y ago

> There is no good reason to use lambdas except parametrization of stl algorithms. IIRC, there are usually several alternate ways to parameterize STL algorithms. If lambdas don't add enough value to be worth the additional complexity in other places, then they don't as STL arguments either.