Toast to C

    <h4>By Jason – October 13, 2011</h4>
From: http://jasonvictordartmouth.posterous.com/a-toast-to-c

At
Cloudmetrx, we use a lot of C. So given the recent passing of UNIX
legend Dennis Ritchie, the creator of the C language, we think a toast
to C is only fitting.

Our extensive reliance on C is especially
unusual considering the other languages in our stack – Clojure, Node.js,
and other hipster platforms. We aren't predisposed to using older,
"venerated" technologies simply because they're older and venerated. But
when it comes to high-performant computation, there's just nothing like
C. Some will claim Java, but those people are incorrect. There's
nothing like C.

In my opinion, the reason C has maintained its
popularity for all these years is that it is relatively paradigm-free.
Most languages, for better or worse, come equipped with some inherently
recommended programming paradigm – object-oriented, functional,
whatever. The realities of the hardware, then, are sculpted to best
support that paradigm.

C, on the other hand, doesn't sculpt the
hardware. It gives you raw access to the hardware. You do what you wish
with the hardware. There is no inherent overhead due to your paradigm –
you are expected to enforce whatever paradigm you please by yourself.

C
is the Turing part of the Church-Turing Thesis. C basically gives you
math plus a ticker tape you can write onto. All algorithms revolve
around those two basic concepts: reading and writing to the tape, and
doing small mathematical operations.

As it happens, the universal
computing device referred to in the Thesis is implemented like Turing,
but often used like Church. The lambda calculus revolves around
meaningful and elegant representations of behavior, as it makes sense to
humans; but the Turing Machine represents behavior as it makes sense
for a machine based on transistors and electrons. It is the more natural
of the two; and so C is a more natural way to harness the power of the
actual hardware, at the expense of readability, and perhaps even
elegance.

It is quite a feat to create a technology still being
actively used decades after its inception and rise to popularity. I
don't think the only reason is that it is (relatively speaking)
paradigm-free. The syntax itself is also brilliant – as complex as the
language is, and as complex as managing memory is, C makes it
brilliantly clear what is going on. The C syntax has also influenced
other languages – from PERL to Java to JavaScript – a testament to its
clarity and usability.

And with all this power, C is still a joy
to write in. There's something special to me about cracking a 5-hour
energy and sitting down with <tt>vim</tt>
to hack some C. It's like
driving a manual car, and feeling the rush as you switch gears, going
faster and faster. After a month of Python, C drives like a BMW with a
rocket engine. The speed is facemelting; you run <tt>time</tt>
and your jaw drops at the results – a millisecond! For that? Amazing.

But C isn't always pretty. C can be a naughty girl that seg faults, leaving you in despair, confused, forced to use <tt>gdb</tt>
. But at the end of the day, you always come back to C – that seductress of speed. [Citation needed]

At Cloudmetrx, we use C for essentially all of our financial logic except bootstrapping
.
Without the ability to crank out a blindingly fast result in C, the
Real-Time Cloudmetrx product would likely be impossible, since we
wouldn't be able to use horizontal scale to handle the loads. And
indeed, the speed difference between a derivative pricing model – many
of which require Monte Carlo – written in C and a model written in Java
is noticeable. Not huge, but noticeable; and likely too big to serve
real-time financial analytics.

So here's to C, that naughty girl, that seductress of speed. Salud!


?