The future according to Dennis Ritchie (a 2000 interview)

By Danny Kalev, LinuxWorld.com |  Development

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.



What is changing is that higher-level languages are becoming much more important as the number of computer-involved people increases. Things that began as neat but small tools, like Perl or Python, say, are suddenly more central in the whole scheme of things. The kind of programming that C provides will probably remain similar absolutely or slowly decline in usage, but relatively, JavaScript or its variants, or XML, will continue to become more central. For that matter, it may be that Visual Basic is the most heavily used language around the world. I'm not picking a winner here, but higher-level ways of instructing machines will continue to occupy more of the center of the stage.



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.

Resources



  • Dennis Ritchie's page at Bell Labs:

    http://cm.bell-labs.com/cm/cs/who/dmr/
  • Bell Laboratories:

    http://www.bell-labs.com/
  • Ken Thompson's page at Bell Labs:

    http://cm.bell-labs.com/cm/cs/who/ken/index.html
  • Bell Labs's Plan 9 page:

    http://plan9.bell-labs.com/plan9
  • A good Plan 9 FAQ with basic information:

    http://www.fywss.com/plan9/plan9faq.html
  • Vita Nuova's Inferno page:

    http://www.vitanuova.com/inferno/index.html
  • C9X information page:

    http://web.onetelnet.ch/~twolf/tw/c/c9x_changes.html
  • The C Programming Language, Brian W. Kernighan and Dennis M. Ritchie (Prentice Hall, 1988):

    http://cm.bell-labs.com/cm/cs/cbook/index.html
  • Brian Kernighan's page at Bell Labs:

    http://cm.bell-labs.com/cm/cs/who/bwk/index.html
  • Historical perceptions about the VAX architecture:

    http://cm.bell-labs.com/cm/cs/who/dmr/vax.html
  • A tribute to PDP-11 machines:

    http://www.psych.usyd.edu.au/pdp-11/
  • Audio file of further conversations with Dennis Ritchie:

    http://mithras.itworld.com/media/001021kalev_ritchie.ram

  • Join us:
    Facebook

    Twitter

    Pinterest

    Tumblr

    LinkedIn

    Google+

    DevelopmentWhite Papers & Webcasts

    See more White Papers | Webcasts

    Answers - Powered by ITworld

    Join us:
    Facebook

    Twitter

    Pinterest

    Tumblr

    LinkedIn

    Google+

    Ask a Question