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

71–80 of 112 posts

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

#71

Post by TillE »

Fede_V wrote: post #47

Lambdas are an incredibly useful construct, and, once you master them, they do make a lot of programming tasks much easier. However, C++ lambdas picked the most horrifically ugly syntax possible, and they switch between three subtly different semantics (copy, reference, move) depending on a single glyph. I feel bad for the people working on modern C++ - maintaining backwards compatibility is a huge constraint upon de…

Serious question: how would you improve the syntax while maintaining their feature set (which is not huge, but includes a few important things)?

I understand that C++ lambda syntax can be confusing on first encounter, but after reading about them for five minutes it should be very naturally comprehensible to any experienced C++ programmer. It's terse, but very clear.

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

#73

Post by EGreg »

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…

Yes, RAII and exceptions (as well as a few other things like being able to declare variables anywhere) is the reason why I liked C++ in 2000 more than C.

But beyond that, it all went downhill. There was no reason to make C++ the most bloated language ever.

The same is true of Javascript etc. Newbies will not be able to start, now, because they will think about let/var/const the same way as in C++ they have to think about all the possible casts, copy constructor vs casting semantics etc.

Tell me this for example, does the following use a cast or a copy constructor?

http://stackoverflow.com/questions/11222076/why-is-copy-cons...

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

#74

Post by jeremiep »

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.

I see that mentality in every language, even if its worse in C++ because "close to metal" and "we know C++, therefore we must be good programmers".

What usually happens is that the code gets unreadable/unmaintainable quickly and is still a complete unoptimized mess at the macro level.

Once you realize this you don't need C++ for most application domains. And for the domains where C++ matters you also realize you'd be better off in C with a scripting language on top.

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

#75

Post by ahmedtd »

flohofwoe wrote: post #39

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

I'm pretty sure that most uses of lambda don't involve creation of std::function (and thus dynamic allocation and virtual function calls).

As long as you maintain the distinct type of the lambda, any captures (by reference or by value) will just be fields in a stack object.

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

#76

Post by jeremiep »

72deluxe wrote: post #64
alfalfasprout wrote: post #31

Earlier quoted context omitted.

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

Out of interest, I never learned C but went straight to C++. What in particular about C++ makes you believe that you'll write memory hogging programs?

I've seen a game engine built on shared_ptr that had trouble getting a 2D game performing well on the PS3.

Its not that C++ will bloat your program, its that many programmers don't understand the tradeoffs of the primitives they're using, or don't have the experience or vision to see what they become at scale.

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

#77

Post by asveikau »

duneroadrunner wrote: post #53
MaulingMonkey wrote: post #13

Earlier quoted context omitted.

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…

"Idiomatic" doesn't necessarily mean better. I think objectively it's hard to argue that "item != market.end()" is superior to "iter.hasNext()". The latter accurately reflects the programmer's intent, while the former specifies an unnecessarily specific (and poor) implementation of the intent. First of all, using something like "market.cend() != const_iter" instead is arguably better practice (imagine you unintention…

> I think objectively it's hard to argue that "item != market.end()" is superior to "iter.hasNext()"

Until you realize the purpose of the weird syntax in the former.

Namely: you can write algorithms where an iterator is a drop-in replacement for a simple loop through all items in an array via pointer arithmetic, if you write it to take a start and an end iterator as templates.

Plus said algorithm can take sub-ranges instead of requiring it to loop through all items.

I thought c++ iterators were very strange for many years until I understood this and other rationales.

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

#78

Post by JohnLeTigre »

There's a guy at work whose position is unclear to most. It's just that random guy.

Typically, on monday mornings and friday evenings, he's very loud and looking busy. This is an age-old trick to superficially keep your job.

Ever so often one would hear his odd sounding voice pierce through the office talking about some idiosyncratic evidence while looking proud of himself.

Truly, if this guy was a programmer (which I doubt), he would be using lambdas. See, lambdas might have a use after all...

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

#79

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

#80

Post by sidlls »

alfalfasprout wrote: post #31
pjmlp wrote: post #20

Earlier quoted context omitted.

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

Fear of premature optimization, fear of pointers, and fear of how computers work in general, yes.

Pointers should be used very sparingly, and much of the time in code I've seen they could have and should have been avoided. But it seems like we've come to some far extreme other side of that thought to the point where seeing a pointer instills an exaggerated fear of memory stomping, leaks, and a variety of other things. These are important concerns, but, like optimization, ought not make a person afraid of their use. Anybody who needs to do non-trivial programming at the systems level had better get over those fears and focus on learning how best to use the tools they need to, in my view.

Post reply on HN