""If you want to design something better than C++, you need to understand why so many people use C++." No, you don't. You just need to design something better than C++."

And how do you define "better than C++"? C++ didn't get to be as popular as it is for nothing. It got to be as popular as it is because it is a very good tool for solving certain classes of problems. If you don't understand why people still choose C++ for new projects, you're going to have a tough time building something that will change those decisions. And if you think people only choose C++ for new projects because they're idiots, frankly, you're the idiot.

"Everybody is an idiot" is a much less likely hypothesis than "I'm missing something". Before you throw out a popular tool whose appeal you don't understand, you would be well advised to spend some time comprehensively falsifying "I'm missing something". Hence, "If you want to replace X, you need to understand why X is popular."

It wasn't my example. But there is no a priori reason why "something better than C++" must be designed by someone with a deep understanding of C++. This holds for anything you might put in place of C++:

- must someone who designs a car understand why people ride horses?

- must someone who designs a phone understand why people use smoke signals?

- must someone who designs a gun understand why people use swords?

Sometimes, the vast majority of people are just wrong. Look at people building McMansions with complicated roof lines, useless "bump-outs" and other crap details, when any thinking building professional knows this is wrong.

"Now, having people adopt better-than-C++ and better-than-CSS might take a little bit of the psychoanalysis (marketing?) you propose."

I don't mean marketing, I mean actually designing something better. A lot of people don't actually know what better means. It's like the Betamax myth. A lot of people believe that Betamax was the technologically superior version, and it lost because of other reasons. This is bunk. Betamax's edge in picture quality over VHS, all else being equal, was slim to nonexistant. But Betamax was locked to a relatively fast tape speed to keep quality from degrading. VHS let people run at much slower tape speeds in order to fit more video on the same tape. Betamax allowed you record about an hour worth of video programming on a standard tape. VHS originally allowed two, and then they just said the heck with it and let you record four hours of bad-looking video. It turns out, though, that it's far more important to most people to have the ENTIRETY of a movie or (in the case of a four-hour tape, an NFL game) than it was to have the part of it you recorded look pristine.

The lesson everyone draws from Betamax is that we can't have nice things and technological superiority is trumped by other considerations. The lesson everyone SHOULD draw from Betamax is that to win, you have to be better at the right things to actually be better.

Betamax and VHS are incrementally different, not radically different as the blog post discussed. Radically different would be VHS vs. streaming video, and I suspect there is no technological overlap between the two. Incrementalists would have us stream video to tape decks, or something.

>Now, having people adopt better-than-C++ and better-than-CSS might take a little bit of the psychoanalysis (marketing?) you propose. But understanding why someone uses C++ is not really relevant at all in order to design a superior replacement.

The above makes no sense. Understanding why they use C++ is the first and most basic step in designing a REPLACEMENT.

If what you create doesn't cover their use cases then it's not a replacement, it's just a new language.

So the web can't be a replacement for CICS because it wasn't designed as such. Gotcha.

No, you didn't really got anything. You just put words in my mouth with a quick snarky response that misunderstoods what I wrote.

Whether your replacement handles the use cases people need the old product for intentionally or unintentionally (in the case of the web vs CICS) doesn't matter.

What matters is that your design DOES handle those use cases and those needs.

You can obviously end up designing something as a replacement for X without specific intent or even knowledge of X.

But you can't design something as a replacement for X if it doesn't handle the needs that people use X for.

That's a completely different point than the one you made originally. If you want to avoid being misunderstood, then make the point you actually intend - "a C++ replacement must function as C++ does" instead of the one you claim - "understanding C++ is the first step in replacing C++"

How do you propose "must function as C++ does" happens if not through understading C++'s uses?

As I said, it can also be done unintentionally (you create a new language without studing how C++ is used, and it gets adoption in place of C++), but this is far less likely and quite random.

If one really wants to create a replacement for a language, he should very much study the language he wants to replace, and find what he needs to provide in his new language and what he can improve.

The thing you added that, "no, he can just create a replacement" (without needing to study the previous language), might very well be possible in theory but it's very much improbable.

If you want adoption from C++ users and from projects C++ is used and for the kinds of stuff C++ excels, you pragmatically need to study C++ and how it's used, period. That was the case for Rust, for D, for Java and C# earlier, and of course C++ (who studies C with that intent). That was also not the case for Go, and that's one reason why Go (by Pike's own admission) failed to gain traction from C++ users.

Of course success is not guaranteed, but merely making a "superior language" is not a way to get C++ users off C++ (or any other language).

For the vast majority of people, a car functions as a horse used to before there were cars -- it functions better, in fact. Yet car designers are not required to be intimately familiar with horse care.

You are pointing out marketing issues. I agree that if you don't actually have a better C++ than C++, then you will have difficulty convincing most C++ users that they should switch.

By the same token, if you actually do have a better C++ than C++, it will be evident in the adoption of the technology.

Also at this point, if Java, Go, Objective-C, D, and C# have not convinced the current user base of C++ to use other things, then perhaps it is no more possible or necessary to convince these remaining users to switch than it is to convince modern horse riders that they shouldn't bother to ride, own, or breed horses. For them there cannot be a "better C++ than C++."

There's a pretty big difference in that the web has far more features.

Unless, you intend for C++'s replacement to have even more features than C++, which hardly seems even possible.

Must a replacement perform all of the functions of the thing that it replaces in order for it to be a replacement? Let's interview our good friend the vacuum tube to find out more.

It's clearly possible. C++ lacks pattern matching, for instance. Whether adding any given feature is advisable is another question...