C++: The Documentary • Hacker News Board

Re: C++: The Documentary

#231

Post by spacechild1 » Fri, Jun 05, 2026, 5:35 PM UTC

garyrob wrote: post #211

For what it's worth: I had an idea for a special reminder app I wanted for myself. It's complicated enough that it comes to 9,000+ lines of code. I wanted to write it using the C++ UI library wxWidgets, because I like that wxWidgets uses native widgets, and is cross-platform, and that it's easy to make an app look nice. And that it doesn't use tons of memory. There's a wxPython library, but I didn't want my UI to be…

Do we really have to shoehorn AI into every single thread? It's really getting tiring.

Re: C++: The Documentary

#232

Post by [deleted] » Fri, Jun 05, 2026, 5:35 PM UTC

techbrovanguard wrote: post #189

rustyhancock wrote: post #91

Earlier quoted context omitted.

I agree. You don't learn or know C++ in the way you learn or know C. You never have the total language spec in mind. Much of it you will never (and for some of it should never) come across. The way I think of it C is an abstraction of the machine, so thin it's nearly transparent. C++ is an abstraction over programming paradigms, letting you pick how you think. Everything else abstracts the machine away, replacing it…

> C is an abstraction of the machine, so thin it's nearly transparent. Looks like someone fell for the C abstract machine trap yet again. No, C is isn’t an abstraction of the machine.

[deleted]

Re: C++: The Documentary

#233

Post by bulbar » Fri, Jun 05, 2026, 5:36 PM UTC

socalgal2 wrote: post #223

C++ needs to die. I get so many people are invested in it and so much code is written in it. I used to be a fan and it's still my main job. But, in 2026 with LLMs able to find all the exploits, and with more and more adversarials, we need a language that is opt-out of safety, not C++ which is opt-in + super vigilance to get safety. It doesn't work and decades of experience proves it.

When LLMs find all the exploits without the source code, they should find them even easier worth the code, no?

Re: C++: The Documentary

#234

Post by rustyhancock » Fri, Jun 05, 2026, 5:36 PM UTC

skydhash wrote: post #217

techbrovanguard wrote: post #189

Earlier quoted context omitted.

> C is an abstraction of the machine, so thin it's nearly transparent. Looks like someone fell for the C abstract machine trap yet again. No, C is isn’t an abstraction of the machine.

It may not be an abstraction of a real machine. But the C abstract machine is very close to the foundational idea of how a computer work. And it’s quite easy to bootstrap.

Importantly my work involves me often being able to look at C and think about the assembly and back and I regularly work on ESP32, ch42(riscv) and atmega avr8.

I couldn't do that with mciropython on any platform.

C is a thin abstraction, python isn't.

Re: C++: The Documentary

#235

Post by spacechild1 » Fri, Jun 05, 2026, 5:40 PM UTC

orsenthil wrote: post #166

I haven't watched this yet. With all due respect, why John Romero instead of John Carmack for a C++ documentary ?

I'm pretty sure they first asked the other John and got a rejection :)

Re: C++: The Documentary

#236

Post by bdelmas » Fri, Jun 05, 2026, 5:43 PM UTC

jeffbee wrote: post #214

jmalicki wrote: post #204

Earlier quoted context omitted.

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…

Saying this about Rust and C++ is like saying the kitchen you just built is cleaner than the old kitchen you used for 50 years. Get back to me in another few years.

I agree for the comparison.

Now for Rust I don’t think it is going to change a lot. Because it is based on ML, it has the best foundations and all features are known. The question is more how much Haskell vs script/imperative do you want your language to be, and what’s the purpose of the language rather than we had the wrong paradigm and found a new better one. For Rust 99% of its features are known and most are already implemented.

Maybe things around the borrow checker, and await, but beyond that nothing as much as what C++ saw in its history. Even more when for instance you see the article from the guy doing Gleam where traits (impl) are not necessary, all you need is data and function to have the same functionality. Or how ML have been the main factor to most new languages or new features to existing languages.

The future is ML, with languages dedicated to specific use cases and niches. And also ML languages easily readable by AI.

Re: C++: The Documentary

#237

Post by jheriko » Fri, Jun 05, 2026, 5:48 PM UTC

[dead]

Re: C++: The Documentary

#238

Post by wasmperson » Fri, Jun 05, 2026, 5:49 PM UTC

WalterBright wrote: post #229

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…

> if c++/cfront didn't ride on the tails of c, I'm skeptical it would've seen widespread use What launched C++ into success was Zortech C++. At the time, 90% of programming was done on MS-DOS. Cfront was nearly unusable on DOS, because: 1. agonizingly slow to compile 2. no support for near/far pointers, which was essential for non-trivial apps Zortech C++ fixed those problems, and sold like wildfire. This provided cr…

Your perspective on this may be distorted due to your personal involvement. Do you believe MSVC++ or Turbo C++ would still have existed without Zortech C++ arriving first? Because if so then I don't think you can really take credit for C++ popularity on the PC.

Re: C++: The Documentary

#239

Post by fasterik » Fri, Jun 05, 2026, 5:54 PM UTC

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…

I don't really understand this perspective. You don't need to memorize anything to learn a new programming language. You choose a medium-sized project you've already done in another language, start with "Hello world," and add one line of code at a time until the project is done. When there's something you need that you don't know how to do, you look it up.

You'll end up with a strong understanding of the subset of the language that's actually useful for the thing you want to build.

Re: C++: The Documentary

#240

Post by CyberDildonics » Fri, Jun 05, 2026, 6:05 PM UTC

Maxatar wrote: post #213

andrewl-hn wrote: post #200

Earlier quoted context omitted.

Something that not many people consider. It is almost certain that C++ "saved" C by existing. Without C++ there would be an enormous pressure to add more features to C itself. One reason why C committee could get away without adding much over the years was that they could nod towards C++ and say "that's their job, not ours". And if later didn't exist who knows what kind of language C would become. Classes? Templates?…

I don't know if this is true. In the 80s there were many languages that were C with additional features or C preprocessors that added and experimented with features similar to cfront. You had OOPC (object-oriented pre-compiler), Objective-C, C*, Concurrent-C. People were experimenting in all kinds of ways by taking C and trying things out with it.

I think it is absolutely true, because adding features to an experimental language that has no tools or ecosystem surrounding it does nothing and people know that.

Niche experiments having features doesn't accomplish anything, but adding just one more feature to C seems plausible.

With C++ people could point people to another production ready language compatible with C that people could use, so there was somewhere they could do and an example of the feature working instead of someone promising silver bullets in theory.