Re:On the history and justification of the C programming lan...
by nickpsecurity on Thursday August 18, 2016 @07:16PM
(#12316945)
"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."
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:
"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.
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.