programming is terriblelessons learned from a life wasted

A Million Random Digits with 100,000 Normal Deviates, from 1955

Early in the course of research at The RAND Corporation a demand arose for random numbers; these were needed to solve problems of various kinds by experimental probability procedures, which have come to be called Monte Carlo methods. Many of the applications required a large supply of random digits or normal deviates of high quality, and the tables presented here were produced to meet those requirements. The numbers have been used extensively by research workers at RAND, and by many others, in the solution of a wide range of problems during the past seven years.

Program design in the UNIX environment, by Pike and Kernighan

Much of the power of the UNIX operating system comes from a style of program design that makes programs easy to use and, more important, easy to combine with other programs. This style has been called the use of software tools, and depends more on how the programs fit into the programming environment how they can be used with other programs than on how they are designed internally. But as the system has become commercially successful and has spread widely, this style has often been compromised, to the detriment of all users. Old programs have become encrusted with dubious features. Newer programs are not always written with attention to proper separation of function and design for interconnection. This paper discusses the elements of program design, showing by example good and bad design, and indicates some possible trends for the future.

There is much to learn from UNIX, both the failures and successes. In particular this paper argues for small well defined functions which can be composed to build larger functionality, and against a slow and steady bloat of features — as Perlis said “If you have a procedure with 10 parameters, you probably missed some.”

Reflections on Trusting Trust, by Ken Thompson

As a programmer, I write programs. I would like to present to you the cutest program I ever wrote.

This is a classic paper on programming and security, about self referential programs called Quines. A quine is a program that outputs its source code

There is a trick to writing quines, so if you’ve never tried to write one, you might want to give it a try before reading this paper.

Quines come in many forms, some are a series of programs which output the next in sequence, like this famous perl spiral. Others are written in multiple languages, like this python and ruby quine I wrote. What Thompson does with their Quine is rather insidious, but I won’t spoil the fun

You once referred to computing as pop culture.

It is. Complete pop culture. I’m not against pop culture. Developed music, for instance, needs a pop culture. There’s a tendency to over-develop. Brahms and Dvorak needed gypsy music badly by the end of the 19th century. The big problem with our culture is that it’s being dominated, because the electronic media we have is so much better suited for transmitting pop-culture content than it is for high-culture content. I consider jazz to be a developed part of high culture. Anything that’s been worked on and developed and you [can] go to the next couple levels.

One thing about jazz aficionados is that they take deep pleasure in knowing the history of jazz.

Yes! Classical music is like that, too. But pop culture holds a disdain for history. Pop culture is all about identity and feeling like you’re participating. It has nothing to do with cooperation, the past or the future — it’s living in the present. I think the same is true of most people who write code for money. They have no idea where [their culture came from] — and the Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made. When was the last time a technology with a scale like that was so error-free? The Web, in comparison, is a joke. The Web was done by amateurs.

From Interview with Alan Kay, the second grumpiest programmer in the world. (The first is Ted Nelson).

Object-Oriented Programming Versus Abstract Data Types, by William R. Cook

This tutorial collects and elaborates arguments for distinguishing between object-oriented programming and abstract data types. The basic distinction is that object-oriented programming achieves data abstraction by the use of procedural abstraction, while abstract data types depend upon type abstraction. Object-oriented programming and abstract data types can also be viewed as complementary implementation techniques: objects are centered around the constructors of a data abstraction, while abstract data types are organized around the operations. These differences have consequences relating to extensibility, efficiency, typing, and verification; in many cases the strengths of one paradigm are the weaknesses of the other. Most object-oriented programming languages support aspects of both techniques,not a unification of them, so an understanding of their relative merits is useful in designing programs