If C is so evil why is it so successful?

I think a better question is "Why do you choose to write C (or any other language)?" I can speak for myself--I can't say for sure, but I've written at least hundreds of thousands of line of assembly (not "assembler", please!) language, much of it on mainframes, back when mainframes were fairly slow and code needed to be compact and fast. You do develop discipline in coding, realizing the payoff when someone drops a 6" thick assembly listing on your desk with the attached yellow sheet that says "There's a problem somewhere in this; please fix for Friday's build." I'd had a brush with another systems programming language, CDC SYMPL, which resembled PL/I, but it was nascent and not entirely accepted by management at the time. FORTRAN was used for quite a few system utilities and, of course, bits of the FORTRAN compiler itself. When I moved to the then-new Intel 8080, there were only about two choices (other than straight machine code, which I've also used on older machines); assembly and PL/M (from Intel). PL/M was great for "quick and dirty" programs, but your polished code and final product usually turned out to be assembly. The 8080 was slow and memory was expensive. In the late 70s, I became acquainted with K&R C and thought it was a good idea. But C on the 8-bitters, particularly the 8080 didn't fare well in either speed or memory. Trying to deal with on-stack local variables on architecture with no stack-relative addressing was a nightmare. The z80 was better for this. When the 8086 and Microsoft came along, the picture changed dramatically. You pretty much had to have Lattice C if you were an OEM developing your own custom adaptation of MS-DOS--and if you were going to use Xenix, C was part of the package. I still wrote some assembly, for obvious reasons; i.e, you can't get to some machine specific features without it, but more of my code became an admixture, with much of the assembly being inline code, rather than separate assemblies. One drawback of C was (and still is) the weak preprocessor, which pales in comparison to that of, say, PL/I. Small MCU programming took me back to assembly, which was a strange experience, as most MCU (e.g. AVR, PIC 8-bit) assemblers are pretty brain-dead when compared with full-featured relatives. I'm currently doing a lot of ARM programming and wouldn't even consider assembly, unless it was for a single instruction or two. If carefully coded, C is quite portable (note the big "if"). I've written C++ also, when it seemed to be logical. For me, the point of OOP is object reuse and much of my work involved one-time applications. So I still fall back to C. One good or bad thing about C is that it removes uncommon features, so that you don't get access to the parity branches or the special instructions (e.g. AAM) which does enhance the portability of code. Could I do my work in Ada? Sure--I like the language. But the likelihood of finding a good, free Ada compiler for a specific platform can be fairly small. --Chuck