A Skill Instead of a Function

archive

In Cambridge in the early fifties, next to EDSAC, one of the first computers that actually worked, stood a steel cabinet of paper tapes. On each tape a small program was punched in holes, a program that could do one thing: compute a sine, extract a root, print a number nicely. If a problem needed a sine, the programmer took out the tape, mechanically copied it onto his own and returned the original to the shelf. In 1951 Maurice Wilkes, David Wheeler and Stanley Gill described this arrangement in the first programming textbook, and small programs that are inserted into large ones have been called subroutines ever since, and later functions.

The history of programming can be retold as the history of what is put into that cabinet. First functions were stored there, then libraries of functions, then whole services on other people’s servers: you send a request, and somewhere far away a payment is made, a text message is sent or you are told the weather. Each time, what lay on the shelf became larger and more independent. Now something is being put on the shelf for which the fifties would not even have had a name.

---

It is easiest to show on an invoice. The function createInvoice() creates an invoice if it is carefully given all the data in the right form. An application programming interface provides an address like /invoices where the invoice can be sent for storage. But a skill invoices the client, and that is a different verb altogether. It finds out who the client is and what his billing details are, gathers the line items from the work done, applies the company’s rules on discounts, taxes and terms, produces the document, sends it where the client will actually read it, remembers that the invoice has gone out, and, if the money has not arrived by the due date, sends a reminder by itself. Inside, it uses a dozen functions, a couple of outside services, memory and access rights, and from the outside it looks like a single action any accountant understands.