 |
The future according to Dennis Ritchie
LinuxWorld.com 12/4/00
Bell Labs guru speaks on C's future, Plan 9, and more
Danny Kalev, LinuxWorld.com
Dennis M. Ritchie heads the system software research department at Bell Laboratories's Computing Science Research Center. | Advertisement | |
|
| >
Ritchie joined Bell Laboratories in 1968 after obtaining his graduate and undergraduate degrees from Harvard University. He assisted Ken Thompson in creating Unix, and was the primary designer of the C language. He helped foster Plan 9 and Inferno.
He is a member of the US National Academy of Engineering and is a Bell Laboratories Fellow, and has received several honors, including the ACM Turing Award, the IEEE Piore, Hamming, and Pioneer awards, the NEC C&C Foundation award, and the US National Medal of Technology.
LinuxWorld.com: Can you introduce us to Plan 9 (see Resources for a link), the project in which you're currently involved, and describe some of its novel features?
Dennis Ritchie: A new release of Plan 9 happened in June, and at about the same time a new release of the Inferno system, which began here, was announced by Vita Nuova. Most of the system ideas from Plan 9 are in Inferno, but Inferno also exploits the exceptional portability of a virtual machine that can be implemented either standalone as the OS on a small device, or as an application on a conventional machine.
As for Plan 9, it combines three big ideas. First, system resources and services are represented as files in a directory hierarchy. This comes from Unix, it is worked even better in Linux, but Plan 9 pushes it hardest. Not only devices, but things like Internet domain name servers look like files. Second, remote file systems -- likewise not a new or unique idea. But if all system resources are files, grabbing bits of another machine's resources is easy, provided the permission gods permit. Third, and unusual, is that the namespace -- the hierarchy -- of files seen by a particular process group is private to it, not machine-wide.
LinuxWorld.com: C and Unix have exhibited remarkable stability, popularity, and longevity in the past three decades. How do you explain that unusual phenomenon?
Dennis Ritchie: Somehow, both hit some sweet spots. The longevity is a bit remarkable -- I began to observe a while ago that both have been around, in not astonishingly changed form, for well more half the lifetime of commercial computers. This must have to do with finding the right point of abstraction of computer hardware for implementation of the applications.
The basic Unix idea -- a hierarchical file system with simple operations on it (create/open/read/write/delete with I/O operations based on just descriptor/buffer/count) -- wasn't new even in 1970, but has proved to be amazingly adaptable in many ways. Likewise, C managed to escape its original close ties with Unix as a useful tool for writing applications in different environments. Even more than Unix, it is a pragmatic tool that seems to have flown at the right height.
Both Unix and C gained from accidents of history. We picked the very popular PDP-11 during the 1970s, then the VAX during the early 1980s. [See Resources for links to both.] And AT&T and Bell Labs maintained policies about software distribution that were, in retrospect, pretty liberal. It wasn't today's notion of open software by any means, but it was close enough to help get both the language and the operating system accepted in many places, including universities, the government, and in growing companies.
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
Danny Kalev, a system analyst and software engineer with 12 years of experience, specializes in C++, object-oriented analysis, and design on various platforms, including Linux. Visit Danny's Linux Software Development discussion in the Linux forum, hosted on ITworld.com, and check out his Linux Tips and Tricks newsletter.
|
ITnews
Webcasts
