If C is so evil why is it so successful?

Chuck Guzis cclist at sydex.com
Wed Apr 12 13:20:11 CDT 2017

I think a better question is "Why do you choose to write C (or any other

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.


More information about the cctalk mailing list