C++: The Documentary

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 critical mass for C++ to succeed. The traffic on comp.lang.c++ angled sharply upward. Borland saw our sales, and abandoned their OOP language product and did Turbo C++ instead. Microsoft saw Borland's success and then did their own C++.

We sold a lot of Zortech C++ compilers to Microsoft. They used it to develop COM.

I heard rumors that Microsoft was developing their own OOP C, called C*. I've never been able to confirm it, though.

1. do I need a license to create a C++ compiler?

2. do I need to call it something other than C++?

He laughed and said, no, I could do whatever I wanted. He also thanked me for being the only compiler guy to ask permission.

I read about his passing a few years ago. He was a solid guy.

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

Their creation C and UNIX won over the more advanced LISP and Smalltalk systems because they were simpler to implement. Even their own more advanced Plan 9 based OSs could not displace the more widespread unix-like systems.

It seems distribution and 'good enough' to rely on always wins. IMO, dynamic languages like Perl, Python, Ruby, JavaScript, PHP and the heavily marketed Java provided good enough high level facilities that have prevented people from reaching for Lisp and Smalltalk.

Looking at it through this lens, perhaps C++ was the vehicle for strapping some high level facilities on a widely adopted low level performant language that made it just good enough of a technology for wide adoption.

Obviously. C++ was a "better C" in that you could keep a lot of your "legacy" C code while improving your codebase piecemeal with C++ features. Your management didn't even have to care, in that C/C++ was accepted as a valid descriptor even by people who should have known better. It's a wonder Java/C# and Perl/PHP never caught on.

In my experience it takes a while (<=3 months) for folks to become proficient when they see an alien dialect of c++. That may sound totally unacceptable to you (fair). Cpp is also a “big tent” language in that it is genuinely multi-paradigm.

I think LLM’s might help, but sometime they hurt too (confidently/persuasively wrong analyses). The gain is large for small/trivial contributions. For changes that require genuine understanding, I’m not sure (large error bars personally as to whether the sign is even positive).

Followed a couple of years later contribution to Go's design, exactly to avoid C++ at Google.

I would say the same thing of Rust.

But it was indeed a nice book that really made stataic polymorphism popular. Before that, most books focused on building object hierarchies with virtual functions, etc.

For the language of the web I'd probably nominate HTML.

For the language of the internet it's a lot less clear to me.

It took in almost every idea, and the battlefield showed us which do work and which don't. We get to keep RAII, move vs copy, smart pointers, placement-new, and generics. We get to drop auto_ptr, copy-by-default, its specific exceptions implementation (fight me), multiple virtual inheritance, and templates as full code substitution.

In my opinion the battles have played out, and Rust is the best sum-up of what worked (it even inherited the compile times! Lucky us!)

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.

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. This makes code reuse via libraries much harder than it should be.

[0] https://hftuniversity.com/post/the-c-standard-library-has-be...

Also the nice thing about having a large set of features is that C,++ allows you to write very nice abstractions (or not) at both very low or at very high level. In other words you can be very low level with online ASM and bit operations and bit and direct memory manipulation or very high level almost like a script language. Whatever the problem domain needs C++ has got you covered.

As a side note, regarding your profile info, unless you are based in North Korea, please at least add one 0 to your rate. You'll get more long-term and high-quality clientele.

That's what it's like to be a C++ programmer.

I've been feeling this way about web dev for a while now, and sometimes look at C++ devs with jealousy, wishing that the crazy amount of memorization/varied standards/rough maintenance/high difficulty I experience were only limited to the language that I write.

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.

If you'd already been using it for 10+ years you wouldn't feel that way, because you'd already have memorized a lot of it.

If someone tells you to write a web app, do you also cry? Surely there's more JavaScript frameworks than subsets of C++ at this point, no? Do you also go memorize all of them? Or do you just quickly pick one, and then only learn that one, and forget the rest exist? Because that's kinda how you approach C++. You pick a subset (like, say, just modern C++, only caring about C++17 & later or whatever), and just use that. And move on with your life. There's absolutely no reason to learn how std::auto_ptr works because it's dead in the same way you aren't learning how PHP & CGI works if you're making a modern web app. They're dead relics of the past that you can just pretend don't exist.

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 as main compiled language.

Additionally as many other programming language ecosystems have discovered, it is easy to beat C++ in version 1.0, and eventually all of them grow to get the complexity of their own.

I reach for C++, because the language runtimes, compiler tooling, and GPGPU frameworks I care about are partially written in C++, and I am not in the place to be writing new ecosystems myself.

The ecosystem isn't fine - just to get a project going requires picking a non-trivial set of tools and approaches, none of which the C++ standard enforces or guides to.

For example, will you manage dependencies via packages? If so, with what? What will you use for building your project? The list goes on and on.

Apparently, they are making documentaries about open source software.

0: https://dianne.skoll.ca/projects/remind/

On top of that, C++ allows to design very concise APIs. (One of my favorite examples is sol2: https://github.com/ThePhd/sol2).

Library code involving templates, on the other hand, can be pretty complex and hard to read. Concepts and other C++20 features (like [[no_unique_address]]) are certainly an improvement, but only new projects with no backwards compatibility requirements can actually use them (unconditionally).

That's how you emulate language features that aren't there originally. I've "impelemented" a static code block, like in Java:

https://stackoverflow.com/a/34321324/1593077

and that's all in C++98. The implementation is a bit ugly but the use is terse and self-expalantory.

The language which still supports C-style pointers, arbitrary datatype conversions, and inherits architecture-specific undefined behavior gives you too many ways to fail at solving a problem.

As a programmer, I love coding in C++ because I know what I'm doing. I'd hate reviewing C++ code though.

Also

>It is because we have enduring demand for languages that are good at performance per watt.

(1 min in from above link)

Is this good or bad?

[0]: https://www.slashdata.co/research/developer-population

[1]: https://www.slashdata.co/company/methodology

[2]: https://developernation.net/

(if you mean that film, most likely no.)