I learned C from reading K&R over a Thanksgiving weekend, without even a compiler to try it out on. The only thing that confused me was the explanation of argc and argv.
Learning C was a different experience entirely. The mental work involved was huge with the level I worked at for any job being micro-managing the machine. It's only simple on the surface. The job is much harder than a BASIC, Oberon, or whatever with selective use of unsafe features.
On the other hand, I learned BASIC on a TRS-80. Safe? Not with the POKE command being part of the language.
You start with what's shown to have benefits. You then subset it to work within your constraints. I described an example of what C inventors might have done here:
https://news.ycombinator.com/item?id=12316092
"Due to this it's impossible to say how well another language would behave in the wild since I don't think anyone can predict how well the language will be used to it's extent."
Better if it was designed to do that. As I illustrated, C wasn't: portability was incidental. The languages designed to make portability, safety, integration, etc first-class features handle the "in the wild" effect way better. Of the simple ones, Wirth's keep things consistent by focusing on types, memory-safety where possible, interface checks, concurrency support, and modularity. Of older days, Ada is probably one that most systematically approached the problems of programming. Due to all its interface safety & support for cross-language development, the integrations and extensions of Ada programs by multiple developers usually happened with fewer problems than you'd expect.
So, you can design such capabilities in. The resulting problems will be smaller. C didn't. The problems were large and seemingly impossible to fix afterward. Makes sense.
"Something that's good for the advanced programmer, in my opinion, is the use of braces and not words."
I'm sticking to the concrete stuff. Much of the syntax stuff is opinion which hasn't been empirically tested enough. Quorum is closest to that. Except for one that had some evidence:
"I also hate needing to type := for assignment. It makes no sense. "
The language has to support assignment and equality. Originally, that was := (arbitrary) for assignment and = for equality. The change was to = for assignment and == for equality. That's less intuitive. Led to errors. Also, "change your IDE/tooling" doesn't cover for bad language design. It's also exactly what I'm telling people to do in the article: ditch C because it's bad design wherever possible.
The issue is that there are not any major open source projects to examine that use these languages to see how they actually work in the wild. For example, writing a Java codebase with nothing other then the standard library you can do some very nice design patterns. You can come up with some very clean and concise code and everything can be perfect. Then, when you go to integrate with someone else's code (see Spring) you notice that everything becomes a mess since they are using some crazy things that make it very difficult to integrate with it.
Due to this it's impossible to say how well another language would behave in the wild since I don't think anyone can predict how well the language will be used to it's extent.
That being said, I think C succeeded because it was SIMPLE. Not only for the compiler, but I can teach pretty much anyone how to understand C in most likely a few days to a week. It's very simple and very little you need to know to understand how to start writing your programs.
On the other hand, ALGOL is MASSIVE. There are 106 reserved identifiers in the language according to wikipedia and I don't think I could ever remember what every one of them did.
Currently C has about 32 key words and I can tell you in full detail what every one of them means except union as I don't work much with C.
This is good for the beginning programmer since it shortens the time they need to hit the books and helps them jump strait into writing.
Something that's good for the advanced programmer, in my opinion, is the use of braces and not words.
I know this is kind of controversial but I do honestly think that a code should be easily segmented by the eye not readable.
Begin and End only help so much and by so much I mean not at all. Words should not be syntax in my opinion. Seeing { } is less to look at and understand then seing Begin and End.
This sample phenomenon can be looked at from the recent Linux 1000 patches debacle.
Linus said he didn't want to replace unix file permission numbers with the symbolic values. Why? Because it's much much faster for someone to see the numbers and know what's going on then to have to read a bunch of text. It's much quicker in parsing.
That's where the breakdown comes in these discussions. People will throw "You've never used these, how do you know yours is faster."
While that's true that doesn't really present a good argument for changing everything.
I also hate needing to type := for assignment. It makes no sense. Fixing the beginner issue of missing the second equal sign in an if statement has a much simpler fix. Use some kind of IDE/Editor with a linter. You'll not have this problem.