Hacker News Reader

> 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 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.

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.

> Do you believe MSVC++ or Turbo C++ would still have existed without Zortech C++ arriving first?

Nope. As I mentioned, Borland was working on their own OOP C language. ZTC++'s success caused them to abandon it and do Turbo C++. I know this because of my conversations with Eugene Wang. And Turbo C++'s success caused Microsoft to do MSVC++, which was quite late to the game.

Before C++, the newsgroup traffic on C++ and ObjC was about the same. The C++ traffic took off after ZTC++ was released.

You can verify some of this by:

1. looking at newsgroup programming language traffic over time

2. looking at the release dates of Zortech C++, Turbo C++, and MSVC++

3. looking at the programming magazines of the time and what language/compiler they used

4. looking at the programming magazines at the time and seeing they were all about programming on the PC, not mainframes, and not Unix.

Little known fact - when I was contemplating enhancing Zortech C into C++, I was concerned about AT&T's intellectual property. I contacted Ryan Williams (I think that was his name), AT&T's IP lawyer. I asked him:

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.

I looked up my notes. It was William Ryan.

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? Lambdas? We can only speculate.

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.

> adding just one more feature to C seems plausible

I thought it would be a couple months to add C++ to my C compiler. 10 years later...

> It is almost certain that C++ "saved" C by existing.

Perhaps. But in the 80's, C was the most practical language to use on the PC, by far. And porting C code to other platforms was easy.

Yeah, OPs claim feels disconnected from C’s identity. C stayed conservative because the areas where it excels (to this day) benefit from its “portable assembler” design history. A history with no C++ wouldn’t have changed that, instead another (either non-C extended or alternative C-adapted [Obj-C, for instance]) language would have taken the market C++ did; likely with a larger runway time due to the lack of interoperability/superset compilation.

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

I highly respect the Ken Thompson and the rest of the old UNIX hands, but wouldn't they admit that the real world is messy and the best solutions in isolation don't always win?

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.

You think that LISP and Smalltalk aren't widely used is because they weren't easy to implement in the late 1980's? There have been many languages that have risen to prominence in the 40 years since, yet LISP and Smalltalk remain niche languages.

My opinion is that Lisp and Smalltalk are too pure and abstract. C is heavily tied to the real world of computing and can be easier to grasp for beginner. But try to explain variable bindings (instead of assignment) or message passing (instead of function calls) to a beginner in programming. It’s not that they’re hard to explain or understand, they’re just hard to be completely grasped without a foundation in computer science. They’re too alien.

Which new languages have risen to prominence outside of a niche?

Rust, Python, Java, Ruby, Scala, Swift to start with. These are languages with very wide adoption. Objective-C is very Smalltalk-like, but it is being phased out for Swift.

These became popular after Moore's law made it possible many years after C/Unix had become the standard.

And they became just good enough that more people didn't go into Lisp/Smalltalk instead.

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?

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.

Then I will feel the same about Rust! There's nothing wrong with wanting to throw out the janky accretion every 30 years for a redesign.

After 3-4 years, sure. But eventually enough has changed it's worth redoing.

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.

I built my career on C++ and I agree with you. Rust is just superior in almost every way. C++ is dead to me for new projects.

> IMO, if c++/cfront didn't ride on the tails of c, I'm skeptical it would've seen widespread use

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.

Nowadays I got into the habit of saying C++ was C's Typescript.

> kiss goodbye to any notion of being able comprehend existing code that's not written by you (until llms arrived).

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).

UNIX founders never liked C++ that much, note how Plan 9 and Inferno only have C as the systems language, with the Alef experiment, and later Limbo.

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

The last one from Scott Meyers was the final nail in the coffin for me. The chapter about auto and template parameter deduction specifically. Since then, I've been happy with Golang and Java.

Auto is great