Tue, 10 Aug 2004

Scripting versus C

In a recent article, Adrian asks why people like scripting languages. While exploring this, he says:

I don’t see why they should be considered the be all and end all solution that people seem to think they are.

The most common reason I hear people giving for why they like scripting languages is because they “just flow better”.

I’m not sure that I agree with either of these remarks. My experience with so-called scripting languages is that people use them when they are an appropriate tool for the task at hand. People in the Unix world have been writing scripts since long before Perl and other modern scripting languages were invented. Those scripts made sense then; they still do. But this doesn’t make scripting languages the be all and end all. And scripts are quicker to write than programs written in C or Fortran (and arguably perform rather different tasks).

These are quibbles, of course, and I agree with most of what Adrian says—at least if we exclude this:

I wouldn’t consider C an option unless performance was absolutely critical for server systems however because it leaves open the risk of buffer overruns and similar security holes that can be completely eliminated automatically by most other languages.

This is one of those popular “reasons” for eschewing C, but it’s only advanced by people who haven’t learned how to write C.

Already, there are probably plenty of people saying that they do know C and that I’m being arrogant or that I’m plain wrong.

Let’s consider this a bit. If somebody drops a copy of The Elements of Programming Style in front of me, open at one of the Fortran examples, and asks me to explain it, I’ll be quite able to provide the explanation and do it well enough that it appears that I know Fortran. And, to some extent, I do—it was the first “high level” language that I learned. But nobody in their right mind would hire me to write or maintain any serious program in Fortran. I’m just not up to it. Apart from reading examples in my favourite books, I haven’t done anything with Fortran since 1965.

Lots of people who claim to know C have skills on a par with my Fortran (or my Algol, to take another language that I once worked with). Those people do tend to write C with buffer overflows. After all, one of C’s strengths is its small size—anybody can learn all the C language in a few days; and can then start writing bad C programs immediately. And, because there’s a ton of bad sample code lying around to copy from, it’s a matter of moments to create a nice big broken C program.

But real C programmers don’t work that way. They have developed their own tool box of useful code over the years and they build their software from scratch, using their tools to make that process simpler. One of the utilities that every real C programmer has developed is a library that completely eliminates any possibility of buffer overruns. These are easy to write—after all the scripting languages are written in C and have these things—and are a good exercise for developing one’s skills with the language.

The fact that the roads are filled with people who have never learned properly how to drive and who go about killing themselves off in great numbers is no proof that cars are especially dangerous. Similarly, the fact that there are lots of examples of C code with buffer overruns is no proof that C is at fault. Both problems can be largely solved by suitable training. The obstacles to that are pretty similar, too.

And, while it’s true that many scripting languages will protect programmers from buffer overruns, it’s not true that they can turn bad programmers into good ones. Programming is hard. Software is almost infinitely malleable, but many of the shapes that it can adopt are not desirable. Bad programmers can write buggy code in any language.

The real strength of scripting languages is found in those languages that provide useful abstractions that allow the programmer to work towards the solution to a problem by writing fewer lines of code. The computer doesn’t give a toss what language we use, or how elegant our code is; it will digest it all. We write software in some chosen language because we need to be able to understand where we’re going with it; and because we want other people to be able to come along later and understand it. If a scripting language helps us do that better, it’s a good tool to use. If we later find that we have performance bottlenecks, we can use our profilers to measure things and then we can turn to more efficient tools like C to help us work around the problems. But we have to find people who really know C to do that.

Whatever language(s) we choose to use, we need to take the time to study the language, to develop real software with it, and to apply the many lessons of software design to the work that we do. The lessons come from good books—still regrettably much fewer in number than bad books—and from the study of good code and from mentors and colleagues; and many of the best lessons come from experience. No language will ever free us from the need to study and to work hard.

Posted at: 14:09

Path: /software/discuss   |  permalink