Hacker News Reader

Comment by muststopmyths | Hacker News Reader

Man, that c++ code triggers my hatred of lambdas. Instead of a hopefully descriptive function name, whose code I can peruse separately from trying to understand the enclosing code, I have to understand every goddamn line in real time.

lambda more than 5 lines should be a compile error.

Why not move C++ towards readability instead of enabling laziness in the guise of features ?

View on HN

For a lot of things, I actually like being able to read what the code is doing inline, rather than having to constantly jump around to function definitions.

It is a subjective thing, and I think the permissive approach of the language with regard to lambda complexity is a good thing.

The biggest thing that can be done to make that code example more readable is to use coroutines (which were just introduced in C++20) which will get rid of the lambdas.

I don't dislike all lambdas. I just wrote some code that made pretty heavy use of lambdas, but they were always called synchronously within their creating function, as a way to reduce code duplication within that function. Sure, I could have defined a separate method, with a separate declaration in the header file, with lots of arguments, but that would have been considerably less readable.

What I often find problematic is lambdas that outlive their creators. Especially ones that have lots of captures. Especially especially ones where those captures include objects with complex destructors. It's a common pattern in the code I have to work with, and it constantly results in serious bugs. A far better pattern is to wrap the things that need to outlive the caller in their own object - often a "request" object that should have already existed and had its own separate lifetime - and pass that around instead of passing lambdas.

I'd be perfectly happy with lambdas, even lambdas with captures, that couldn't outlive their creator. Trying to attach one to an object with non-local scope would be a compiler error. We already have objects to wrap up the same bits of data and control flow that a long-lived lambda would have. People should use them.

Do you hate the C++ syntax for lambdas or the concept of lambdas?

The concept of anonymous blocks of code in the middle of a flow annoys me. I fully appreciate that sometimes they're useful, but like everything else in C++ there is a way to misuse them horribly and you will run across code bases that do it eventually.

I hate the syntax for lambdas in general, but not the concept of them. But the same is true for several things in C++, like functors.

Lambdas are compiler friendly. They reliably inline unlike standalone functions. It's not laziness, it's an optimization.

C# has inner (local) functions which are close in semantics to lambdas but have names. I didn’t think I’d use them at first, but actually I use them all the time and often prefer them to raw lambdas.

  #include <cstdio>
  int main() {
    auto square = [](double x) -> double { return x*x; };
    printf("%f\n", square(10));
    return 0;
  }

since 2011

> They reliably inline unlike standalone functions.

No. They don't. Non-constexpr ones can't. And lambdas with captures that outlive their creators are notoriously painful for compilers and libraries to support.

Yet, they do. Lambdas with captures are explicitly modeled as a struct holding the captured values, and a member function that takes its implicit "this".

That function, with its implementation fully exposed, is as easily inlined as any other. The struct is moved or copied as needed to keep it live after the originating context evaporates.

I stand corrected. OTOH, "functionally equivalent but makes debugging or verification harder" isn't actually a strong argument in favor of lambdas.

Fortunately they don't need a strong argument. Convenience and minimized boilerplate suffices.

100% agreed, except "5" should read "2"

Perhaps you may enjoy Python ;)

I'll disagree - a lambda should be very short indeed[0] else just define it as a standard func with a descriptive name[1]. And python's lambdas regrettably single expression only, no statements, which can really limit things.

[0] My opinion

[1] Exception is where you use lambdas for passing to new control flow structures. Something you can't do with python, although python does finally have a way to do the same thing (I think htis, though I'm a bit rusty so maybe something newer https://www.novixys.com/blog/proper-cleanup-resources-python...)

There's becoming a fashion to write fucking awful shite because it's functional so it must be written that way because it's good because it's functional. People need to get out of this habit now.

All awful shite is functional. All functional is good. So all awful shite is good?

I think that might be a tad reductive. Also, concluding that "people" must do anything now isn't useful. No one will be persuaded by your argument. People that are knowingly writing awful shite aren't bothered by that fact. People unknowningly writing awful shite will assume you're talking about other people.

IMO it's awful shite. Other people seem to think nesting lambdas n deep is not shite. I've worked with code like this - I've been lectured that "it's the functional way", but it isn't, it's just a mess. And often inefficient to boot.

You can write fine code functionally but for some reason this kind of horror is considered "the right way". Why? since when did people forget about writing for the human not the computer?

What is awful shite?

There's nothing about functional programming that requires nested lambdas. I like functional programming at least a little, but I don't like nested lambdas. If you want to know why someone considers it "right", you'd have to ask someone who considers it to be.

Strongly agree re: writing for humans. Actual computer architecture seems a lot closer to imperative with goto, so I'm not sure who would argue that functional code is "for computers".

> you'd have to ask someone who considers it to be [right]

I did say why - it's because it's "functional style" so it should be done that way. I've been told this to my face. Trouble is, it's plain wrong.

> so I'm not sure who would argue that functional code is "for computers".

Agreed. I should not have put that.

I don't think that's what they're saying - what I read (and experience sometimes...) is old C++ programmers that have only known imperative styles get access to functional techniques and don't see the problem sticking stream-lambda-filter-map "loops" within regular imperative for loops.

AKA quit giving C++ devs new obfuscation techniques...

Reply on news.ycombinator.com