Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++: The Documentary

herbsutter.com

Post reply on HN
Print view View original

81–90 of 334 posts

Re: C++: The Documentary

#81

Post by avadodin »

whstl wrote: post #71
bayindirh wrote: post #13

Earlier quoted context omitted.

Personally I don't find programming with C++ that hard. The downside is it needs a brain warm-up, and this is per project, but once that flywheel is spinning, I find it almost effortless to write code. I have to go through the same warm-up more or less for any language I work with, so it's not that different than writing Python, Go or Java for me.

I find C++ not hard at all when working with familiar idioms, restrictions and toolings (familiar to me). But it's hard jumping into new codebases and adjusting yourself to new patterns. Recently I did a lot of programming using C++23 Modules and it was a breeze. There's basically dozens of very nice languages inside C++. That can be a blessing or a curse. I'm anxious for Herb Sutter's CPP2/CPPFront to become a stand…

Looked up what C++23 Modules were and I must say I was not let down.

Re: C++: The Documentary

#83

Post by zabzonk »

flohofwoe wrote: post #43
Chaosvex wrote: post #36

Earlier quoted context omitted.

Grossly exaggerated or misunderstood in many cases. Some of their arguments are just flat-out wrong. I mean, why are they blaming the standard library for inherent properties of linked lists? Yeah, you don't want to use them without good reason. That's just called picking the right data structure for the job, not a flaw with the standard library. Some of the other choices were tradeoffs between performance and usabil…

As I understood the article, the main critique is that the stdlib has no concept of deprecation and breaking backward compatibility. E.g. the C++ committee is quick to add badly designed features to the stdlib but then can't roll them back when people actually realize that those new features are useless for most real-world code.

Badly designed things get replaced. For example unique_ptr replaced auto_ptr. I'm not sure if the language standard actually supports the term "deprecation" though.

Edit: Also not sure what can possibly be downvoted here.

Re: C++: The Documentary

#84

Post by domenicd »

flohofwoe wrote: post #43
Chaosvex wrote: post #36

Earlier quoted context omitted.

Grossly exaggerated or misunderstood in many cases. Some of their arguments are just flat-out wrong. I mean, why are they blaming the standard library for inherent properties of linked lists? Yeah, you don't want to use them without good reason. That's just called picking the right data structure for the job, not a flaw with the standard library. Some of the other choices were tradeoffs between performance and usabil…

As I understood the article, the main critique is that the stdlib has no concept of deprecation and breaking backward compatibility. E.g. the C++ committee is quick to add badly designed features to the stdlib but then can't roll them back when people actually realize that those new features are useless for most real-world code.

I'm not sure this is a winnable game for programming languages.

- Keep a small stdlib, like JavaScript (especially earlier JavaScript): everyone complains about missing features, warring communities form around jQuery promises vs. Promises/A+ vs. callbacks, supply chain attacks, left-pad/is-even dependencies, etc.

- Grow a big stdlib while keeping backward compatibility, like C++: lots of cruft left around that must never be used, sitting next to newer stuff with similar names. People complain about the bloat.

- Grow a big stdlib and then break backward compatibility, like Python 2 -> 3: everyone is sad, the ecosystem churns for years.

I admit there are probably better and worse versions of each strategy, e.g., it seems to me like JavaScript's slow-but-steady accretion of primitives over time has gone OK, and it seems like apart from Python 2 -> 3 some of the PEPs I see for deprecations and replacements are reasonable. But no language has ever hit on a strategy that everyone loves, as far as I can tell.

Re: C++: The Documentary

#85

Post by tialaramex »

whstl wrote: post #71
bayindirh wrote: post #13

Earlier quoted context omitted.

Personally I don't find programming with C++ that hard. The downside is it needs a brain warm-up, and this is per project, but once that flywheel is spinning, I find it almost effortless to write code. I have to go through the same warm-up more or less for any language I work with, so it's not that different than writing Python, Go or Java for me.

I find C++ not hard at all when working with familiar idioms, restrictions and toolings (familiar to me). But it's hard jumping into new codebases and adjusting yourself to new patterns. Recently I did a lot of programming using C++23 Modules and it was a breeze. There's basically dozens of very nice languages inside C++. That can be a blessing or a curse. I'm anxious for Herb Sutter's CPP2/CPPFront to become a stand…

In February this year Herb tweaked a test case. That was his last commit to his "CPP2 syntax experiment". Don't expect it to "become a standard".

https://github.com/hsutter/cppfront/commits/main/

Re: C++: The Documentary

#86

Post by tonyedgecombe »

zeafoamrun wrote: post #7
bdamm wrote: post #2

Since I've been working in C++ a lot recently I decided to watch the video as I waited for a build to complete. So the length is about right. And fortunately, the video is a delight!

I have read as much as I can on the history of C++ and I'm looking forward to watch this. I find the process of it's evolution deeply fascinating.

I feel drawn to watch it in the same way I was drawn to watch Breaking Bad.

Re: C++: The Documentary

#87

Post by tonyedgecombe »

i_am_a_peasant wrote: post #42

My only problem with C++ is that it’s too verbose. my eyes need to parse huuge chunks of things when I just want some convenient syntax for it. otherwise the idioms are pretty universal for most programming languages nowadays.

The trouble with that is the more mental capacity you exert on the language the less you have available for the task at hand.

Re: C++: The Documentary

#88

Post by tenderfault »

W0lf wrote: post #70
tenderfault wrote: post #60

So happy to see Andrei Alexandrescu was included in this documentary. His book on modern C++ design was a mind opener at the time I read it. Maybe still is today. Anybody else read it?

Yes, I feel the same way. I met Andrei once on a Meetup in Munich, basically telling him that he taught me how to think which led to a somewhat awkward conversion. Fun times nonetheless :-)

1. Find your hero

2. Meet your hero

3. Start an awkward conversation with your hero.

It always goes like this no matter what you try.

Re: C++: The Documentary

#89

Post by GodelNumbering »

Personal opinion: C++ is the most elegant language I have used (for about 15 years). If you are the 'systemizer' type and like to have an extremely precise mental model of the thing you write down to the last bit, nothing beats C++. I acknowledge the limitations and uncertainties that come from compilers etc, but still

Re: C++: The Documentary

#90

Post by spacechild1 »

mixolydianagain wrote: post #54
samiv wrote: post #31

Earlier quoted context omitted.

If you don't use the STL you end up re-implementing it yourself. Usually poorly.

some of the STL is easy to improve on. For example, std::unordered_map performs poorly due to pointer stability requirements in the standard. Most performance sensitive C++ codebases will use something like abseil's hash maps instead.

Just a heads-up: if you're already using boost, boost::unordered now has open addressing containers (unordered_flat_map and unordered_flat_map) and they are among the fastest.
Post reply on HN