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

11–20 of 112 posts

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

#11

Post by eropple »

EGreg wrote: post #9
lambda wrote: post #8

Earlier quoted context omitted.

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.

> there is a difference between using C in crazy ways

As per my sibling, write me something as straightforward as a C++ RAII-using dtor in C without "using C in crazy ways". I will not hold my breath. The cost of a very minimal subset of C++ is literally zero, and yet significantly improves the likelihood of your code actually working. You're picking social baggage in either case: either understanding the subset of C++ that your team is using or expecting all of your developers to be perfect where C++ (and other languages--shouts, Rust!) just do it for you, correctly.

Technology is socially interesting in that incompleteness and inexpressivity is so often misread as "elegance" or "minimalism". That a language is "simple" is not a feature when it offloads all of the danger onto the (almost invariably failing to consider critical information at the worst possible time, and I include myself at the forefront of that characterization!) developer. This is why we have tools that compensate for the most common, and most destructive, of our mistakes.

(This post should not be construed as any particular endorsement of C++. C++ is a gong show when used improperly. But at least it's possible for a mere mortal to use it properly.)

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

#12

Post by beagle3 »

eropple wrote: post #11
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.

> there is a difference between using C in crazy ways As per my sibling, write me something as straightforward as a C++ RAII-using dtor in C without "using C in crazy ways". I will not hold my breath. The cost of a very minimal subset of C++ is literally zero , and yet significantly improves the likelihood of your code actually working. You're picking social baggage in either case: either understanding the subset of…

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 experience, it isn't what the language provides, it is how it is used in practice - and again from my experience (YMMV), C is used sanely and C++ is not.

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

#13

Post by MaulingMonkey »

porges wrote: post #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 w…

Yeah - from what I can see, neither interface looks like idiomatic C++.

EDIT: Looks like you beat me to the punch on some of these ;)

Instead of:

  float getSum(marketBasket mb) {
    float retVal = 0;
    // Implement solution here
    // ---------
    marketBasket::iterator iter = mb.begin();
    while (iter.hasNext()) {
      retVal += iter.get().price;
      iter.next();
    }
    // ---------
    return retVal;
  }
I'd rather see real SC++L compatible iterators (as hopefully taught) and saner naming:

  float getSum(marketBasket market) {
    float sum = 0;
    // Implement solution here
    // ---------
    for (marketBasket::iterator item = market.begin(); item != market.end(); ++item) {
      sum += item->price;
    }
    // ---------
    return sum;
  }
And instead of being pre-provided with a function , if I'm reading the pdf correctly:

  float getSum(marketBasket mb) {
    float retVal = 0;
    // Implement solution here
    // ---------
    function  func = [&](item theItem) {
      retVal += theItem.price;
    };
    mb.iterateOverItems(func);
    // ---------
    return retVal;
  }
I'd rather see:

  float getSum(marketBasket market) {
    float sum = 0;
    // Implement solution here
    // ---------
    market.for_each([&](item theItem) {
      sum += theItem.price;
    });
    // ---------
    return sum;
  }
Or venturing into the far more functional style, where lambdas start to shine for me, personally:

  float getSum(std::vector market) {
    // Implement solution here
    // ---------
    return std::accumulate(market.begin(), market.end(), 0.0f, [&](float sum, item theItem) {
      return sum + theItem.price;
    });
    // ---------
  }
It looks a bit better in C# where your selection of standard functions is a little less anemic and a little nicer to use:

  float GetSum(MarketBasket market) {
    // Implement solution here
    // ---------
    return market.Sum(item => item.Price);
    // ---------
  }

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

#14

Post by eropple »

beagle3 wrote: post #12
eropple wrote: post #11

Earlier quoted context omitted.

> there is a difference between using C in crazy ways As per my sibling, write me something as straightforward as a C++ RAII-using dtor in C without "using C in crazy ways". I will not hold my breath. The cost of a very minimal subset of C++ is literally zero , and yet significantly improves the likelihood of your code actually working. You're picking social baggage in either case: either understanding the subset of…

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 walkways over a pit of fulminating acid is just the worst.)

The idea that people use C "sanely" more often than C++ (or, you know, something actually good--further shouts, Rust!) doesn't pass the smell test. Are you checking the retval of every sprintf? Are you writing goto drops in every method where there's allocated memory, diligently checking every error code, and properly bailing out, every time? If so, you're that one percent. But you're probably not. And that's not a slight--I'm not, either. That's why I am proud to count myself as a member of a tool-using species, because we build (and have built) better tools to compensate for our flaws.

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

#15

Post by nice_byte »

I'm a professional and you can take the lambdas out of my cold, dead hands.

Also, their examples are removed from reality. I've never seen people use lambdas like that. Most of the use cases I've seen are callbacks that get triggered on certain events (i.e. "display notification when background loading thread completes") and predicates (i.e. find_if). I see neither in their examples.

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

#16

Post by marklgr »

EGreg wrote: post #9
lambda wrote: post #8

Earlier quoted context omitted.

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.

In my experience, some people are too much attached to that good feeling of knowing "all there is to know" about something; this has the taste of proficiency, but the very real risk is to prefer the small pond because of that, calling the sea "overextended".

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

#17

Post by jonstewart »

nice_byte wrote: post #15

I'm a professional and you can take the lambdas out of my cold, dead hands. Also, their examples are removed from reality. I've never seen people use lambdas like that. Most of the use cases I've seen are callbacks that get triggered on certain events (i.e. "display notification when background loading thread completes") and predicates (i.e. find_if). I see neither in their examples.

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.

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

#18

Post by spacelizard »

byuu wrote: post #2

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

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 been using them since C++11 was released and still forget the capture list syntax sometime), it's not much more than an academic exercise to take some iterator-based code and replace it with higher-order function calls. It's unfortunate that all the tasks seem to be based around doing that though. I do think it is still reasonable to do this in C++11 once you know how - with -O1 turned on you can get basically the same code spit out using std::transform, std::accumulate, std::for_each, et al, as you would using a for loop.

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. Lambdas typically end up being faster in both compile-time and run-time, and end up generating less code. For these reasons I've found myself using them a lot more, especially anywhere I would have done some type of currying. This I do miss somewhat, but it's still leaps and bounds ahead of something I would have written in C++03.

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

#19

Post by Karliss »

porges wrote: post #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 w…

First two tests used lambda with custom for each method. If authors used real c++ iterators and for each loop it would become obvious that comparing iterators and lambdas at iterating is the same as comparing lambdas with if statements at being if statements.

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

#20

Post by pjmlp »

jonstewart wrote: post #17
nice_byte wrote: post #15

I'm a professional and you can take the lambdas out of my cold, dead hands. Also, their examples are removed from reality. I've never seen people use lambdas like that. Most of the use cases I've seen are callbacks that get triggered on certain events (i.e. "display notification when background loading thread completes") and predicates (i.e. find_if). I see neither in their examples.

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.

Post reply on HN