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

21–30 of 112 posts

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

#21

Post by pcwalton »

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.

> But there is a difference between using C in crazy ways

Is signed arithmetic using C in crazy ways? Is shifting by an arbitrary value without checking to make sure that the number of bits is in the valid range of the type using C in crazy ways?

Undefined behavior is everywhere in C.

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

#22

Post by beagle3 »

eropple wrote: post #14
beagle3 wrote: post #12

Earlier quoted context omitted.

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 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 mileage obviously varies) is only that C code bases that I tend to use and meet (e.g. x264, ffmpeg/libav, the linux kernel, the Nim compiler) tend to be saner than C++ code bases that I tend to use and meet (e.g. libzmq, although that one improved dramatically since 4.0, and is now almost sane, boost, stl)

I admit that I have not yet met a C++11 codebase with lambdas - that might have restored sanity. But even if it does, it does not retroactively bestow that goodness on the millions of lines of code already out there.

I stress again - I am not passing judgement on the language, but about how it is used in practice, through my own sample set. If I work on a project in which I can dictate the exact subset, choose the people, etc, I might pick C++. But in most projects I'm involved in, the constraints are dictated in some way or the other that makes C at least as good a choice (and often better) than C++

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

#23

Post by pjmlp »

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.

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 to find out that the code was already broken from ANSI C point of view.

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

#24

Post by alfalfasprout »

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

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

#25

Post by [deleted] »

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…

[deleted]

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

#26

Post by [deleted] »

MaulingMonkey wrote: post #13
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 iterato…

[deleted]

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

#27

Post by GeneralMayhem »

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.

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

#28

Post by pjmlp »

eropple wrote: post #14
beagle3 wrote: post #12

Earlier quoted context omitted.

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

And we already could take advantage of many of those positive features with C++ARM.

Hence why I eventually did a Turbo Pascal -> C++ transition, with a very very short stop in C.

I was lucky that our technical school also had access to Turbo C++ 1.0 for MS-DOS on their software library. As I was not getting why should I downgrade myself from Turbo Pascal 6.0 into C.

Already in those days of "The C++ Report" and when "The C/C++ Users Journal" was still called "The C Users Journal", there were articles how to put C++ features to good use for increased safety.

And this is a major culture gap between C and C++, that I have observed since then, yes we also get the performance obsessed ones, but there are also the security minded ones.

I seldom see talks about how to increase type safety in C, their C99 security annex is a joke as it keeps pointers and size separated, and is so highly regarded that it was moved into optional in C11.

C++ community on the other hard improves the standard library to decrease the unsafe use cases, promotes guidelines and is trying to reduce the amount of UB use cases.

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

#29

Post by ryporter »

It's important to note that the negative impact documented in this study is in development time and whether the task is completed. It makes no claims about impacts on maintainability that show up later in the development process. It also does not measure the longer term impact on development time if a team starts using lambdas and gains experience over time.

I say this not to dismiss the study, which appears to be fairly well done and to provide interesting results. I'm simply saying that its results are not inconsistent with lambdas providing a net, long-term benefit if introduced to a development team at work.

Post reply on HN