That's pure assumption and, as far as I can tell, not actually true. PASCAL was a strong contender. No language was competitive with handwritten assembly for several decades after C's invention, and there's no fundamental reason why PASCAL couldn't benefit from intense compiler optimizations just as C has.

Here are some papers from before C "won", a more recent article about how PASCAL "lost", and a forum thread about what using PASCAL was actually like. None of them indicate a strong performance advantage for C.

[–] CanadaPlus@lemmy.sdf.org 1 points 5 months ago* (last edited 5 months ago) (1 children)

Hmm, that's really interesting. I went down a bit of a rabbit hole.

One thing you might not know is that the Soviets had their own, actually older version of C, the Адресный programming language, which also had pointers and higher-order pointers, and probably was memory-unsafe as a result (though even with some Russian, I can't find anything conclusive). The thing I eventually ran into is that Pascal itself has pointer arithmetic, and so is vulnerable to the same kinds of errors. Maybe it was better than C, which is fascinating, but not that much better.

Off-topic, that Springer paper was also pretty neat, just because it sheds light on how people thought about programming in 1979. For example:

In the following, we shall

compare how "convenient" the languages are to code our favourite solution to a programming problem,

play the devil's advocate, and try to list all possible things that can go wrong in a program expressed in a language.

Some of us, including myself, have reservations about the validity of the second technique for comparison, the most persuasive argument being that even though some of the features are potentially dangerous, people rarely use them in those contexts. There is certainly some truth in this, but until we have experimentally collected data convincingly demonstrating this, it is wiser to disbelieve it. Take note of the observed fact of increased difficulty in formally proving the properties of programs that use these potentially hazardous features in a safe way. This is one of the reasons behind the increased redundancy (and restrictions) of the newer languages like Alphard

I don't see a lot of people denying that 2 is a good metric today. In fact, in the rare exceptions where someone has come right out and said it, I've suspected JS Stockholm syndrome was involved. Murphy's law is very real when you not only have to write code, but debug and maintain it for decades as a large team, possibly with significant turnover. Early on they were still innocent of that, and so this almost reads like something a non-CS acedemic would write about programming.

[–] BatmanAoD@programming.dev 1 points 5 months ago (1 children)

Indeed, I had no idea there are multiple languages referred to as "APL".

I feel like most people defending C++ resort to "people shouldn't use those features that way". 😅

As far as I can tell, pointer arithmetic was not originally part of PASCAL; it's just included as an extension in many implementations, but not all. Delphi, the most common modern dialect, only has optional pointer arithmetic, and only in certain regions of the code, kind of like unsafe in Rust. There are also optional bounds checks in many (possibly most) dialects. And in any case, there are other ways in which C is unsafe.

[–] CanadaPlus@lemmy.sdf.org 1 points 5 months ago* (last edited 5 months ago)

I feel like most people defending C++ resort to “people shouldn’t use those features that way”. 😅

And yeah, I'm with you, that's a shit argument. A language is a tool, it exists to make the task easier. If it makes it harder by leading you into situations that introduce subtle bugs, that's not a good tool. Or at least, worse than an otherwise similar one that wouldn't.

Without a super-detailed knowledge of the history and the alternative languages to go off of, my suspicion is that being unsafe is intrinsic to making a powerful mid-level language. Rust itself doesn't solve the problem exactly, but does control flow analysis to prove memory safety in (restricted cases of) an otherwise unsafe situation. Every other language I'm aware of either has some form of a garbage collector at runtime or potential memory issues.