I've seen no evidence that C brought us anything good. Anything I can do with C I can do with a Modula-2-like language with better safety and compiler robustness. If a check is a problem, I can disable it but it's there by default. Nonetheless, I'll look into any benefits you think C brought us that alternatives wouldn't have done.
The main alternatives were ALGOL60, ALGOL68, and Pascal. They were each designed by people who knew what they were doing in balancing many goals. They, esp ALGOLS, achieved good chunk of most. A subset and/or modification of one with gradual progression for improved hardware would've led to better results than C with same amount of labor invested. On low end, Pascal ended up being ported to systems from 8-bitters to mainframes. On high end, Burroughs implemented their mainframe OS in an ALGOL with hardware that enforced its safety for arrays, stacks, and function calls.
In the 80's, things like Modula-2, Concurrent Pascal, Oberon, and Ada showed up. I'll understand if they avoided Ada given constraints at the time but the others were safer than C and quite efficient. More importantly, their authors could've used your argument back then as most people were doing but decided to build on prior work with better design. They got better results out of it, too, with many doing a lot of reliable code with very little manpower. Hansen topped it off by implementing a barebones, Wirth-like language and system called Edison on the same PDP that C was born on.
"The comment you were responding to reads to me like someone providing historical context, not an expression of an ideal."
The historical context in a related comment was wrong, though. It almost always is with C because people don't know it's true history. Revisionism took over. The power that revision has in locking in people to C is why I always counter it with actual evidence from the inventors of the concepts. Two quick questions to illustrate why I do that and test if it's sensible:
1. When hearing "the programmer is in control," did you think that philosophy was invented by Thompson for C or it was stolen without early credit from BCPL along with its other foundations?
2. Did you know that those were not designed or validated as a good language at all? And that they were grudgingly accepted just to get CPL, an ALGOL60 variant, to compile on crappy hardware whose problems no longer exist by chopping off most important attributes?
If you knew 1 and 2, would you still think C was a "well-designed" language for systems programming? Or a failed implementation of ALGOL60 whose designers were too limited by hardware? If No 1, we should emulate the heck out of C. If No 2, we should emulate ALGOL60-like language that balances readability, efficiency, safety, and programming in the large. Btw, all the modern languages people think are productive and safer lean more toward ALGOL more than C albeit sometimes using C-like syntax for uptake. Might be corroboration of what I'm saying.
I'll back out of the PL debate; this isn't really the place and there's too much to be said on the topic than will fit in this margin.
That's generally true so long as the winner is open. C was. Now, it runs on everything.
> [...] or it was stolen without early credit from BCPL along with its other foundations?
https://www.bell-labs.com/usr/dmr/www/cman.pdf
Show me where it references BCPL. As I see it, Ritchie only references B as the inspiration for C. From the document, anyone who hadn't read the B paper (most people) would think they, Thompson, and/or Ritchie mostly came up with C's features and strengths. They eventually became known as the "C philosophy" and C-like languages.
Whereas, it was Martin Richards that invented both of those plus the idea of stripped down languages for writing tools on minimal hardware. He should get credit for creating the "BCPL philosophy" that the "programmer is in control" plus inspiring a BCPL-like language called C that allowed UNIX's success. Instead, early work focused all attention on Thompson and Ritchie with UNIX papers/software making sure that was the case by adding momentum.
At least I got to see the guy in action in the video linked to my History of C page. It shows his team, the constraints they worked on, why they dumped most of ALGOL, and him working with it later on. That presentation put things into an honest perspective where I can see his and UNIX founders' contributions to overall success with due credits (and/or critiques) to each.
End result a lot of CS students learned C in school.
Other languages tended to be tied to a particular machine, cost money, or weren't really suitable (Fortran/p-system Pascal) for the stuff people wanted to do.
Extended Algol was available in 1961.
PL/I and PL/M variants are older than C.
Mesa was already being used at Xerox PARC when C was born.
There are quite a few other examples that anyone that bothers to read SIGPLAN papers and other archives can easily find out.
> Extended Algol was available in 1961.
> Mesa was already being used at Xerox PARC when C was born.
It still doesn't invalidate the fact that it had more memory safety features as C, one decade earlier.
Regarding Mesa that is like calling x86/x64 firmware an interpreter for Intel bytecode.
Most literature in those days used bytecode to refer to Assembly processed by CPU microcode.
Any systems programming language has them.
However there is a difference between having them as an addition to strong type features and them being the only way to program in the language.
For example, using arrays and strings didn't require pointer arithmetic.
In C all unsafe features are in thr face of the programmer. There is no way to avoid them.
In Mesa and other similar languages, those unsafe are there, but programmers only need to use them in a few cases.
C was designed with PDP-11 instruction set in mind. For many years that the C machine model no longer maps to the hardware as many think it does.
IBM: assembler & PL/S Unisys: Algol GE/MIT (Multics): PL/I(-ish) Control Data: Cybill (Pascal-ish) & assembler Intel and Digital Research: PL/M DEC: MACRO-11 & BLISS DG: assembly & PL/I Xerox: assembly, Smalltalk, Mesa/Cedar PERQ: Pascal
Look at all the C applications, the C ABI that every other language exports for FFI, all the operating systems, big and small.
While I enjoy programming in others more, C is the single greatest most versatile language. All the languages I like all can call C a common ancestor.
Are there better options today? Maybe. Is there a question that C deserves a huge amount of credit? Not at all.
Also, on optimization, I don't know exactly what you mean by that. I assume you mean b/c it's got a lot of undefined behavior. There is so much optimization going on in tools like LLVM that I question it's accuracy.
Anyway, I agree that there are more pleasurable and portable languages (and now just as performant/lightweight with Rust).
All the undefined behaviour in the C spec enables optimisations, yes, but it would be so much better if those optimisations didn't require a lot of mental labour by both compiler writers and programmers.
For example: Pointers, casts, unions, casting pointers to different types, and doing all of this across procedure call boundaries all challenge/break data flow analysis. You can pass a pointer to a long into a procedure, and the compiler has no idea what other compilation unit you are linking to satisfy the external call. You could well be casting that pointer-to-long to something totally crazy. Or not even looking at it.
I was associated with a compiler group experimenting whole-program optimization -- doing optimization after a linking phase. This has huge benefits because now you can chase dataflow across procedure calls, which enables more aggressive procedure inlining, which enables constant folding across procedure calls on a per-call-site basis. You might also enable loop-jamming across procedure calls, etc. C really is an unholy mess as far as trying to implement modern optimizations. The compiler simply can't view enough of the program at once in order to propagate analysis sufficiently.
Now imagine Y was slightly worse than X, based on some magic objective measure. Even though it's the backbone of all these amazing things, Y has actually had a negative impact on the world. We could all have computers that are equally easy to program and use but slightly less buggy, if only that effort has focused on X instead.
So when you say there's no question that C brought a huge amount of value based on usage stats, you're wrong. It can definitely be questioned.
Now, := is another situation. Let me ask you: what did = mean before you learned programming? I'm guessing, as math teaches, it meant two things were equal. So, making = be the conditional check for equality is intuitive and reinforced by years. A colon is English for something similar where you assign one thing a more specific meaning. So, := for assignment and = makes sense even if a better syntax exists for := part. W
hat makes no sense is making the intuitive operator for equality (=) into assignment then equality becoming ==. We know it didn't make sense because Thompson did it when creating B from BCPL. His reason: personal preference. (sighs) At the worst, if I were him, I'd have done == for assignment and = for equality to capitalize on intuition.
It makes much more sense if you consider it from a logic perspective. '=' is material implication (→), and '==' is material biconditional (↔) - which is logically equivalent to (a → b) ∧ (b → a)... so two equal signs (the logical conjunction is redundant so you drop it). Computer science favors logic, so I'd be pretty surprised if it was simply personal preference.
In this case, though, it would be fine to use something smaller like braces, brackets, or parentheses. The reason is the intuition learns it quickly since the understanding is half there already: the braces visually wrap the statements. Not a big deal to me like equality was.
That isn't either assignment or equality testing.
"Isnt... equality tedting"
Contradicted yourself there. The equals is used in conditionals with other logical operators to assert equality is true or not. That's a legit use for it.
https://msdn.microsoft.com/en-us/library/1b3fsfxw.aspx
You can't use that for equality testing at all. If the assumption is wrong, the compiler will generate bad code.
Note: This discussion on an "obvious" problem shows how deep the rabbit hole can go in our field in even the simplest thing. Kind of ridiculous and fun at same time haha.