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

201–210 of 334 posts

Re: C++: The Documentary

#201

Post by foobar1274278 »

mirmor23 wrote: post #144

Ken Thompson's criticism of C++ as incoherent, complex and garbage heap of ideas still resonates with me; C++98 was the last version I used for work although I've dabbled in 11/17/20 out of curiosity. IMO, if c++/cfront didn't ride on the tails of c, I'm skeptical it would've seen widespread use, but then, that's its main identity which limited it in ways that C++ was not willing to change; It is highly irritating to…

Hilarious coming from the guy whose shitty Multics ripoff directly inspired "Worse is Better"

From the essay:

"Unix and C are the ultimate computer viruses.

A further benefit of the worse-is-better philosophy is that the programmer is conditioned to sacrifice some safety, convenience, and hassle to get good performance and modest resource use. Programs written using the New Jersey approach will work well both in small machines and large ones, and the code will be portable because it is written on top of a virus.

It is important to remember that the initial virus has to be basically good. If so, the viral spread is assured as long as it is portable. Once the virus has spread, there will be pressure to improve it, possibly by increasing its functionality closer to 90%, but users have already been conditioned to accept worse than the right thing. Therefore, the worse-is-better software first will gain acceptance, second will condition its users to expect less, and third will be improved to a point that is almost the right thing. In concrete terms, even though Lisp compilers in 1987 were about as good as C compilers, there are many more compiler experts who want to make C compilers better than want to make Lisp compilers better.

The good news is that in 1995 we will have a good operating system and programming language; the bad news is that they will be Unix and C++."

https://dreamsongs.com/RiseOfWorseIsBetter.html

Re: C++: The Documentary

#202

Post by marcosdumay »

pjmlp wrote: post #72
jdw64 wrote: post #11

It's surprising that C++'s development trend continues. When a game or program is made with C++, it's usually nice because performance is mostly guaranteed. But if someone told me to write C++ myself, I'd cry. There's too much to memorize, and the standards are too varied. When I go to a project site for maintenance and it's a C++ project, I instantly lose energy — because it's just too difficult. I'd be happy if som…

Not really, despite all its warts, it is exactly because of them that many reach out to C++. Many of us don't like C, it was already too little and too unsafe, when the first C++ compilers started to hit the market in early 1990's, hence why all desktop OSes moved into C++ for their frameworks. The return to C has caused by the rise of FOSS, UNIX winning the server room, and early GNU coding standards to use only C a…

The return to C was caused by other languages taking over every niche where C++ is better suited than C.

There isn't even much of a "return" there. In fact, AFAIK, C++ expanded over C the entire time.

Re: C++: The Documentary

#203

Post by bluGill »

Maxatar wrote: post #185
bluGill wrote: post #173

Earlier quoted context omitted.

CMake says they are there. Other tools mostly are not. Nobody has said they are using them in anything important, but hopefully that is coming.

CMake has support for named modules but does not support header units or C++23 module features such as import std;

Import std has been there for a while but is experimental until gcc supports it. Gcc just for that support so it should be mainline soon.

Re: C++: The Documentary

#204

Post by jmalicki »

72deluxe wrote: post #156
mirmor23 wrote: post #144

Ken Thompson's criticism of C++ as incoherent, complex and garbage heap of ideas still resonates with me; C++98 was the last version I used for work although I've dabbled in 11/17/20 out of curiosity. IMO, if c++/cfront didn't ride on the tails of c, I'm skeptical it would've seen widespread use, but then, that's its main identity which limited it in ways that C++ was not willing to change; It is highly irritating to…

But C++98 is so different to even C++11. Bjarne's book covering C++11 read completely differently to the 98 version, I found.

That just adds to the incoherency.

It's why I've found Rust a joy - enough had happened in programming languages, that it was able to reinvent C++ with some of the best parts of the Haskell/ML/Scala family, some of the ergonomics of Python/nodejs, and bringing the borrow checker too.

C++ is this weird amalgam of like 7 different generations of languages.

But by far the worst part is the developer hostility behind the idea of UB. "Oh, this is not an error, it will compile, we will just secretly stab you in the back."

You can get good and avoid it, and there are tools to help you, but why is that at all a reasonable stance for the definition of a language?

Re: C++: The Documentary

#205

Post by wavemode »

stackghost wrote: post #195
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!

Wow is this just a shitpost (it was funny!) or do your builds actually take about an hour? That's nuts, if so.

A fresh build of a large C++ project taking 1 hour does not sound strange at all.

If that's an incremental build though (i.e. simply rebuilding after changing a few files), there's something very wrong.

Re: C++: The Documentary

#206

Post by marcosdumay »

imtringued wrote: post #112
DesaiAshu wrote: post #33

Earlier quoted context omitted.

A few reasons: 1. Header files make C++ verbose. Header files are well within LLM's ability 2. LLMs can handle setting up cmake for you 3. C++ is very well documented relative to (most) newer languages 4. LLMs can port modern features like websockets and build API wrappers easily, reducing the disadvantage against web (since most documentation is for JS/python/go) Coding languages have been developing for speed of (m…

All of those seem like barriers that make C++ unappealing in general, but you're deciding to overcome the barriers using an LLM and seeing that as a strength somehow?

That's like every application of LLM-coding I have ever seen people talking about.

Re: C++: The Documentary

#207

Post by wavemode »

GnarfGnarf wrote: post #104
herr_shield wrote: post #57

Earlier quoted context omitted.

I fully agree. In my personal project, I ended up using the STL to get off the ground, but in the end I replaced pretty much everything with custom-written code. Once you get rid of the STL, compile times get so much better. With modern c++23 features, templates actually become really convenient to write, and at the core there is a really useful and pleasant to use language. I try to avoid c++ libraries and instead r…

What, you rewrote std::deque? Whew!

Deque is one of the easier ones.

I echo the parent commenter - the STL has a massive negative impact on compile times. And for what? The STL is not even fast. The way the standards are written, std::unordered_map has to be implemented as a tree rather than a flat open-addressing hashtable, which would've been far superior due to cache locality.

For my own project I rolled my own string, string_view, map, set, optional, variant, and vector. Only took maybe a day. And that day has paid dividends, as my clean debug builds literally take 3 seconds now.

Re: C++: The Documentary

#209

Post by variadix »

samiv wrote: post #31
flohofwoe wrote: post #25

Earlier quoted context omitted.

For games, C++ becomes a much simpler language since game code bases usually ignore the C++ stdlib (at least mostly, and for good reasons, e.g. see [0]). And without the stdlib C++ is actually kinda-sorta okay-ish. Related, the main problem with the C++ ecosystem is that everybody carves out their own language subset, so it's not one ecosystem but many ecosystems with contradicting styles and language/stdlib subsets.…

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

The STL is not good if you want performance or predictable behavior. The issue is in the specification and the requirements placed on certain algorithms and data structures. It’s easy to beat unordered_map for example with an open addressing hash map, small vector optimization can’t be implemented in vector due to standard requirements, etc.

Re: C++: The Documentary

#210

Post by VoidWarranty »

Davidbrcz wrote: post #103
VoidWarranty wrote: post #63

Earlier quoted context omitted.

You don't have to use them. There's a handful of nice to haves in modern releases but its totally fine and sane to just ignore whatever the committee is distracted by at the moment. Hell, if you wait long enough, they'll just deprecate it before you can care to bother.

And that's the usual fallacy (just ignore the bad stuff). But if you work with C++ in professional context, you will encounter it somewhere (library, teamate's PR, legacy code, LLM output, book / blog / conference ...). | You actually need to know the bad stuff to be able to judge it and discard it.

We're talking about different things.

Im talking about your own personal coding. You dont have to use the new things. You dont have to know them to decide to discard them. In fact, the criteria to discard something is to not know it. You generally shouldn't be using things you dont know anyway.

The fact that other people use things you do not know is not a reason to stress out about the dumb pace and direction c++ is moving in. It is possible to enjoy a life free from fomo about the c++ standards goalposts.

Post reply on HN