To whom does "we" refer. The classic C programmer curmudgeon. Those commenting on HN frequently use the term "we" but reading HN one can see that, amongst those commenting, there is a divergence of opinions about software. Who is "we".
Asking prospective "DevOps", "software engineer" and "IT admin" candidates to program in C is an effective way to weed out those who are not truly capable of writing "good" software. It is easy to find mistakes and expose the incompetent. That may offend the incompetent who believe they are "good" programmers. Thus there are new programming languages created every year, more people using them to write "bad" software, and more people who feel emboldened to attack C as the source of problems, instead of "bad" programmers.
C is truth serum. It is difficult for people programming in C to pretend they are "good" programmmers. They will be found out. It is funny how people on HN attack the language for exposing so many "bad" programmers. Under this theory, programmers are absolved of all responsibility for their mistakes. The language is at fault. "Good" programmers do not blame languages for their own mistakes.
IMHO, there is sometimes a benefit to languages that make it more difficult, not easier, to create and sustain Rube Goldberg complexity. Not to mention languages that compile to smaller, faster programs. "Programmer productivity" is ambiguous. For example, it could be a positive for a programmer trying to justify the expense their salary presents to an employer or it could be a negative to people who are forced to use an ever-increasing quantity of "bad" software. It could be a positive to a programmer who wants to keep implementing new "features" or it could be a negative to a software user who dislikes "feature creep".
The dichotomy of good versus bad software is such a subjective topic that the term "we" really needs to be defined. Different groups of people have different interests and therefore different opinions.
Hey, I've written more C code than anything else and was generally considered pretty competent.
> The language is at fault. "Good" programmers do not blame languages for their mistakes.
I also know that my time to get something functional in higher level languages is often 10x less, and my probability of having very subtle bugs to hunt is much lower.
There's a super-weird tradeoff here. There's all kinds of modern, high-level techniques that improve programmer productivity and reliability of bigger systems.. They convert people who can't be productive C programmers into doing OK work.
But they're also slow and a bit opaque in how they work. And it's really easy to run out of performance and have to do exotic things to get them to scale, in which case you have to build bigger systems still and cede a lot of those advantages.
Whereas, if you write to the metal, you can get a lot of performance out of a single large computer.
I kinda knew this comment would show up. It's completely irrelevant / orthogonal to what I'm saying. But I knew someone would have to beat their favorite horse :D
Yes, Rust may have somewhat better programmer productivity than C, but it's not really at a massively higher level of abstraction.
That truth serum sure has a long list of memory vulnerabilities causing tremendous amount of damage.
Come on, C is not an exceptional language from any point of view. It just pretends that everything is a fast PDP-11, and thanks to the insane amount of work and mental gymnastics done by the compiler, it will output good code. It has shitty abstractability that hinders performance if anything (just look at the small string optimizations done by C++) and hurts maintainability and productivity. At least it should have a proper macro system, but preprocessor macros are just a disgusting hack.
It is if not outright a “bad language”, it should definitely be left behind outside of maintaining the litany of programs written in it, and one should start new programs in either managed languages (if absolute control over the hardware is not required), or at least in C++ or Rust.
Interpreters for popular languages such as Perl, Python, Ruby, etc. are all written in C. The original Go compiler was written in C. Even the people developing Rust used Flex and Bison when trying to formalise a grammar.
The question is whether C is useful. For example, in building things from the ground up. Or vetting programmers.
Another way to vet programmers is to observe how many negatives they try to cram into their sentences. For example, "Not being... doesn't... non-popular."
If they are unable to make clear, concise, positive statements the same deficiency is likely to carry over to writing programs.
Not being an exceptional language doesn’t make it non-popular. There is plenty of programs written in it and certain domains are simply 100% C (particularly operating systems)
Asking prospective "DevOps", "software engineer" and "IT admin" candidates to program in C is an effective way to weed out those who are not truly capable of writing "good" software. It is easy to find mistakes and expose the incompetent. That may offend the incompetent who believe they are "good" programmers. Thus there are new programming languages created every year, more people using them to write "bad" software, and more people who feel emboldened to attack C as the source of problems, instead of "bad" programmers.
C is truth serum. It is difficult for people programming in C to pretend they are "good" programmmers. They will be found out. It is funny how people on HN attack the language for exposing so many "bad" programmers. Under this theory, programmers are absolved of all responsibility for their mistakes. The language is at fault. "Good" programmers do not blame languages for their own mistakes.
IMHO, there is sometimes a benefit to languages that make it more difficult, not easier, to create and sustain Rube Goldberg complexity. Not to mention languages that compile to smaller, faster programs. "Programmer productivity" is ambiguous. For example, it could be a positive for a programmer trying to justify the expense their salary presents to an employer or it could be a negative to people who are forced to use an ever-increasing quantity of "bad" software. It could be a positive to a programmer who wants to keep implementing new "features" or it could be a negative to a software user who dislikes "feature creep".
The dichotomy of good versus bad software is such a subjective topic that the term "we" really needs to be defined. Different groups of people have different interests and therefore different opinions.