Digital Gold

The true nature of money has, through the centuries, been an inexhaustible source of puzzlement. This has abated somewhat in the Greenspan era when currency management sort of limped along by being conducted according to business as usual. Post Greenspan, the avalanche of crises triggered by the subprime debacle should have come as a wake-up call that business as usual is a recipe for disaster. But you wouldn’t guess so from The Economist’s Special Report on International Banking (May 17, 2008), which foresees return to “normal” after a “salutary dose of reality”. This underlines what many readers have noticed, namely that The Economist is not what its title suggests, but rather is The Voice of the Industry.

One of the ways in which The Economist affirms its orthodoxy is to state or suggest that only cranks entertain ideas like the gold standard or social credit. The Web is more rewarding in this respect. For example, the Wikipedia article (version of 080530) on the gold standard tells that Alan Greenspan, this pillar of orthodoxy, was once a proponent of its return.

Though the gold standard is a lousy system, it has the advantage of being a fruitful starting point in the search for something better. Business as usual does not have this property. The problem with the gold standard is that the money supply is rigidly equated to the amount of gold that circulates as coins or serves as back-up to paper certificates. In the 16th century, when the gold of the New World was imported into Europe, this gave rise to a large amount of inflation. In the 1930s the US economy required a larger supply of money than was available under the then reigning gold standard, thus aggravating the depression.

These problems suggested a monetary system in which economists determine the money supply needed by the state of the economy and in which governments have various means at their disposal to ensure that the actual money supply closely approximates this ideal. Both economists and governments like this idea: they are flattered by the power it ascribes to them.

This may have worked for a while, but since asset-backed securities, credit derivatives, and hedge funds neither governments, nor anybody else, has any idea what the money supply is. So there we are: equating the money supply to a gold reserve at a fixed price doesn’t work. Alternative ways of controlling the money supply, such as the M1 and M2 of yore don’t work. Isn’t there anything else?

There is a lot one can do nowadays with digital authentication techniques. It is time to investigate whether it is possible to implement digitally a collection of monetary certificates that is the equivalent of the Federal Reserve’s gold supply in the days of the gold standard. These digital techniques have been used for message authentication and digital signatures. It is worth investigating whether they can be used to create a digital one million dollar version of the hundred-dollar bill signed by the Secretary of the Treasury.

Specifications: the Good, the Bad, and the Ugly

One can define a prime number as an integer greater than 1 that has no divisors other than 1 and itself. This is a declarative definition: it says what a prime number is rather than how to get one. One can also appeal to the Sieve of Eratosthenes. This would be a procedural definition. It is the opposite of declarative and it only tells how to get prime numbers.

In Software Engineering it is considered bad form to specify a function by pseudocode or by a reference implementation; a proper specification is supposed to be declarative. This blanket preference for the declarative assumes that such specifications are always better: easier to understand and to write. This is indeed the case with prime numbers, but not always. In the case of the Reef Knot, the Bowline, or any other kind of knot, a declarative definition, though perhaps possible, is likely to be less useful than being shown how to make one, which is procedural. Here I consider an example where it is easy to compare the merits of the Good (declarative), the Bad (procedural), and an even less respectable third approach.

I remember Edsger Dijkstra (1930 – 2002)

In 1966 I became a PhD student of A. van Wijngaarden at the Computational Department of the Mathematical Centre in Amsterdam. Whatever my topic was going to be, it was clear that my job would be to program. There used to be one computer, the Electrologica X1. Shortly before my arrival a much faster and bigger successor was added: the X8 from the same manufacturer. The language was Algol 60.

Most organizations have a strong attachment to a single programming language. At the Mathematical Centre this attachment was even stronger than usual. My new colleagues proudly pointed to the cover of the Revised Report on the algorithmic language Algol 60, which showed van Wijngaarden among the members of the committee that had defined the language. Moreover, they told me, as soon as the report was finalized early 1960, a race was on between Peter Naur and his team at Regnecentralen in Copenhagen and Dijkstra at the Mathematical Centre; upon which Dijkstra vowed not to shave until the project was finished; upon which Dijkstra finished the compiler by himself in six weeks, in assembler, on the fly inventing new compilation techniques (such as required for Call By Name), handily beating the Regnecentralen team.

“Beauty Is Our Business”?

Note the carefully engineered punctuation in the title. The quotes indicate that the assertion therein contained is not mine; the question mark is there to indicate that I’m not sure I agree.

Though the quoted assertion may suggest it comes from some Association of Cosmeticians, I got it from the cover of the festschrift in honour of Edsger W. Dijkstra, the programming guru who died in 2002.

Dijkstra believed that

• programming should be like mathematics, and that
• beauty is the business of mathematics.

In his writings and in his lectures, Dijkstra held up mathematics as a prime example of the kind of beauty that he strived for in his own programming and that he found lacking in the work of those who program for pay.