I remember the wars in the days of Pascal. The argument was thatcomputers should help you; that C was too dangerous a language. The twobig voices I remember were Wirth and Dijkstra. On the other side wasevery systems programmer I know, including me. I wrote everything in C.So C sort of steamrolled the zillions of languages back then.

The government tried to mandate Ada and they wouldn’t let contracts unless theywere in Ada. C steamrolled over those. It was just amazing. But as I look at itnow, I am still stunned almost every day that it borders on the impossible towrite a program of any real complexity in C and not have a security problem.The amount of care it takes for a programmer to never do a read into a bufferwithout explicitly making sure it can’t run over the end of the buffer, tonever free a block of memory at the wrong time so a pointer way elsewhere inthe program becomes stale, to never store something that’s the wrong size andhappens to step on the next value—those problems can be so hard to find.

It has been such a boon in systems programming. The idea that we wouldwrite our systems in assembler and all our applications in Pascal sent shiversdown my spine. I don’t think that was the right answer. But writing bothsystems and applications in C, I would have to say has proven just not towork very well. It’s just too hard.

It’s kind of like the problems we had with interrupt bugs. You could arguethat there’s no real magic in writing a program with sequence breaks orinterrupts. There’s no real problem with that. It takes a little bit ofunderstanding and a little bit of care. But I know for a fact that very goodprogrammers who understand all of that put those bugs in theirprogram. A programmer like me would have to come and fix it and Ihad to do the Niklaus Wirth–style thing of inventing the computer languagethat wouldn’t let them make interrupt bugs.

For the IMP system I wrote a complicated set of assembler macros, so youcould declare what you were doing. When you came in on an interrupt, youwrote a declaration that says, “I am on modem input” or “I am on the highpriorityclock or the low-priority clock.” And then when it assembled yourprogram, it actually tagged every instruction with which interrupt level itwas running on and then there was a postprocessor that I probably wrote inTECO macros, honest to God, that processed that and looked for timesharingproblems. It would look for a variable that was accessed by twodifferent levels and it would say, “There is an interrupt conflict.” Now all ofa sudden, the time-sharing bug would go away. Other programmers couldunderstand that if they put the right declarations in, these macros wouldkeep them from making timing bugs. I got a trip to Hungary to present howyou could get programmers who don’t really understand real-time issues tobe able to write solid real-time programs by using this technique to abstractout the conflict problems.

That’s a little bit the way I feel about C. I’m sure that there are goodprogrammers, perhaps including me, who can write good C programs. Butit’s just harder than it has to be. In the modern environment it’s gottenharder because the environment is so much more difficult—the number ofplaces where C’s weaknesses can be exploited or overlooked, the amountof care it takes. That’s one reason why I’m very comfortable writing in Perl.Perl is slow. I’m sure it’s one of the slower languages, but in essence itrepairs all of the security problems of programming in C. What happenswhen you index off the end of the array in Perl? It makes more array.

It knows what its pointers point to, so you can never misreference a pointerbecause you only say to go through it and it tells you where it’s going. SoI’m much more comfortable building security-necessary applications in Perlbecause I have a world full of Perl people pounding on the core and it’sbeen stable for so many years. I don’t think we’re going to find too manyallocate bugs or pointer bugs, and they’re hard to exploit from random Perlcode anyway. I don’t have to trust the programmers around me to getevery pointer check right.

And even then we get programs like the classic one where somebody wrotea web page that was looking up somebody in a table and some hacker putsomething in the input that looked like, “Joe;drop all tables.” That stillhappens. That’s obviously not C’s fault, but it shows programmers just can’tbe careful enough. They don’t see all the places. And C makes too manyplaces. Too scary for me, and I guess it’s fair to say I’ve programmed C onlyabout five years less than Ken has. We’re not in the same league, but I havea long track record with C and know how difficult it is and I think C is a bigpart of the problem.

As these applications get more complicated, and built on more and morecomplicated libraries—and nobody will ever understand the security cracksin the libraries because they’re so immensely complicated—probably we’llhave to move toward application-development languages that are morefault-free. Processors are becoming blindingly fast and memory is becomingridiculously cheap. I don’t know what tomorrow’s language is. I don’t thinkC or its derivatives such as C++ are going to really be the right vehicle forheavy-duty program application—even system development—goingforward.

Java didn’t feel right. My old reflexes hit me. Java struck me as tooauthoritarian. That’s one of the reasons why I mentioned that Perl felt sogood, because it’s got the safety and the checks but it is so damnmultidimensioned that the artist part of me has a lot of free board toexpress things clearly and to think about the right way to do things. I havesome freedom.

When I first messed with Java—this was when it was little baby language, ofcourse—I said, “Oh, this is just another one of those languages to helpnot-so-good programmers go down the straight and narrow by restricting whatthey can do.” But maybe we’ve come to a point where that’s the right thing.Maybe the world has gotten so dangerous you can’t have a good, flexiblelanguage that one percent or two percent of the programmers will use to makegreat art because the world is now populated with 75 million run-of-the-millprogrammers building these incredibly complicated applications and they needmore help than that. So maybe Java’s the right thing. I don’t know.

Seibel: When I spoke with Fran Allen, who worked at IBM on Fortrancompilers, she was quite upset about C from a completely differentperspective, which was it made it impossible to write really highly optimizingcompilers because it was so low-level.

Cosell: Now, she’s in a different camp. She’s working on compilers; shesees C as this awful, clunky step down that you can’t do anything with.Whereas we were working with bit-twiddling assemblers and C was like abreath of fresh air. So of course most of the very best programmers backthen were not the guys writing BASIC programs and not so much writingFortran programs doing calculations. The real heavy hitters were of coursethe guys doing all the assembly code. So we went to C because C was likebreath of fresh of air. If you think C has problems with array checks, trywriting your array loops in assembler. So in that regard, it was a great boon.

I don’t want to say that C has outlived its usefulness, but I think it was usedby too many good programmers so that now not-good-enoughprogrammers are using it to build applications and the bottom line is they’renot good enough and they can’t. Maybe C is the perfect language for reallygood systems programmers, but unfortunately not-so-good systems andapplications programmers are using it and they shouldn’t be.

Seibel: Do you think that the nature of programming has changed as aconsequence of the fact that we can’t know how it all works anymore?