On Fri, 1 Aug 2003, Jack Bates wrote:
There is nothing in C which guarantees that code will be unreliable or insecure.
Lack of real strong typing, built-in var-size strings (so the compiler can actually optimize string ops) and uncontrollable pointer operations is enough to guarantee that any complicated program will have buffer-overflow vulnerabilities.
C has the advantage of power and flexibility.
So does assembler - way more than C.
It does no hand holding, so any idiot coder claiming to be a programmer can slap together code poorly. This is the fault of the programmer, and not the language.
Presumeably, a non-idiot can produce ideal code in significant quantities. May I politely inquire if you ever wrote anything bigger than 10k lines - because anyone who did knows for sure that no program is ideal, and that humans forget, make mistakes and cannot hold the entire project in mind, and that our minds tend to see how things are supposed to be, not how they are - making overlooking silly mistakes a certainity. Some languages help to catch mistakes. Some help them to stay unnoticed, until a hacker kid with spermotoxicosis and too much free time comes poking around.
The syntax for C is just fine, and since any language is nothing more than syntax, C is a workable language.
I'm afraid you're mistaken - a language is a lot more than syntax. Syntax is easy, the semantics is hard. To my knowledge, only one group ever atempted to formally define semantics of a real programming language - and what they produced is 300-something pages of barely readable "Algol-68: The Revised Report" filled with statements in a context-dependent grammar. All _syntax_ for the same language fits in 6 pages. C is a workable language, but it is not close (by far) to a language which would incorporate support for known best practices for large-scale software engineering. C++ is somewhat better, but it fails horribly in some places, particulary when you want to write reusable code (hint: STLport.com was hosted on one of my home boxes for some time :) Java is overly restrictive and has no support for generic programming (aka templates), besides the insistence on garbage colletion makes it nearly useless for any high-performance stuff. Anyway, my point is not that there is an ideal language which everyone must use, but rather that the existing ones are inadequate, and no serious effort is being spent on getting them better (or even getting existing better research languages into the field). The lack of effort is simply a consequence of lack of demand.
There are libraries out there for handling arrays with sanity checks. The fact that people don't use them is their own fault.
Overhead. To get reasonable performance on boundary-checked arrays you need compiler to do deeper optimization than is possible with calling library routines (or even inlining them - because the semantics of procedure call is restrictive).
For that matter, one can easily write their own. I don't know how many times I have gotten a vacant expression when mentioning the word flowchart; which is nothing more than the visual form of what any programmer should have going through their head (and on paper if they really want to limit mistakes).
I don't use flowcharts - they're less compact than text, so they hinder comprehension of complex pieces of code (it is a well-known fact that splitting text onto separate pages which need to be flipped back and forth significantly degrades speed and accuracy of comprehension - check any textbook on cognitive psychology). There were many graphical programming projects (this is a perinneal mania in programming tool-smith circles), none of them yielded any significant improvement in productivity or quality.
What I'd give to see a detailed flowchart for sendmail. I'd hang it on my walls (as I'm sure it'd take more than one).
Sendmail is a horrible kludge, and, frankly, I'm amazed that it is still being supplied as a default MTA with Unix-like OS-es.
Write a small program in C and then write it in Perl. ... Time both programs. For what it's worth, sorry Perl took so long.
Perl is interpreted, C is compiled. In fact, Perl is worse than C when it comes to writing reliable programs, for obvious reasons. If anything, I wouldn't advocate using any of the new-fangled hack-and-run languages for anything but writing 10-line scripts.
If a programmer can write a process in any language, then naturally the programmer should choose the language which provides the most flexibility, performance, and diversity; or the right tool.
A professional programmer will choose a language which lets him do the required job with minimal effort. Since quality is not generally a project requirement in this industry (for reasons I already mentioned) the result is predictable - use of languages which allow quick and dirty programming; getting stuff to do something fast, so it can be shipped, and screw the user, who is by now well-conditioned to do the three-finger salute instead of asking for refund. --vadim