5 ms·
The 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
by emcq 10y ago
The 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.
- alfalfasprout 10y agoBasically anywhere where you would have used a callback in C code could probably benefit from a C++ lambda. It's easier to see what's going on, you don't litter your code with hundreds (or thousands) of tiny functions, and the compiler can easily inline everything. The fact that you can capture whatever you need makes it super easy to use inside a class if needed (eg; you need to access class members). It seems really dumb to me to declare that lambdas are detrimental to novices when it's clear they have a great deal of utility outside of something like replacing iterators.
- eksemplar 10y agoI'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 training process longer.
- silasdavis 10y agoI'm glad I don't work for you...
- criddell 10y agoI think I understand why turnover is such an issue. The reluctance to invest in your people is a little baffling.
- deleted 10y ago[deleted]
- mickronome 10y agoIf you want solid code in C++ you (essentially) have to only hire people who are good at their job, or accept a long runway where lambdas would simply be taught instead of the inferior methods/patterns they are intended to replace. I have yet to see a C++ codebase which was good while not written by people who are essentially C++ experts, or through in-depth code reviews by such, for all code. I understand finding the talent may be hard, but then the C++ volume might need to be decreased and replaced by something less demanding, or the code will likely be anything but solid.
- hellofunk 10y agoThis is a rather shallow perspective on software engineering. You are basically saying you don't want your employees to use the language as it is designed, even when it provides tools to make code better.
- gjvc 10y ago> I need to be able to replace any developer with any developer on a moments notice. As unpleasant as it is, this is all too widespread, because it seems like common-sense on the surface. "A little knowledge (on the part of management) is a dangerous thing."
- 72deluxe 10y agoThis is amusing and I think (hope?) it's sarcasm. Interestingly, you can think of lambdas a small functions with single responsibility, which happen to be easy to find (they're inline right there in the code and you don't have to hunt around for them).
- rubber_duck 10y ago>A promise library with lambdas is much easier to write and read than the equivalent state machine. async/await makes this even easier, AFAIK C++ is getting it soon as well.