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

31–40 of 112 posts

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

#31

Post by alfalfasprout »

pjmlp wrote: post #20
jonstewart wrote: post #17

Earlier quoted context omitted.

Of course students had problems—-it's one more damn thing for them to learn about C++, likely from professors that don't know it very well either. But is way more useful these days, and boost::asio is a dream.

Unfortunately most teachers aren't like Kate Gregory, and I fully agree with her, they should stop teaching C -> C++. Already in 1994 it was obvious to me that it leads to bad unsafe code and worse, the mentality to micro-benchmark each code line.

There's pitfalls to everything. I find that a lot of people that only learned C++ end up writing nice-looking safe code that's very well organized but has awful memory usage and dubious performance characteristics. It's not that they're bad programmers or made poor algorithmic choices. It's that they've been indoctrinated with the fear of "premature optimization". Moreover, they don't really know any better if they do have optimization opportunities.

On the flip-side, the C programmer who starts out learning C++ will often spit out some hideous abomination that uses no namespaces, consists of obscure function names, pointers everywhere, and tons of callbacks.

Thing is, sometimes performance really matters. A large part of the HN audience focuses only on web-oriented programming. But in scientific computing, finance, etc. being able to squeeze out a few more operations/CPU cycle can be incredibly important.

I think rather than being dogmatic about the issue, as programmers tend to do, it's important to introduce students to C but be very clear about why you might want to use some of its features vs. relying on the safer C++ variants.

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

#32

Post by _hao »

pjmlp wrote: post #20
jonstewart wrote: post #17

Earlier quoted context omitted.

Of course students had problems—-it's one more damn thing for them to learn about C++, likely from professors that don't know it very well either. But is way more useful these days, and boost::asio is a dream.

Unfortunately most teachers aren't like Kate Gregory, and I fully agree with her, they should stop teaching C -> C++. Already in 1994 it was obvious to me that it leads to bad unsafe code and worse, the mentality to micro-benchmark each code line.

In my university we started with C++ and pretty much everything was done in it (4 years). Although I've had C experience before that, I'd say that teaching C -> C++ to a complete beginner will be pretty hard on them and won't recommend it.

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

#33

Post by chj »

pjmlp wrote: post #23
EGreg wrote: post #9

Earlier quoted context omitted.

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.

Being a language geek with major in compiler design and systems programming, I tend to be a bit language lawyer. I seldom meet C developers that are able to distinguish between ANSI C and my compiler's C, that extrapolate from my compiler's C version Y, how the language should behave. Then they port the code to my compiler's C version Y + 1, or another compiler vendor, their code gets broken, blame the compiler, only…

So is your compiler ANSI C or not? c89 or c99?

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

#34

Post by noobermin »

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.

To be fair, the most fervent disciples of the Church of Haskell would use Haskell I'd think :)

I only scanned the paper, but I get the impression the title was chosen specifically to grab attention. "An empirical study comparing the use of C++ lambdas versus C++ STL iterators and programmer experience" wouldn't get eyes on their presentation, and eventually, being posted to HN...well, it would, but they'll surely get more reads/downloads this way.

Clickbaiting for conference proceedings, who would have known.

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

#35

Post by EllipticCurve »

beagle3 wrote: post #22
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…

"shackle" was a bad choice of word, I agree. I meant to say that you might be disciplined enough to never use anything except RAII, but most (users/libraries) aren't. > If so, you're that one percent. I probably am that one percent (and I don't use sprintf, because there is no sane way to use it). When I say people use C "sanely", I do not mean that they never err in any way, far from it. And my observation (your mil…

I completely agree and would, most of the time, choose C over C++!

Except, that I have seen C++11 codebases that heavily relied on lambdas. And that was far from sane. I am very familiar with lambdas from pure functional languages and partially ones (python, ...). But all the syntax specifics, brackets, ... in C++ made it a very annoying process to understand, what was even going on at all.

Using short functions would be more lines of code. But at least I would have known right away what's happening in the code.

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

#36

Post by ThePhysicist »

Recently I wrote a parser generator, which would take a rule structure and return a function that does the parsing. Lambdas were very useful here, and I do not know how I would've implemented this without them, at least in an efficient manner, because they let me do something like this:

    Parser ParserGenerator::compileLiteral(Rule& rule){

        const string literal = rule.value;

        Parser parser = [literal] (shared_ptr state){
           //parse the literal...
           state.Advance(literal.size())
           return state;
       }

       return parser
    }
Solving this without lambdas would require a different encapsulation mechanism for the rule data, such as a class, which (IMHO) would make the code less idiomatic.

So lambdas are actually very useful!

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

#37

Post by badminton1 »

Some people feel comfortable expressing things in a more traditional way, in part, because you cannot change the habits built over the course of decades by just announcing a new standard.

After the standard including lambdas came out, compilers did not immediately comply to it, and it took some time for them to catch up. Then it took even more time for tutorials and books to catch up. And it will take time for the C++ community as a whole to catch up as well.

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

#38

Post by jytqtrrrrr »

noobermin wrote: post #34
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.

To be fair, the most fervent disciples of the Church of Haskell would use Haskell I'd think :) I only scanned the paper, but I get the impression the title was chosen specifically to grab attention. "An empirical study comparing the use of C++ lambdas versus C++ STL iterators and programmer experience" wouldn't get eyes on their presentation, and eventually, being posted to HN...well, it would, but they'll surely get…

Such a title wouldn't be right, either. Their poor iterators don't seem to act like real iterators.

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

#39

Post by flohofwoe »

Title of the research paper should be "C++ is not Haskell", but snark aside, I find C++11 lambdas useful to replace old-school callback code (of course only if callbacks make sense in a situation) because:

- if local variables need to be captured, the code is much less noisy than using the old std::bind mess

- non-capturing lambdas also work for C-style function pointers, and in this case the generated code is very efficient (no std::function object created under the hood)

If you're aware what happens under the hood (...that in most cases a std::function object will be created, which in turn might do a dynamic memory allocation to hold captured variables), lambdas are a useful syntactic sugar and one of the more useful additions in C++11 (IMHO).

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

#40

Post by eksemplar »

alfalfasprout wrote: post #24
emcq wrote: post #7

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…

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 reall…

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.

Post reply on HN