*Emanuel Derman (ED) wrote the excellent Being Foreign, Japan, and E Pluribus Unum Editions (amongst others). He grew up in Cape Town, South Africa, and came to Columbia University in New York to study for a PhD in physics. Since then he’s lived mostly in Manhattan. His memoir is My Life As A Quant.*

* Emanuel here. *I’ve programmed computers on and off for almost five decades. I started at the University of Cape Town during a summer research job in nuclear physics, using MAC, Manchester Auto Code, a FORTRAN-like language, on a British ICT 1301 to plot crude graphs from experimental numbers. One bored evening I got it to produce random five-line poems from words I had programmed it to print, not realizing that text manipulation rather than numerical computation might actually be a serious thing to do.

In those days you wrote your program on paper, line by line, composed like an essay, with an eraser. When you thought it was right, you had to punch the program, line by line, as coded holes onto cards using a keyboard that controlled a mechanical punch. To check for typos, you then put the cards into a verifier, on whose keyboard you typed the same instructions again and had the verifier check the match.

My next experience was in graduate school at Columbia, on an IBM 360. I wrote Monte Carlo programs to numerically evaluate integrals in formulas I had derived for my thesis on the observable effects of the standard model. I again wrote the program like an essay, punched cards, and submitted the card stack at night to the computer center which ran 24/7. The computer, rather than a verifier, found the typographical errors and then printed them out. If there had been a nonsensical typo it rejected the program. The next morning you got the results, corrected them, and resubmitted the next night.

A few years later I wrote more Monte Carlos as a postdoc at various different universities. By then, however, I had bought one of the first HP hand-held calculators, programmable in a crude kind of assembler language, and could check the output of my program in simple cases against that. I remember Columbia faculty members going to the Kiev particle physics conference in the early 1970s and taking expensive HP calculators to give to their Soviet physicist counterparts.

It was at Bell Labs in 1980 that I learned to use a computer terminal to type programs directly into a file on the computer rather than on paper. Now the computer could execute programs directly from the file, bypassing the cards. I learned to write programs in C and to manipulate, check and run them on a VAX or a SUN Workstation running UNIX. Until I arrived at the Labs, I had never realized how elegant and challenging programming could be. Programming then was in the late stages of a revolution that demanded that programs be humanly comprehensible texts of information.

The following is from a book I wrote about that era:

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.

What all of these languages—FORTRAN, C, the UNIX shell *sh* and its text manipulation tools such as *awk*, *vi *and *sed*—had in common was that they were *procedural*: you gave a series of commands in a procedure and ordered the computer to carry them out step by step.

**Why Is This Interesting?**

Recently I began to learn Mathematica, more recently renamed as the Wolfram Language, a system for doing symbolic mathematics as well as numerical computation. It has truly amazing facilities. I knew Stephen Wolfram, the author, as an immensely precocious Eton student when I was a physics postdoc at Oxford in 1976.

Mathematica knows almost everything about the language of much of math. And each year Wolfram and company add more math algorithms to it. Mathematica is a *functional* rather than procedural language, somewhat inspired by the early AI language LISP. In a procedural language, you specify, step by step, what the machine must do. You can, for example, write a statement that tells the program to simply go to another line in the program and execute that command, or to store a number in a certain memory register. These are actions without output.

In a functional language, in contrast, every statement is a function that takes input and transforms it into a different output, which in some generalized sense is what a program *in toto* is supposed to do A toy example would be the program statement y = SquareOf(3), which uses the function SquareOf(_)to provide the square of 3 as output and put the result in the variable called y. If you want to calculate the fourth power of 3 in this spirit, you would create the function for doing by writing y = SquareOf(SquareOf(3)).

Mathematica knows how to evaluate mathematical functions *f*(*x*,*y*,*z*,…), where*f*( ) is some arbitrary function such as *sin*( ) or a calculus derivative or integral. It can evaluate functions and functions of functions, and functions of functions of functions …

What’s subtle in Mathematica is that to get something calculated, you need to use Mathematica’s functions to create a more complex function that does what you need. You have to use its commands not so much to directly tell it what to do step by step, but rather to construct a mathematical text sentence that builds the function of functions you want. Once you’ve done that, Mathematica knows how to deal with it, even if it contains symbols rather than numbers. Its power is not just that it can carry out procedures or evaluate functions, but also that it understands (almost) all mathematical notation. It can do symbolic mathematics.

What Mathematica lacks for me is the easy human comprehensibility that modern programming style stressed when I first learned UNIX. Mathematica afiçionados tend to write one-line elegant but somewhat cryptic-looking functions of functions of functions to do their bidding. Here is a short simple example of nested functions, taken from Wolfram’s introductory book, that generates Pascal’s triangle:

The output of this function is

I find that doing simple things in Mathematica seems complicated. Its power and structure shine when it comes to doing complex things. To do that you have to start thinking of everything you want to do as a function that accepts input and produces output. My difficulties are likely in part a reflection of my relative novice status. Getting fluent in any new language takes time and an adjustment of your thinking style, and the more powerful and compact the language, the harder it is to read or write at the beginning. (*ED*)

**Quick Links:**

Quote Investigator on the Bezos what’s not going to change quote. (

*NRB*)Imagine your flexible office work future from Anne Helen Petersen (

*NRB*)

Thanks for reading,

Noah (NRB) & Colin (CJN) & Emanuel (ED)

—

*Why is this interesting? is a daily email from Noah Brier & Colin Nagy (and friends!) about interesting things. If you’ve enjoyed this edition, please consider forwarding it to a friend. If you’re reading it for the first time, consider subscribing (it’s free!).*