I've written a little 'C' code, maybe ~9-10K lines, but found that, since it easily compiles code that has no chance of operating at all, because of its weak type-checking (or none) and all the other things that it doesn't do, that it's much easier and probably as sensible, to use other tools that help you a little more. I think the reason 'C' is so popular is because it is widely used in educational institutions, heaven knows why. Pascal was designed for education, and it does that pretty well. 'C', on the other hand, discourages rigor and discipline, both of which are necessary for any useful work.

Whe I was in college, nobody used such languages. We had Fortran and Cobol, and, of course, assembler. BASIC didn't yet exist. Many large computers used "characters" rather than words, wherein one had to specify in the instruction, what the associated data length and format was. Computers didn't have stacks, and a subroutine was often entered with an instruction such as JST (jump and store) wherein the current PC was incremented and stored at the entry point of the routine and subsequently used as a return path. On the last job I held as a programmer, we were denied the use of Fortran-IV because the "higher ups" didn't want application programmers having access to certain I/O devices, so we had to use Fortran-II, to which we users referred as "Threetran."

'C' may be useful for large programs (those exceeding 1 milion lines) but it's really only maintainable if it's thoroughly documented, with each and every statement bound back to the requirement that justifies it. I found that, since there are often many dozens of ways of expressing the same simple sequence, some "approved" and some not, it makes much more sense to use a more strongly self-enforcing tool. The thing that convinced me that extensive documentation is absolutely necessary was an experience I had with "updating" decade-old code of considerable size. I couldn't find two people who could agree on what even one page of that entire project's code was intended to do.

The inherent flexibility of a language can be its undoing. From the standpoint of the long term, that's 'C' for you. It sacrifices "keeping it afloat" later on for "getting it out the door" now, in a sense. It's easy for someone to write code that compiles, and, as a result, it removes one small obstacle from the equation, namely discipline.

If everyone used more or less the same subset of 'C' these matters wouldn't be such an issue. If everyone were disciplined enough to delay writing the code until the requirements were documented and signed, and then wrote the code to match the reuquirements, it wouldn't be so bad, but too much code is written before the requirements are agreed upon and too little of that code is justified.

The documentation is required becuase someone else will eventually have to fix the code.

No, the 'C' code I've written was not documented in the way I recommend, because I knew it would never have to be maintained, even by me, as its real effect was to convince me that 'C' was not a tool I'd find acceptable for use in profesisonal-quality work, and that was because it disocurages rigor and discipline.

RE