?

Log in

No account? Create an account

Previous Entry | Next Entry

A rant on C

Back in "O week" when I was an undergraduate, the head of the Science Faculty announced a competition for the best essay on the topic of "What I would like to achieve in science". One of the entrants was a guy in my CompSci class called Zoltan. Now, I don't know if his essay won the competition but the odds weren't too bad at all as only three entries were eventually received. What Zoltan wanted to do was design a new computer language. One part of his essay sticks in my mind. He recognised that dreaming up a new language from scratch was an awesome task and proposed to base his new language on an existing one. "I chose C" he wrote.

Now for those of you more familiar with natural languages like English and Russian, the idea of creating a new language and getting people to accept it may appear preposterous. But new computer languages are being created all the time - although not as often as they once were - and new languages like Java (1994) and C# (2001) can achieve widespread acceptance very quickly. Computer languages are functional, designed to be understandable both by humans and machines.

At the time - we going back a long time here - C was a relatively new language, having been developed back in the 1970s and defined through its bible, The C Programming language by Brian Kernighan and Dennis Ritchie, which was published in 1978. In the 1980s, C migrated from the minicomputers to the desktops. As undergraduates we found C inviting as it combined power with speed and flexibility. In short, C was the hot rod of computer languages.

There are good reasons why we use C at work. To quote Bjarne Stroustrup:

  • C is flexible... The language has no inherent limitations that preclude particular programs from being written. [Although there are still certain things that must be written in assembler]
  • C is efficient... it is relatively easy for a compiler and/or programmer to efficiently utilise hardware resources for C programs
  • C is available... Given a computer, whether the tiniest micro or the largest super-computer, chances are that there is an acceptable quality C compiler available... [Chances are that every program running on your puter is written predominately or entirely in C.]
  • C is portable... A C program is not automatically portable from one machine to another nor is a port easy to do. It is, however, usually posible...

The business model of the company I work for is based on this. Sure, you could write write your own software that does the same job as our product - but that would cost money, both to write it and to maintain it; more money than our product costs. We don't need to develop anything, because it's already written, and we spread the maintenance load over many customers. The trick is to make the same software available on many platforms for many customers. Therefore, we do lots of ports - perhaps one or two every week.

Yet a lot of the effort and a considerable number of the problems plaguing the industry as a whole can also be tracked back to C. Due to its low-level nature, C has this tendency for even the simplest of programs to crash or run amok. Many of the computer security problems that you hear about are based on exploiting bugs of this nature. Trying to fix them is a constant challenge. Trying to avoid them has been no less difficult. It seems like the effort is making us rewrite large chunks of the standard library. The ease with which the language permits certain stupid mistakes forces us to write in a rigid style that has been found to avoid as many as possible.

Comments

( 3 comments — Leave a comment )
morgan_dhu
27th Aug, 2005 04:43 (UTC)
I used to program in C, about 15 years ago (I've long since moved out of the programming business and have no familiarity with more recent versions of C or any newer programming languages). In the financial industry, no less. One thing I remember is having to define arrays, ranges for loops, all sorts of things very strictly to avoid the demon rogue pointer problems.

But it sure made for writing elegant, compact, efficient code. I much preferred it over the other languages I knew - COBOL, BASIC, even Pascal.
hawkeye7
27th Aug, 2005 09:16 (UTC)
There are now three distinct dialects of C. The first is the old K&R dialect, s defined in their 1978 book (with a couple of additions, such as enums, that didn't make it to press time), which is sometimes known as traditional C. It is believed to now be extinct. The second is C89. This has officially been superseded by C99 in the eyes of the ISO (and therefore our ASO) but the new standard is not well supported at the present time and most compilers are for the C89.

This is a real pain, as the new language contains certain lessons learned the hard way. For example, at work I introduced snprintf, a C99 standard function that makes the powerful sprintf function less likely to overrun memory. Unfortunately, one of our most common compilers - Microsoft C - does not support it. I therefore ported it myself. Initially we only used it on platforms where snprintf was unavailable but then we found that some compilers were not correctly supporting C's rules for rounding decimal numbers (Microsoft's compiler doesn't do this either), resulting in our software sometimes giving different answers on different platforms, so the use of my version became more widespread.

I'm glad to hear that there is life after the programming business. It's very hard to imagine doing this sort of work for years on end.
morgan_dhu
27th Aug, 2005 18:44 (UTC)
I was working in traditional C, but It was already beginning to yield to other versions when I got out of the business.

And yes, there's definitely life after programming - but the interesting thing I've found is that the underlying and occasionally ancilliary skills of programming keep coming in handy in the oddest of situations. Logic, of course, but also the ability to break large tasks down into manageable linked functions. ;-)

You'd be surprised (or perhaps you wouldn't be) at how many people cannot analyse a task from that perspective, and hence spend far too much time floundering about.
( 3 comments — Leave a comment )