C == Assembly

Last month John Gruber asked the question “Is C the new assembly?”

It’s a tough question – what, exactly, does ‘the new assembly’ mean? The first things that pop into my head when I think of assembly language are these:

1. Fast (or believed to be so)
2. Ugly and difficult
3. Nonportable
4. Foundation for other languages

C has all of these attributes. (And more!) But does it have these attributes in such a way that it can be called ‘the new assembly’? I think so.
Fast
Ever since the development of higher-level-langauges, programmers have tended to view assembly language as a Tool of Last Resort for when you need something to run blindingly fast. Though assembly language retains its place in the toolboxes of many programmers, it’s hardly the first thing which John Q. Coder will reach for to solve a problem. But thanks to the years of tweaks and optimizations made by truly intelligent people to gcc, C (under gcc) is the fastest programming language. Though several languages go faster in the right situations, “C” is nonetheless the byword for “fast” among high-level languages, like it or not.

Ugly and unpleasant

You can argue about why C is ugly, difficult, and unsafe all you like, but the fact remains – as jwz says, “C has all the expressive power of two dixie cups and a string.” When compared to the D language (which is as fast, if not faster), it’s hideous. There are no auto-expanding array types (even FØRTRAN had auto-expanding lists!) which makes it extremely difficult to create proper data structures without the use of pointers.

C’s string support is laughable – how in blazes are we supposed to use a language that doesn’t automatically understand that strings a) are more than just an array of one-byte characters and b) have an end? A well-crafted preprocessor statement stuck in the middle of some otherwise innocuous code can bring an entire codebase to its knees.

You can quantify a language’s simplicity of syntax by looking at the recommended coding standards. Python’s can be boiled down to “use clear_variable_names instead of bd_1s, don’t scre w a ro u n d with whites pace, and keep the documentation up to date.” C’s, on the other hand, are labyrinthine tomes full of references to implicit ints and nested includes.

Nonportable

The old axiom is true – C combines all the elegance and power of assembly language with the portability of assembly language. Here’s a fun idea for a drinking game:

1. Take a look through any reasonably complicated cross-platform and/or cross-architecture C library.
2. Take a drink every time you see one of these phrases:
   • “hack to make this work on $PLATFORM/$PROCESSOR”
   • “$PLATFORM doesn’t understand $NOUN, so we have to do this”
   • #if defined ($PLATFORMNAME) // $PROFANITY
3. Repeat steps 1 and 2 until insulin shock sets in.

And don’t forget the lovely fact that arguments to a function are evaluated in an order that depends on a) the compiler b) the compiler version and c) the processor architecture. One would think that the order of evaluation of the arguments to a function would be a critical part of a specification. One would be unpleasantly surprised to discover that this is not the case.

Foundation

The majority of high-level languages realize that using the wheel which C has “perfected” (I use the term in its loosest possible sense) is an acceptable compromise – after all, why not shift the responsibility for ensuring cross-platform compatiblity to the interpreter/compiler, not the programmer? The four programming languages with which I am most familiar – Ruby, Python, Objective-C and Java – are either based on or a superset of C.

Conclusion

Now, in the days of AJAX, Vista, OS X and Beryl/Compiz, assembly language is nearly forgotten. (I’ll leave discussions as to whether or not that is a good thing to people who know what they’re talking about.) Perhaps in the future C will be similarly forgotten; after all, Boo is based on Python.

Won’t it be strange if in twenty years we’re arguing over whether Python is the new C?

Strange, yes; unpleasant, no.