My Life as a Quant (18 page)

When you program well, you are trying to design a machine to perform a task. You design with a man-made programming language—FORTRAN, Lisp, C++ or Java, for example. Programming is not that different from instructing a friend to perform a task for you. The big difference is that the computer is much more literal than any friend, and so every detail of the task must be specified as though the computer knows nothing about the world.

Until I arrived at the Labs in 1980, I had never realized how elegant and challenging programming could be. I had never used a computer terminal. During my student and postdoc years, all my programs had aimed merely to obtain the numerical values of complicated mathematical formulae, over and over again; I thought of the computer as a glorified adding machine. My only exception had been at the University of Cape Town, in 1965, when I used punched cards to enter a vocabulary into the machine and then created randomly generated short poems. I had always thought of that effort as a childish lark.

But at AT&T in 1980, the whole firm was embracing C, the simultaneously graceful and yet practical language invented by Dennis Ritchie about ten years earlier at Murray Hill. He had devised C to be a high-level tool with which to write portable versions of UNIX, the operating system also invented there by Ken Thompson and Ritchie.
2
Now, everything from telephone switching systems to word-processing software was being written in C, on UNIX, all with amazing style. Eventually, even physicists, who are generally interested only in the number of digits after a decimal point, began to forsake ugly utilitarian FORTRAN for poetically stylish C. Programming was in the late stages of a revolution about which I was just beginning to learn.

The revolution's credo demanded that programs be humanly comprehensible texts of information. This had not always been the case; because programs had to be stored in expensive and limited computer memory, programmers had traditionally concentrated on making them as concise as possible. They bragged about writing “tight” code that was terse, condensed, and cryptic, even confusing. It was OK as long as it ran fast, the thinking went; style was almost irrelevant and content was king. Programs were therefore error-prone as well as hard for humans to understand and modify—implicitly, they were written for the computers that would mechanically execute their commands. Hard to create, programs tended to have surprisingly long subsequent lifetimes during which they required expensive maintenance, modification, and enhancement. This was the set of circumstances that caused the anxiety behind Y2K.

What are you doing when you program? You are trying to use a language to specify an imagined world and its details as accurately as possible. You are trying to create this world on a machine that can understand and execute only simple commands. You do this solely by writing precise instructions, often many hundreds of thousands of lines long. Your sequence of instructions must be executed without ambiguity, by an uncomprehending automaton, the computer, and yet, in parallel, must be read, comprehended, remembered and modified by you and other programmers. Just as poetry strives to resolve the tension between form and meaning, so programming must resolve the conflict between intelligibility and concision. In this endeavor, the language you employ is critically important.

At the Labs, one regarded code-writing itself as a task in need of tools. They encouraged programmers to view each specific program they tackled as an instance of a class of more generally useful programs, and then to use the computer to create that class. They devised programs to write part or all of their programs. The UNIX community at the Labs had created, out of love rather than duty, a suite of editorial and analytical tools to help write, examine, and modify their programs. Thompson and Ritchie's UNIX programming environment used the computer not merely as the automaton to execute the program, but, just as importantly, as the tool to create it. The computer was not just the hammer, but also the forge with which to create the next-generation hammer.

Bell Labs Members of Technical Staff didn't just churn out programs; instead, they thought about the subtasks (reading input, solving equations, formatting output, for example) that the program needed to do. Then, they wrote little, special-purpose programming languages that could be used to generate these subunits of the larger program. Finally, they used these little languages to create the entire program itself. They were always generalizing from tasks to tools.

Because AT&T was a regulated utility, forbidden from making a profit by selling software in competition with IBM and Digital, the Labs distributed these tools freely to universities. This dissemination produced an entire generation of programmers who thought of programming not as a chore, but as a literary endeavor with the computer as medium. How lucid, elegant and structured your program looked was as important as how efficiently it ran.

Kernighan and Plauger wrote a famous and influential book in the 1970s called
The Elements of Programming Style
, its title a homage to Strunk and White's classic monograph on writing well,
The Elements of Style
. They were part of a movement that perceived programming and code development as art.

This culture was already widespread when I arrived at the Business Analysis Systems Center. All new employees learned UNIX and its Bourne-shell scripting language, as well as C for programming, the S language for statistics, and the line-formatting text editor
ed
. I remember the excitement of learning to use Bill Joy's visual text editor
vi
shortly after it was released. To their credit, the Center organized a sequence of master's-equivalent courses on computer science, taught mostly by professors from Columbia University in New York City. I learned software design and algorithms from John Kender, a mild-mannered, low-key expert on vision software; we learned database theory from David Shaw, who later founded the investment boutique D. E. Shaw & Co., as well as the first free email service, Juno. At D. E. Shaw, David employed Jeff Bezos, who later left to found
Amazon.com
.

David was already a free-wheeling entrepreneur. He had run a software company while studying computer science at Stanford; when I met him he still radiated a sloppy academic demeanor that didn't completely jibe with his business-oriented self-assurance. He was an early incarnation of the now ubiquitous capitalist academic. In his back trousers pocket he carried his appointments in a small leather DayTimer that had conformed to the shape of his body. The book had been manufactured in Pennsylvania and was very American middle manager, with its one-month spiral-bound inserts with space for lists of Appointments and Things To Do. It looked very unprofessorally businesslike, an early precursor of soon-to-arrive European Filofaxes and, a decade later, American Palm Pilots.

David clearly thought big. In those days he was planning what he called “NonVon,” a parallel-processing computer comprised of many small processors and memory units. It was to be the antithesis of the standard computer with one large central processor, a design that had prevailed since John von Neumann and the ENIAC computer of the 1940s. David's confidence inspired fear and envy. John Kender complained half-jokingly to me that while he and the other assistant professors in the tenure race at Columbia were trying to get modest government grants to do their work, David was always talking about ambitious proposals on a much larger scale, with plans for NonVon eventually to require a staff of tens to hundreds. John thought he and his colleagues had no chance of tenure in comparison with David's broad vision and unquestioning self-confidence that bordered on braggadocio.

John was right about David's capacious
weltanschaung
, but wrong about his exact path to glory. David left Columbia soon afterwards and went to work in Nunzio Tartaglia's fabled group at Morgan Stanley, doing pairs trading.
3
When that effort eventually ended, he created D. E. Shaw & Co. His new firm touted itself as specializing in the interaction between technology and finance, nurturing their reputation as secretive builders of high-powered computer systems used to seek out trading opportunities.
Fortune
magazine in 1996 referred to it as “the most intriguing and mysterious force on Wall Street today.” I knew hiring managers on Wall Street who interviewed anyone from D. E. Shaw, if only to find out what went on in its obscure depths. But most Shaw employees you interviewed didn't know much about how things worked there. In 1997, when I was invited to introduce David as the luncheon speaker at a conference, I said that “. . . you could think of D. E. Shaw & Co. as the Batcave, with David as Batman, watching the world, himself visible only through a glass, darkly.” But building a riskless money machine, especially on a large scale, is not that easy. There are not that many riskless profits to be harvested in the world. Eventually the struggle to make the same return on larger amounts of capital makes ever-riskier strategies tempting. In 1998 D. E. Shaw & Co., in partnership with the Bank of America, reportedly lost close to a billion dollars on the same sorts of strategies that decapitated Long Term Capital Management and took appreciable pounds of flesh out of many other hedge funds and investment banks.

Meanwhile, in 1981, I attended the computer science courses offered by the Labs and learned the practical art of programming. I was especially entranced by language design and compiler writing, and spent most of my time creating specific little languages that allowed users to solve specialized problems.

In high-level languages like Java, C, or even ancient and despised FORTRAN, you can easily write brief, sophisticated commands that instruct the computer to carry out complex operations. You can program in a style that corresponds rather closely to the way an educated person thinks or talks about mathematics. But a computer's central processing unit, the primitive brain that actually performs the logical and mathematical operations, is an
idiot savant
that has been engineered to “understand” and respond only to simple babytalk. It is as though you want to tell a small child who grasps only baby talk (but has a very good memory for long sequences of it) to take the dog for a walk. You cannot just say “Take the dog for a walk!”This assumes too much knowledge of the world. Instead, you must translate that high-level, big-picture command into a corresponding list of very elementary sequential actions, each describable in baby talk. You must say something like:

Fetch the dog;

find the leash;

tie the leash to the dog's collar;

hold the leash tightly;

open the front door;

follow the dog for five minutes;

if the dog steps off the sidewalk, pull him back using the leash;

. . .

return to the front door;

enter through the door;

unleash the dog.

If you design a high-level language that allows its users to issue sophisticated commands such as “Walk the dog,” you must provide a compiler that translates these commands into the baby talk machine code that the central processing unit can follow. Clearly, one mistake in translation, or just a little lack of specificity, and the dog and child will never return!

When John Backus and his team at IBM invented FORTRAN as a “FORmula TRANslation” language in the late 1950s, they wanted to allow programmers to manipulate complex mathematical formulas. Their compiler had to
automatically
translate any FORTRAN command into a sequence of the baby talk machine code that the simple logical computer circuits could follow. The compiler had to not only translate reasonable commands into baby talk; it also had to refuse to translate unreasonable or nonsensical ones. It had to to shout “Foul!” if you asked it to compile the command “Dog the! for take walk.” In brief, it had to comprehend grammar.

Grammar is the set of rules that legitimate sentences must satisfy. Adults recognize grammar intuitively, without thinking, but computers must follow rules. Backus developed a mathematical formalism for describing and parsing grammars that facilitated the task of language translation. It worked well for simple programming grammars that are less complex and subtle than those expressing natural languages. Backus's formalism, called BNF for Backus Normal Form, provided a methodology for creating grammatically consistent computer languages, and paralleled similar discoveries by Noam Chomsky on generative grammars. Working with this formalism, I learned how to design small grammatically consistent computer languages.

BNF helped you to define the grammar of your computer language. It allowed you to create a compiler that would parse sentences in your language and accept only the grammatically correct ones. This was half the battle. The other half was to write the part of the compiler that translated each grammatically correct sentence into baby talk. This was painstakingly tedious and difficult; a mistake in translation is potentially fatal in a program that people rely on to do mathematics or control spacecraft.

The UNIX operating system was a breathtakingly liberating environment for program writers. It contained two of the most beautiful tools I had ever seen: they were called
lex
and
yacc
, and they allowed me to create compilers almost effortlessly.
Lex
was an abbreviation for “lexical analyzer.”
Yacc
stood for “
Y
et
A
nother
C
ompiler-
C
ompiler,” and was another of the cute acronyms that characterized many UNIX tools. You could use
lex
to create a subprogram that would recognize all the words in your language. You could use
yacc
to create another subprogram that would parse and recognize legitimate sentences, and then take the actions you deemed appropriate.
Lex
and
yacc
were “non-procedural” programs—you weren't required to write all the details of lexical analysis and parsing; instead, you simply told them
what
grammar you wanted to recognize, and they wrote a program to do it, using algorithms for matching patterns that went back to the computer pioneers Alan Turing and Stephen Kleene. With
lex
and
yacc
as aids, I learned to create my own computer languages.