LinuxWorld.com: Five or ten years from now, will C still be as popular and indispensable as it is today, especially in system programming, networking, and embedded systems, or will newer programming languages take its place?
Dennis Ritchie: I really don't know the answer to this, except to observe that software is much harder to change en masse than hardware. C++ and Java, say, are presumably growing faster than plain C, but I bet C will still be around. For infrastructure technology, C will be hard to displace. The same could be said, of course, of other languages (Pascal versions, Ada for example). But the ecological niches you mention are well occupied.
LinuxWorld.com: What is your advice to designers of new programming languages?
Dennis Ritchie: At least for the people who send me mail about a new language that they're designing, the general advice is: do it to learn about how to write a compiler. Don't have any expectations that anyone will use it, unless you hook up with some sort of organization in a position to push it hard. It's a lottery, and some can buy a lot of the tickets. There are plenty of beautiful languages (more beautiful than C) that didn't catch on. But someone does win the lottery, and doing a language at least teaches you something.
Oh, by the way, if your new language does begin to grow in usage, it can become really hard to fix early mistakes.
LinuxWorld.com: C99, the recently ratified ANSI/ISO C standard, contains several new features, such as restricted pointers, variadic macros, bool, and new libraries for complex and type-generic arithmetic. Are you satisfied with C99?
Dennis Ritchie: I was satisfied with the 1989/1990 ANSI/ISO standard. The new C99 standard is much bulkier, and though the committee has signaled that much of their time was spent in resisting feature-suggestions, there are still plenty of accepted ones to digest. I certainly don't desire additional ones, and the most obvious reaction is that I wish they had resisted more firmly.
Of the new things, restricted pointers probably are a help; variadic macros and bool are just adornment. I've heard the argument for complex numbers for a long time, and maybe it was inevitable, but it does somewhat increase the cross-product of the type rules and inflate the library. One issue the question didn't mention is the introduction of the "long long" type and its implications, which is one of the more contentious issues in discussion groups about the language -- and it also makes the type-promotion rules much more complicated. But of course, 64-bit machines and storage are here, and it had to be faced.
I'm less ecstatic about the C99 standard, but don't denounce it. They did a pretty good job; C does have to evolve. I was not involved with its work, but was given opportunities to snipe or contribute earlier. So I won't do much second-guessing after the fact.
LinuxWorld.com: Considering proprietary languages such as Java and C#, was the decision to make C free deliberate? C users sometime complain that standardization bodies have no teeth and cannot force vendors to provide standard-compliant implementations. What is your preferred model of language development and standardization?
Dennis Ritchie: I can't recall any difficulty in making the C language definition completely open -- any discussion on the matter tended to mention languages whose inventors tried to keep tight control, and consequent ill fate.
I'm just an observer of Java, and where Microsoft wants to go with C# is too early to tell. Although Sun doubtless has spent more on Java as a strategic tool than would be justified simply by garnering some publicity for neat research work by Gosling and company, they've been quite open about the language specification as such. But of course they have been regarding the whole Java package (with libraries) as strategic versus Microsoft and other competitors.
True enough that standards bodies themselves have weak teeth, but they do have influence and importance when a language begins to be widely used. Partly this is simply because it does allow public comment, partly because it adds a certain gravitas to the project. If there is an ISO or ANSI standard, and you distribute a product that claims to conform, your customer has at least a hook for arguing to you when it doesn't.
On the other hand, the "open evolution" idea has its own drawbacks, whether in official standards bodies or more informally, say over the Web or mailing lists. When I read commentary about suggestions for where C should go, I often think back and give thanks that it wasn't developed under the advice of a worldwide crowd. C is peculiar in a lot of ways, but it, like many other successful things, has a certain unity of approach that stems from development in a small group. To tell the truth, I don't know how Linus and his merry band manage so well -- I couldn't have stood it with C.
This whole area is complicated and there is no single lesson to be drawn from its history, except that early and extreme attempts at close control are likely to be detrimental.
LinuxWorld.com: When will we have a C99-compliant edition of The C Programming Language? (See Resources for a link.)
Dennis Ritchie: This is a question about which Brian [Kernighan] and I have thought hard and long, with considerable advice and assistance via email, Usenet, visits from our publisher, and interviews like this one. And we're still thinking. We are prepared to announce that we have not committed ourselves either way.