5 ms·
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
by muststopmyths 6y ago
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 ?
- throwaway_pdp09 6y agoThere'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.
- recursive 6y agoAll 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.
- throwaway_pdp09 6y agoIMO 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?
- recursive 6y agoWhat 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".
- throwaway_pdp09 6y ago> 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.
- verall 6y agoI 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...
- deleted 6y ago[deleted]
- RcouF1uZ4gsC 6y agoFor 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.
- PaulDavisThe1st 6y ago100% agreed, except "5" should read "2"
- saagarjha 6y agoPerhaps you may enjoy Python ;)
- throwaway_pdp09 6y agoI'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-using-statement/ https://www.novixys.com/blog/proper-cleanup-resources-python...)
- zelly 6y agoLambdas are compiler friendly. They reliably inline unlike standalone functions. It's not laziness, it's an optimization.
- moomin 6y agoC# 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.
- zelly 6y ago#include <cstdio> int main() { auto square = [](double x) -> double { return x*x; }; printf("%f\n", square(10)); return 0; } since 2011
- notacoward 6y ago> 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.
- ncmncm 6y agoYet, 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.
- notacoward 6y agoI stand corrected. OTOH, "functionally equivalent but makes debugging or verification harder" isn't actually a strong argument in favor of lambdas.
- 6y ago
- pkaye 6y agoDo you hate the C++ syntax for lambdas or the concept of lambdas?
- muststopmyths 6y agoThe 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.
- tolbish 6y agoI 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.
- notacoward 6y agoI 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.