I happen to disagree, C++ is the best thing after sliced bread. (Just wanted to balance the conversation, really, with an equally meaningless, albeit honest, statement.)
Nah, that place I leave for C, the number one reason we keep having memory corruption issues during the last 50 years of computer history, and having taited every language that has some level of compatibility with it.
The late pioneer in compiler optimization--Frances Allen--agrees.
2006: "..but something else had happened--and that was back in 1973--[something] which I was very, very unhappy about--and that was the advent of C! It derailed, as far as I was concerned, the advances that I foresaw in compilers. One cannot let the user play with the addresses, and use procedures, and play with pointers--which is pointing to the data--and be able to understand how one can transform the program to run more optimally."
"There was an interesting debate at the SIGPLAN conference in that period--about the relative need for optimization. It was put on the table that it wasn't going to be needed anymore! So. Anyway. You can have your own opinion on that, but I know I have mine, beyond a doubt that it was a huge setback for--in my opinion--languages and compilers--and the ability to deliver performance--easily--to the user."
> One cannot let the user play with the addresses, and use procedures, and play with pointers--which is pointing to the data--and be able to understand how one can transform the program to run more optimally."
Well 50 years on we still haven't seen any of these "sufficiently smart compilers", at best they can outsmart C compilers in a few cases with things like generics, so the idea that higher level languages would be faster has been wrong for at least 5 decades. At least you can forgive them for thinking they would 50 years ago, but now it's just ignoring 50 years of reality.
Unfortunately, this assumes everyone is a master at C and that we are comparing straight line speed. In the real world, higher level languages have a much better comparison since everyone's C program has their own slow, buggy "standard" library instead of the hyper optimized ones of higher level languages. One of the major reasons why that is the case is because C, at a language design level, makes building those kinds of high level, interesting, performant, and safe APIs hard
> In the real world, higher level languages have a much better comparison since everyone's C program has their own slow, buggy "standard" library instead of the hyper optimized ones of higher level languages.
In the real world we've pissed away 30 years of hardware improvements primarily through switching to higher level languages. In the real world higher level languages are still not used we're performance counts (like games). In the real world low level languages like c and C++ are still powering our most important and fundamental projects.
She's exactly right. I'm really not sure how we came to accept the worse-is-better argument that high performance required exposing machine details into the source language, and letting compiler writers just "do whatever is fastest", regardless of safety. It gave rise to today's situation where none of application writers, library writers, kernel writers, or compiler writers are quite sure what will happen if a new optimization is introduced. Will it break programs? By how much? Well, let's roll the dice! This is a direct result of allowing--no, even expecting--programmers to peer behind the curtains to see machine details that they frankly, shouldn't. It's why porting programs from one machine to another is even a thing, as opposed to just selecting a different output from a compiler, or running a different VM.
Proper abstractions define exactly what happens in every situation, and design unobservable details out. It is the basis for optimizations that fundamentally cannot observed (except side-channels, like timing and other resource usage). Proper abstractions is why we have fast processors. The ISA is a hard boundary.
They thought many ideas of it (see Lisp, Smalltalk) but computers where not powerful enough for complex compilers. Instead, the burden of ensuring correctness had to be left as the cognitive burden for the developer for decades to come.
> They thought many ideas of it (see Lisp, Smalltalk) but computers where not powerful enough for complex compilers.
That's probably true for borrower-checking specifically, but I don't think it accounts for all language-design breakthroughs. There were decades between the development of functional programming languages, and widespread hybrid languages which incorporated those ideas (e.g. modern Python and C#).
> <sarcasm>Too bad those shitty engineers in the 70s didn't think of Rust...</sarcasm>
True, Rust didn't exist back then, and yes, some (few!) features in Rust weren't invented and worked out then, like the ownership model.
OTOH the corollary to that statement isn't that C was some shining beacon of good design taking advantage of the then state of the art programming language knowledge. See e.g. https://pastebin.com/UAQaWuWG
That pastebin leaves out the fact that C's spartan approach and extreme simplicity allowed C to become the most popular programming language in the world already in the time of K&R, a book still renowned for it's clarity and low mental baggage required to onboard onto a programming language.
The pastebin also left out that Bjarne Stroustrup developed C with classes, and the C, as a backward compatible superset of C to take advantage of C's unrivaled popularity.
We all can agree that the science and art behind programming language design progressed a lot in the four decades where we enjoyed C. However, it feels a kin to rewriting history to depict C as a subpar language that was poorly designed and had little to no redeeming qualities, when facts speak for themselves.
> However, it feels a kin to rewriting history to depict C as a subpar language that was poorly designed and had little to no redeeming qualities, when facts speak for themselves.
It was subpar compared to the state of the art then. It's redeeming quality was that it worked on the PDP-11, whereas the better languages required mainframe level resources. The tragedy isn't that C was invented, it fitted it's niche back then. The tragedy is that as HW evolved the world remained stuck with C rather than switching to better languages.
Actually, computer science in general and the theory of programming languages in particular were already very advanced back in the 60s. It’s just people thought little of languages that would have needed gigabytes of memory (or days of run time) for the compiler to do its job.
That's exactly the point the pamphlet I linked to makes. C was far from the state of the art when it was invented, it's only major redeeming quality was that it worked on the shit low-end computers that were available to the inventors back then.
The tragedy wasn't that C was invented, it was fit for purpose then. The tragedy was that as HW evolved beyond the PDP-11 level, unix programming remained stuck at C.
No one can seriously argue that C's language design was inherently advantageous over, say, Pascal. If Lisp, ML, Simula, Algol, or Ada received the amount of optimization and porting investment that C did, history would be very different.
C succeeded because a.) Unix, and b.) there were a zillion platforms with a zillion different compilers that could process something like C. They all did weird things and you couldn't actually write portable code for decades, but you could kind of fake it.
Sure, with more or less effort. C's semantics seem very easy to port, with very little abstraction over the commonalities that all (most?) assemblies share: computer as a giant array with a CPU and registers.
There's a gaping hole in the abstraction when it comes to word size, but that's about it, and it's obvious to diagnose at least.
Compared to the list of languages above with their more advanced features, it's super easy to port a C compiler and start compiling code. Worse is better.
Actually I'd bet a dollar or two that linear threading of resources existed even before C, it just wasn't neither a common practice nor a theoretical framework at the time.
Have been programming in C (and then C++), like, forever. Hardly any memory corruption issues. Yes, you have to be a little more disciplined and pay attention to things. Being distracted certainly does not help.
If powerhouses like ARM, Apple, Google, Microsoft and even Linux kernel admit not being able to, now even pushing for hardware memory tagging as the only remaining way to fix C and its influence on C++/Objective-C, you are indeed a top expert.
> It's actually really hard to get modern C++ wrong
That's not true. The language is full of footguns, from its basic expressions (signed overflow, integer division-by-zero, and read-before-write are all undefined behaviour) up to concurrency (data-races are undefined behaviour) and everything in between (unsafe arrays, unsafe memory management, alignment, the list goes on). The high-level constructs in modern C++ help, but you're never further than one misstep from undefined behaviour.
Even high-profile codebases by highly skilled teams using all the modern tools, still run into trouble. Even Chromium has security issues arising from the dangers of C++. The push for Rust is out of pragmatism, not trend-chasing or theoretical purity.
Of course, C codebases like the Linux kernel also continue to have these issues.
I'm less optimistic. Even major C++ projects that do everything right, still have issues that would have been prevented had they used a safe language. My go-to example is Chromium.
Yeah, "orange site" comments on Twitter are an interesting entertainment genre in general, if you're into "a visit to the bizarro world" type of humor :).