An empirical study on the impact of C++ lambdas and programmer experience
1–10 of 112 posts
Re: An empirical study on the impact of C++ lambdas and programmer experience
#2Context always matters. I use lambdas sparingly in my applications, except for one major area: user interfaces.
I can't begin to stress what a huge timesaver it is being able to bind a button's callback to a quick lambda instead of having to bind a callback to an std::function, add the function to the class header, and then put the actual button-click code somewhere else in the project in a separate function ... and then repeat that process for a large UI with hundreds of widgets.
It's not even the initial extra typing, it's having all the code right where it's most relevant instead of scattered around everywhere and having to name all of these callback functions.
Re: An empirical study on the impact of C++ lambdas and programmer experience
#3> After instructions, participants were given printouts of sample code they could refer to while solving tasks. Group Lambda got code of a C++ program using lambda expressions and group Iterator received code of the same program written using iterators. They then had time to study the samples before starting the tasks and could refer to these samples later.
These samples do not appear in the paper, so we don't know what they saw.
The “iterators” discussed are Java-/C#-style iterators, not C++ ones (as I expected reading the abstract).
In a C++ context I would have expected lambdas vs iterators to be something like:
// lambda
float retVal = 0;
std::for_each(mb.cbegin(), mb.cend(), [&](item x) { retVal += item.price; });
return retVal;
// pure iterator
float retVal = 0;
for (auto it = mb.cbegin(); it != mb.cend(); ++it)
{
retVal += it->price;
}
return retVal;
return std::accumulate(mb.cbegin(), mb.cend(), 0f,
[](float acc, item x) { return acc + x.price; });
Re: An empirical study on the impact of C++ lambdas and programmer experience
#4I used to really like C++ ... back in 2000. That is before they added the kitchen sink into the language.
I prefer my computer languages to be like Chess - a few rules but efficient and expressive. Like C.
Why? Because everyone can read the code others on the team wrote, without being a language lawyer and knowing tons of esoteric features and magic.
That has implications for maintainability and team productivity, and the bottom line for a business.
Really, people, having basic coding style conventions instead of tons of language features wasn't so bad:
int Foo_bar(struct Foo* this) {
// even this is readable
}Re: An empirical study on the impact of C++ lambdas and programmer experience
#5Context always matters. I use lambdas sparingly in my applications, except for one major area: user interfaces. I can't begin to stress what a huge timesaver it is being able to bind a button's callback to a quick lambda instead of having to bind a callback to an std::function, add the function to the class header, and then put the actual button-click code somewhere else in the project in a separate function ... and…
[deleted]
Re: An empirical study on the impact of C++ lambdas and programmer experience
#6Submitter's editorialized title mischaracterizes the OP
> All the tasks focused on iteration on a collection using a C++ vector object.
That's comparing "functional style" collections to iteration.
It is readily apparent that C++ syntax is so troublesome that "functional collections" won't be a win for small iteration blocks.
We had the same debate for functional Java collection methods (although the Java 8 lambdas tilt it more closely in functional Java's favor)
The main use case for C++ lambdas is for declaring callbacks.
Re: An empirical study on the impact of C++ lambdas and programmer experience
#7The paper seems to mainly compare iterators vs lambdas. This seems like a bit of a strawman; the best use of lambdas is beyond iterators.
For example, consider callback heavy asynchronous code. A promise library with lambdas is much easier to write and read than the equivalent state machine.
I would go as far to say any mechanism where function chaining is useful, such as the nice data to mark/SVG abstraction used in D3, and also in promise libraries, has advantages with lambdas. Not only do you avoid having to write extra classes or methods, but the code is more succinctly logically grouped together, requiring fewer indirections to get to the transformations occurring.
Re: An empirical study on the impact of C++ lambdas and programmer experience
#8I used to really like C++ ... back in 2000. That is before they added the kitchen sink into the language. I prefer my computer languages to be like Chess - a few rules but efficient and expressive. Like C. Why? Because everyone can read the code others on the team wrote, without being a language lawyer and knowing tons of esoteric features and magic. That has implications for maintainability and team productivity, an…
Very few people can read and understand C without being a language lawyer an knowing tons of esoteric magic. There are many things in C which look perfectly reasonable but which actually result in undefined behavior, and you cannot reason about what a program will do in the presence of undefined behavior.
Re: An empirical study on the impact of C++ lambdas and programmer experience
#9I used to really like C++ ... back in 2000. That is before they added the kitchen sink into the language. I prefer my computer languages to be like Chess - a few rules but efficient and expressive. Like C. Why? Because everyone can read the code others on the team wrote, without being a language lawyer and knowing tons of esoteric features and magic. That has implications for maintainability and team productivity, an…
Very few people can read and understand C without being a language lawyer an knowing tons of esoteric magic. There are many things in C which look perfectly reasonable but which actually result in undefined behavior, and you cannot reason about what a program will do in the presence of undefined behavior.
But there is a difference between using C in crazy ways, and using 20 features of a language in ways that make them interact.
The more features a language has, the more I have to know just to read someone's code or be productive in a company - and the more chance someone doesn't know about potential harmful interactions and side effects.
Re: An empirical study on the impact of C++ lambdas and programmer experience
#10I used to really like C++ ... back in 2000. That is before they added the kitchen sink into the language. I prefer my computer languages to be like Chess - a few rules but efficient and expressive. Like C. Why? Because everyone can read the code others on the team wrote, without being a language lawyer and knowing tons of esoteric features and magic. That has implications for maintainability and team productivity, an…
Very few people can read and understand C without being a language lawyer an knowing tons of esoteric magic. There are many things in C which look perfectly reasonable but which actually result in undefined behavior, and you cannot reason about what a program will do in the presence of undefined behavior.
Further, C makes it impractically difficult to handle things that should be simple. Like, uh, errors and resource cleanup. The inability to have something as trivial as a scope guard that works as a human being would expect it to work will ensure that under no circumstances will I ever write a piece of C that anything I care about relies upon. I know I'm not good enough to write perfect C, and imperfect C is disastrous. (The fraction that is good enough to write perfect C is a vanishingly small proportion of those who think they do. And try to. And fail. And hurt other people in the process.)