[emcq]

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]

Basically 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]

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 training process longer.

[mickronome]

If 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]

This 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.

[silasdavis]

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

[criddell]

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

[gjvc]

> 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]

This 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]

>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.