Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An empirical study on the impact of C++ lambdas and programmer experience

dl.acm.org

Post reply on HN
Print view View original

91–100 of 112 posts

Re: An empirical study on the impact of C++ lambdas and programmer experience

#91

Post by duneroadrunner »

duneroadrunner wrote: post #69
lorenzhs wrote: post #56

Earlier quoted context omitted.

> But programmers shouldn't need to consider whether the iterator is const or not when they just want to know if the loop is done. and they don't: http://en.cppreference.com/w/cpp/container/vector/end - there's an overload returning a const_iterator. You don't need to use 'cend'. And since insertion and deletion potentially invalidate iterators, 'hasNext()' is just as bad.

Yeah, maybe I didn't think the const thing through. I guess I was thinking that the benefit of using cend() is the double-check to make sure the iterator was declared as a const_iterator (when appropriate). But using "hasNext()", just like using "end()", you would lose the double-check. Perhaps I could instead claim that "item != market.end()" redundantly specifies the vector, "market", and thus presents an unnecessa…

Sorry never mind, in that last scenario it's the "y_iter++" that will be the first invalid operation.

Re: An empirical study on the impact of C++ lambdas and programmer experience

#92

Post by eco »

As a working C++ programmer for over a decade this conclusion is absolute insanity to me. People (myself included) are actually using the STL algorithms now because you no longer have to go through the pain of writing a functor. Every time I can avoid writing a for loop I'm a little happier (and my code is a lot more readable).

When lambdas first came about there was a lot of "meh, I could already write a functor just fine" but the ease of using them is just so much nicer and the readability of the code is so much greater. Just writing a plain for loop would often be less code than using an STL algorithm and a custom functor so there was very little incentive to use the highly tuned STL algorithms if it was just going to take more boilerplate. Now there is and we are finally seeing C++ programmers catching up to the insights that functional programmers had made a long time ago[1]

Others have said this but comparing lambdas to iterators is a very odd decision because they are completely unrelated things.

The conclusion should really be that anonymous functions aren't as intuitive as "regular" imperative code. The regular code walks you through what is going on in babysteps so even a new user can figure out what is going on. The way with lambdas requires a bit more knowledge but for working programmers who aren't learning C++ for the first time they are obviously a big boon. Sometimes you have to learn something slightly more complex to reap the benefits of it. Pointers are very hard for brand new programmers to wrap their heads around but nobody would argue that judicious use of them can be a real benefit (or essential, even) in some situations. This is like concluding that smart pointers are bad because they are less explicit about what is going on. You still need to learn C++ manual memory management but your code will clearly benefit (both in terms of verbosity and memory safety) by using smart pointers 95% of the time.

1. CppCon 2016: Ben Deane "std::accumulate: Exploring an Algorithmic Empire" https://www.youtube.com/watch?v=B6twozNPUoA (std::accumulate, fold essentially, has been in C++'s STL since the beginning and Stepanov probably had it in mind before C++ even existed but we are just now getting lectures like this and I think lambdas are to thank for this)

Re: An empirical study on the impact of C++ lambdas and programmer experience

#93

Post by EGreg »

eropple wrote: post #85
EGreg wrote: post #73

Earlier quoted context omitted.

Yes, RAII and exceptions (as well as a few other things like being able to declare variables anywhere) is the reason why I liked C++ in 2000 more than C. But beyond that, it all went downhill. There was no reason to make C++ the most bloated language ever. The same is true of Javascript etc. Newbies will not be able to start, now, because they will think about let/var/const the same way as in C++ they have to think a…

"C++ has optional and complicated things that incur costs only when you use them, so let's not even have dtors" is...not a good look, I think.

Gotta love those non virtual destructors which only clean up the base class. And the ambiguity about whether you're going to call a type conversion operator or a copy constructor when assigning A a = b.

Because you know, it's all super clear.

Re: An empirical study on the impact of C++ lambdas and programmer experience

#94

Post by eropple »

EGreg wrote: post #93
eropple wrote: post #85

Earlier quoted context omitted.

"C++ has optional and complicated things that incur costs only when you use them, so let's not even have dtors" is...not a good look, I think.

Gotta love those non virtual destructors which only clean up the base class. And the ambiguity about whether you're going to call a type conversion operator or a copy constructor when assigning A a = b. Because you know, it's all super clear.

Who said anything about inheritance? Like, at all? That is yet another feature you pay for only when you adopt it. You can pick one of two problems: you can agree upon a subset of C++ to use or you can expect your C developers to be perfect all of the time (while having fewer, if any, ways to express correctness). Dragging out additional things that are not part of your subset of C++ doesn't help formulate an argument against this.

Re: An empirical study on the impact of C++ lambdas and programmer experience

#95

Post by swift »

GeneralMayhem wrote: post #27

This is ridiculous. C++ lambdas (and std::function) don't replace iterators except for the most fervent disciples of the Church of Haskell. They replace single-function interfaces in cases where you would have had to put together a custom struct that did exactly the same thing as a lambda with capture but in about 15 more lines.

I'm not so sure. Generally implementing an iterator when the iteration doesn't represent a straightforward walk over the elements of a collection is much more error-prone. The implementation of the lambda version looks exactly the same as if you were just performing the iteration locally, while the iterator version requires saving and restoring a bunch of state and handling more edge cases. At call sites, the iterator version looks a little better, but not so much so that I'd consider the additional implementation complexity (and hence potential for bugs) worth it. That said, this is definitely a controversial opinion and there are arguments in the other direction as well.

Re: An empirical study on the impact of C++ lambdas and programmer experience

#96

Post by ambrop7 »

byuu wrote: post #57
spacelizard wrote: post #18

Earlier quoted context omitted.

Yeah I think this is the real win - the examples in the paper don't really cover any of the real reasons why someone would use functional programming. The places that I've used C++ lambdas a lot are callback-heavy code, i.e. things with a lot of asynchronous I/O, multi-threading, etc. While I don't doubt the validity of the argument that it takes longer for a programmer to write correct lambda code in C++ (I have bee…

> It's also unfortunate to note that, at least in g++ and clang, there is still significant advantage to using lambdas over std::function and std::bind. I have to say, std::bind is just a travesty. It's so difficult to bind a member function pointer that takes multiple arguments to an std::function. I wrote my own so that you can do this with just: function f = {&Class::func, &object}; Source is here: http://hastebin…

I've also written my own "version" of function but intentionally lightweight, for an embedded project: https://github.com/ambrop72/aprinter/blob/master/aprinter/ba...

Callback f = APRINTER_CB_OBJFUNC(&ThisClass::function, this);

One magic thing is that the macro is just a value, it figures out the type itself.

There's zero memory allocation. The Callback class just contains a function pointer and a void pointer. So you can't bind argument values other than the object pointer, but I have no need for that.

Re: An empirical study on the impact of C++ lambdas and programmer experience

#97

Post by criddell »

silasdavis wrote: post #46
eksemplar wrote: post #40

Earlier quoted context omitted.

I'd much rather have a lot of smaller functions with single responsibilities, but then being middle management I worry about things I didn't when developing. I need the code to be SOLID, I need the time to market to be as small as possible and I need to be able to replace any developer with any developer on a moments notice. When students don't know lambdas you're costing me money by using them, because you made the…

I'm glad I don't work for you...

I think I understand why turnover is such an issue. The reluctance to invest in your people is a little baffling.

Re: An empirical study on the impact of C++ lambdas and programmer experience

#98

Post by EGreg »

eropple wrote: post #14
beagle3 wrote: post #12

Earlier quoted context omitted.

The reason I dislike C++ (since about the 2000 as well) is that while it is possible to shackle yourself to only using C++ RAII etc, the vast majority of code in the wild (and in libraries, etc) does not. It does 90%, but that doesn't get you 90% of the benefit (maybe 50%, maybe 0%, depending on your point of view). You can do essentially all the "C in crazy ways" in C++ as well, and people do. In my opinion and expe…

I think the profusion of use-after-free bugs and memory leaks in C code running all over the place should put the lie to this. And, further, modern C++ allows you to firewall off the damage of bad C++ and most C, when you are forced to interact with it, via unique_ptr and your own enforced RAII. (And the idea that using this is so pejoratively "shackling" is bonkers to me; being "shackled" to the use of railings on w…

So that's easy:

  #define NEW(t, args...) ((t*)malloc(sizeof(t)) && t ## _construct(args))

  #define DELETE(t) (t ## _destruct() && !free(t) && (t = NULL))

Re: An empirical study on the impact of C++ lambdas and programmer experience

#99

Post by EGreg »

eropple wrote: post #94
EGreg wrote: post #93

Earlier quoted context omitted.

Gotta love those non virtual destructors which only clean up the base class. And the ambiguity about whether you're going to call a type conversion operator or a copy constructor when assigning A a = b. Because you know, it's all super clear.

Who said anything about inheritance? Like, at all? That is yet another feature you pay for only when you adopt it. You can pick one of two problems: you can agree upon a subset of C++ to use or you can expect your C developers to be perfect all of the time (while having fewer, if any, ways to express correctness). Dragging out additional things that are not part of your subset of C++ doesn't help formulate an argumen…

I agree about C needing memory management and exceptions. That's why I said I liked C++ when that's all there was. Classes were nice sumyntactic sugar.

But the language jumped the shark starting with C++0x

Re: An empirical study on the impact of C++ lambdas and programmer experience

#100

Post by eropple »

EGreg wrote: post #98
eropple wrote: post #14

Earlier quoted context omitted.

I think the profusion of use-after-free bugs and memory leaks in C code running all over the place should put the lie to this. And, further, modern C++ allows you to firewall off the damage of bad C++ and most C, when you are forced to interact with it, via unique_ptr and your own enforced RAII. (And the idea that using this is so pejoratively "shackling" is bonkers to me; being "shackled" to the use of railings on w…

So that's easy: #define NEW(t, args...) ((t*)malloc(sizeof(t)) && t ## _construct(args)) #define DELETE(t) (t ## _destruct() && !free(t) && (t = NULL))

This isn't sufficient unless you consciously error-check and goto-trap every single failure point in your code. Which you might do. But you'd be the literal one percent. If not the literal one permille.
Post reply on HN