Interview with Brian Kernighan

Below, Aleksey Dolya interviews Brian
Kernighan, one of the creators of the AWK and AMPL languages and
someone who has seen the birth of UNIX and C.

Linux Journal: Could you
tell us a little about yourself?Brian Kernighan: I was born
in Toronto and went to the University of Toronto as an
undergraduate, in a course [of study] called Engineering Physics.
It was basically a lot of science, math and engineering for kids
who were good at math and thought they might be engineers but
didn't know what kind. It was a tough course, and about two thirds
of the people eventually dropped out, but I managed to survive and
learned a lot (a small amount of which I still remember).I didn't really know much about computers--this was in
1960-64--and there was only one big computer at Toronto, an IBM
7090, plus a small 1620 in the electrical engineering department. I
saw my first computer, an IBM 650, after my second year, and I
learned a bit of Fortran when I was in my third year. I spent a
summer writing Cobol for a big oil company (honest) after that. It
was enough to get me hooked on programming, though I sure didn't
know what I was doing and was a terrible programmer.At Toronto, I also did a senior thesis (a literature survey,
really) on artificial intelligence, which was showing all kinds of
promise in 1964. So I decided to go to graduate school, without
really knowing what that was all about. But it was easier than
looking for a job. I wound up at Princeton because they made a
better financial offer than any other school. I had a good friend,
Al Aho, who was already there; he had been one year ahead of me at
Toronto, in the same course.Princeton didn't have a CS department at that time, only a
group of good young people in electrical engineering, but I enjoyed
it and had a good time for several years before settling down to
work on a thesis. It was a very nice place to be a graduate
student.LJ: How did your life become
connected with computers?BK: I think the real turning
point was the summer of 1966, where through good luck I got a job
at Project MAC at MIT, [working] for Fernando Corbato. This was a
fantastic experience: I was using CTSS, which was the first general
purpose time sharing system and is still one of the nicest to use.
It was infinitely more productive than the punch cards I was used
to up to that point. I learned to program in MAD and wrote programs
to help collect information for the Multics machine; the first GE
645 arrived that summer. It was a wonderful place to live and work,
with great people (like Corby, who is still alive and active). It
was definitely one of the best times of my life.The next summer, probably because of the MIT experience, I
got a job at Bell Labs in the Computing Science Research Center.
This time I learned assembly language properly and met a bunch of
the people who I had heard of while at MIT (they also were working
on Multics). Another great summer.I went back to Bell Labs the summer after that. This time, I
got lucky and worked with Shen Lin, a great mathematician and
problem solver. Shen was interested in hard combinatorial
optimization problems, such as the Traveling Salesman Problem. I
had been working in a casual way on what came to be called the
graph partitioning problem for my Princeton thesis. Shen had an
idea of how to attack the general case, and I made the algorithm
work in a Fortran program. It became the core of my thesis, along
with some other special cases. Anyway, I had such a great time at
the Labs those two summers that when I finished my thesis early in
1969, I didn't even look for another job--I just went to the Labs.
I was lucky to be in the group that did UNIX and C and all of the
great things that came with them; that started just after I
arrived. In many ways it was the best computer science research
group anywhere, part of a large and productive research
organization, and it had an enormous influence on the world. I
stayed there until 2000, 30 wonderful years with an amazing group
of people.LJ: What is your work these
days? Do you like it?BK: While at the Labs, I
spent several semesters teaching, for example, at Princeton and at
Harvard. I really liked teaching and spent the academic year of
1999-2000 as a visiting professor in the CS department at
Princeton. Princeton offered me a permanent faculty position, and
after months of soul-searching on what should have been an easy
decision, I decided to retire from Bell Labs and become a full-time
professor. It's a very different job and role than what I was doing
at Bell Labs, but I love it, too, and am having the time of my
life. Princeton University is one of the best anywhere; the kids
are endlessly interesting and rewarding; my colleagues are
remarkable; and it's a nice community to be part of. I don't think
it would have been the right thing for me to do right after getting
out of school, but now it really seems perfect.LJ: What do you teach your
students?BK: One course is called
"Computers in our World". It covers how computers and
communications work, for a very non-technical audience; most of the
students are majoring in things like literature, politics, history
and other humanities disciplines. It's a lot of fun for me, because
I can talk about topics that show up in the newspaper every day
that have some computer component. (One I did not use this year but
could have: Dmitri Sklyarov and ElcomSoft. But I do talk about the
DMCA, a US law that definitely has both technical and political
components; that's the law that Sklyarov was charged with
violating.)Basically the course covers hardware (how computers work and
how they are built); software (algorithms, programming, languages,
systems, applications); and communications (Internet, Web,
cryptography, compression and the like). There are labs as well, in
which they create their own Web pages, do some simple programming
and experiment with sound, graphics and spreadsheets.The other course is called "Advanced Programming Techniques".
It's for CS majors and covers a bunch of topics related to how
software really is written: scripting languages, object oriented
programming in C++ and Java, user interfaces, network connections,
database access, components, patterns, and the like. The students
get to define and implement their own multi-person projects, so
it's also a taste of software engineering on a small scale, as they
worry about design, interfaces, testing, documentation, and even
doing demos and giving presentations.LJ: There are a lot of
different areas in today's IT world: platforms, OSes, languages,
hardware. In what areas do you consider yourself to be an
expert?BK: I used to be an expert
in document preparation systems, such as troff (which ran on UNIX),
and in tools for typesetting. I maintained and enhanced troff for a
long time, and I wrote a variety of other text processing tools,
including eqn, for typesetting mathematics. That was one major
piece of my research for a long time. I was also pretty
knowledgeable about such things as programming style, especially in
C. I'm not an expert in anything now, though. There are too many
things to know, and it gets easier to forget as one gets
older.LJ: What was your part in
the birth and destiny of the C language?BK: I had no part in the
birth of C, period. It's entirely Dennis Ritchie's work. I wrote a
tutorial on how to use C for people at Bell Labs, and I twisted
Dennis's arm into writing a book with me. But, if he had been so
motivated, he certainly could have done it without help. He's a
superb writer, as one can tell from the C reference manuals, which
are his prose, untouched. I've profited a great deal from being
part of the book, and I treasure Dennis as a friend, but I didn't
have anything to do with C.LJ: What do you think: is C
a high level language?BK: C is perhaps the best
balance of expressiveness and efficiency that has ever been seen in
programming languages. At the time it was developed, efficiency
mattered a great deal: machines were slow and had small memories,
so one had to get close to the efficiency of assembler. C did this
for system programming tasks--writing compilers, operating systems
and tools. It was so close to the machine that you could see what
the code would be (and it wasn't hard to write a good compiler),
but it still was safely above the instruction level and a good
enough match to all machines that one didn't think about specific
tricks for specific machines. Once C came along, there no longer
was any reason for any normal programmer to use assembly language.
It's still my favorite language; if I were marooned on a desert
island with only one compiler, it would have to be for C.LJ: You called C "the best
balance of expressiveness and efficiency". What about Pascal? There
are legions of Pascal programmers in the world. Is it less
expressive or less efficient than C?BK: I wrote a paper long ago
called "Why Pascal Is Not My Favorite Programming Language"--that
says it all. Pascal was perhaps okay as a teaching language, but in
its official standard form is not appropriate for writing real
programs.LJ: What were the AWK and
AMPL languages designed for? What is your part in their
design?BK: AWK was a joint effort
among Al Aho, Peter Weinberger and myself; the name is our
initials. I think it's fair to say we were pretty equal in our
contributions. Al knew all about regular expressions and the
pattern-action paradigm; Peter knew about report generation and
database issues; and I had a very clear idea of wanting to be able
to handle string and numeric values and conversions between them as
easily as possible. I'm pretty sure that Peter did the first
implementation (which only took a couple of days), aside from
regular expressions, which Al did; I have maintained and modified
it on my own since about 1980. We wrote the AWK book together in
1987.AMPL is a language for specifying optimization problems such
as linear programming. It acts as a sort of compiler, converting a
natural and convenient mathematical notation into whatever a
particular solver program needs. AMPL is joint work with Bob Fourer
and David Gay. Bob is in the Industrial Engineering and Management
Science department at Northwestern University; Dave was a colleague
in Computer Science at Bell Labs until he retired a year or two
ago. Bob had been interested in modeling languages for specifying
optimization problems for a long time. He spent a sabbatical year
at Bell Labs around 1984. Because I was interested in special
purpose languages (like AWK), he, Dave and I worked out the initial
design of AMPL and I wrote the prototype implementation. It was my
first C++ program, so although it was instructive, it probably
wasn't good. In any case, it did show that the language was useful
to a lot of people. Dave took over the implementation, and he has
completely owned that ever since. He and Bob are experts on
optimization; I am not. Essentially all of the current form of AMPL
is their work; I have been a member of the team only by courtesy
for a long time. (We did publish a second edition of the AMPL book
a couple of months ago; I worked on that with them.)LJ: Brian, what do you think
of UNIX? Is it a good and reliable platform for development?BK: I'm used to UNIX systems
that run for months or even years without crashing. If I were
developing UNIX software, there isn't any other choice. If I were
developing Windows software, then I would undoubtedly use Windows
if there were a graphical component or if it cared about the
operating system; otherwise I would use UNIX and port the program.
When I do Java, I often do a mixture, because the tools I prefer
[to use] run on Unix, but the graphical interfaces are more
responsive on Windows than through an X interface.LJ: What UNIX OSes do you
like? Linux? BSD?BK: The way I use them,
which is as a casual programmer, it doesn't matter--they are all
the same. If I encounter some difference, it only makes me mad,
because there really isn't any reason for things to be different
most of the time. I use Solaris at Princeton, Irix when I visit
Bell Labs, and FreeBSD on my Mac; I also have Cygwin on several PCs
so that standard tools are readily available.LJ: Is it true that you
suggested the name "UNIX" for the long ago OS, Multics? What does
that word mean?BK: Yes, long ago. Multics
was an acronym for something like Multiplexed Information and
Computing Service, and it was big and complicated because it had
many of everything. I suggested Unics for Ken's new system, because
it was small and had at most one of anything. (Multi and uni are
both Latin roots, so it was a very weak pun.) Someone else spelled
it with the letter X; no one can remember who.LJ: How do you find the
current situation in the world of IT monopolists? How do you feel
Microsoft's politics and products?BK: Like many people, I have
mixed feelings about Microsoft. They have done much good for the
world, producing a common environment that has enabled a lot of
creative people to build new software and hardware and sell it at
reasonable prices. Microsoft's work has made computing accessible
to a huge population who would otherwise not be able to use
computers. At the same time, I am unhappy with some of their
products. An operating system should not crash very often, if at
all, and the sheer complexity of both using and programming the
Windows environment is daunting.LJ: You are a well-known
expert in practical programming. Does it differ from theoretical
and research programming?BK: As the great American
philosopher Yogi Berra is reputed to have said, "In theory, there
is no difference between theory and practice. In practice, there
is." I'm not sure what theoretical programming might be, but code
that can't be executed on a computer is unlikely to work and thus
isn't terribly useful except as a thought exercise.Research programming might mean software written as a
prototype or [used] to verify that some concept can be made to
work. There, the difference is that one can cut lots of corners:
don't worry about errors, ignore potential hazards, provide no user
interface, skip documentation and, of course, do no maintenance. In
that sense, research programming is vastly easier than writing a
program that will be used by many people over a long period of
time. Someone (Fred Brooks, in The Mythical Man
Month, perhaps) once said that it is at least an order
of magnitude more work to do production software than a prototype.
I think he's wrong by at least an order of magnitude.LJ: How often have you
written code in the last few years?BK: Too infrequently,
unfortunately, except for small experiments, examples for my
courses and occasional maintenance of AWK. I did spend a fair
amount of time building various user interfaces for the AMPL
language--in Java, Tcl/Tk and Visual Basic--but none of these are
very big, and none are very satisfactory either. Last summer I
spent most of my time finishing off the second edition of our book
on AMPL, which didn't involve any programming either. So I'm hoping
to get back to doing more.LJ: What are your hobbies?
Reading? Sports?BK: Mostly reading; I read a
lot, mostly history and sometimes detective stories and
occasionally biographies. I used to ski a bit, played squash and
racquetball, and I once got a black belt in karate. But that was
very long ago indeed. Today my sports are restricted to taking long
walks.LJ: Could you say that you
love computers (IT)?BK: No. There was a time
when they were incredible fun to work with, and I really enjoyed
programming and getting the machine to do things, but it was never
my whole life. And modern systems are so messy and complicated that
they are more frustrating than rewarding most of the time. It's
still pretty easy to get completely wrapped up in trying to write a
program, though; that will always be fun.LJ: You have worked in Bell
Labs, alongside Bjarne Stroustrup, Ken Thompson and Dennis Ritchie.
What kind of relations do you have with them? Were you like a big,
wise family?BK: We were all friends and
close colleagues for many years, all in the same small group at
Bell Labs. Ken, Dennis and I are all about the same age, and we all
came to the Labs about the same time; Bjarne came 10 years later. I
wouldn't call it family, but it was definitely good friends, and I
miss seeing them all every day, which is the way it was for many
years.LJ: Could you make any
predictions about IT in the future? What programming languages will
we be using?BK: There are only two real
problems in computing: computers are too hard to use and too hard
to program. We've made enormous progress on both of these over the
past fifty years, but they are still the real problems. And I
predict they still will be problems 50 years from now. Of course,
we will be using machines far more powerful than today's, and our
languages undoubtedly will be more expressive. But we will be
undertaking far more complicated tasks, so the progress will not be
completely evident.I expect that much of the real progress will be in
mechanization: getting the machine to do more of the work for us.
There are many examples today--compilers, parser-generators,
application-specific languages, wizards, interface builders--all of
which create code for us more easily than we could do it manually.
This will keep getting better: as we understand some area so well
that it becomes almost mechanical to program for it, we will
mechanize the process. And, of course, the level of language will
continue to rise, as languages become more declarative ("do what I
want", rather than "do these particular steps") and as efficiency
is less of a concern for any particular aspect of a
computation.I'm less sure what will happen on the "easier to use" side,
however. Here the trend for the past 10 or 15 years has been
unsatisfactory. Computers are hard to use, even with ostensibly
friendly GUIs and assistants and the like. This is a real problem,
because computers are pervasive, and more and more all of us have
to deal with them in all kinds of settings, some critical (think of
flying a plane, where the "blue screen of death" takes on a whole
new meaning). We simply have to make better interfaces to
machines.LJ: Brian, thank you very
much. Good luck!Aleksey Dolya is a Russian
C/C++ programmer interested in network security and software
protection.

email: tanat@hotmail.ru