We must not forget that it is not our business to make programs, it is our
business to design classes of computations that will display a desired behaviour.

--- Edsger Dijkstra, The Humble Programmer, ACM Turing Lecture 1972, published in Commun. ACM 15 (1972), 10: 859-866

In context:

I now suggest that we confine ourselves to the design and implementation of intellectually manageable programs. If someone fears that this restriction is so severe that we cannot live with it, I can reassure him: the class of intellectually manageable programs is still sufficiently rich to contain many very realistic programs for any problem capable of algorithmic solution. We must not forget that it is not our business to make programs, it is our business to design classes of computations that will display a desired behaviour.

[A]s long as there were no machines, programming was no problem at all; when we
had a few weak computers, programming became a mild problem, and now we have
gigantic computers, programming has become an equally gigantic problem.

--- Edsger Dijkstra, The Humble Programmer, ACM Turing Lecture 1972, published in Commun. ACM 15 (1972), 10: 859-866

Artificial intelligence has the same relation to intelligence as artificial flowers have to flowers.

--- David Lorge Parnas, Software aspects of strategic defense systems, Communications of the ACM, December 1985, Vol. 28, No. 12

In context:

Artificial intelligence has the same relation to intelligence as artificial flowers have to flowers. From a distance they may appear much alike, but when closely examined they are quite different. I don’t think we can learn much about one by studying the other. AI offers no magic technology to solve our problem. Heuristic techniques do not yield systems that one can trust.

Even in highly structured [software] systems, surprises and unreliability occur because the human mind is not able to fully comprehend the many conditions that can arise because of the interaction of these components.

--- David Lorge Parnas, Software aspects of strategic defense systems, Communications of the ACM, December 1985, Vol. 28, No. 12


In context:

Dividing software into modules and building each module of so-called “structured” programs clearly helps. When properly done, each component deals with a small number of cases and can be completely analyzed. However, real software systems have many such components, and there is no repetitive structure to simplify the analysis. Even in highly structured systems, surprises and unreliability occur because the human mind is not able to fully comprehend the many conditions that can arise because of the interaction of these components. Moreover, finding the right structure has proved to be very difficult. Well-structured real software systems are still rare.

I conjecture that most multi-threaded general-purpose applications are, in fact, so full of concurrency bugs that as multi-core architectures become commonplace, these bugs will begin to show up as system failures.

--- Edward A. Lee, professor of computer science, UC Berkely, in "The Problem with Threads,"
Technical Report No. UCB/EECS-2006-1, January 10, 2006

He continues:

This scenario is bleak for computer vendors: their next generation of machines will become widely known as the ones on which many programs crash. These same computer vendors are advocating more multi-threaded programming, so that there is concurrency that can exploit the parallelism they would like to sell us. Intel, for example, has embarked on an active campaign to get leading computer science academic programs to put more emphasis on multi-threaded programming. If they are successful, and the next generation of programmers makes more intensive use of multithreading, then the next generation of computers will become nearly unusable.

We understand complex things by systematically breaking them into successively simpler parts and understanding how these parts fit together locally. Thus, we have different levels of understanding, and each of these levels corresponds to an abstraction of the detail at the level it is composed from. For example, at one level of abstraction, we deal with an integer without considering wehterh it is represented in binary notation or two’s complement, etc., while at deeper levels this representation may be important. At more abstract levels the precise value of the integer is not important except as it related to other data.

--- Donald E Knuth, “Structured Programming with go to Statements,” Computing Surveys, Vol. 6, No. 4, December 1974, p. 291

Knuth goes on to provide an excerpt of Charles L. Baker’s 1957 review of McCracken’s first book on programming:

Break the problem into small, self-contained subroutines, trying at all times to isolate the various sections of coding as much as possible . . . [then] the problem is reduced to many much smaller ones. The truth of this seems very obvious to the experienced coder, yet it is hard to put across to the newcomer.

[Knuth’s citation: Baker, Charles L, “Review of D. D. McCracken, Digital Computer Programming,” Math. Comput. 11 (1957), 298-305]

The problem with being clever is you’re not

--- A saying among developers, reported by Adam Sapek, personal email, 15 April 2007

A civil engineer doesn’t rebel against gravity

- Adam Sapek, personal email, 17 april 2007, exploring why programming is not like engineering. In context:

"[Why is it so rare that software is built as predictably and reliably as bridges?] The first reason is that programmers realize that limitations are arbitrary and don’t like them. A civil engineer doesn’t rebel against gravity; for a programmer the equivalent is PHB ."

The desire to deal with the subject has been consistently less passionate than the desire to have it dealt with.

--- James Davidson, Reader in Dept. of Classics and Ancient History in the University of Warwick, on why received notions of homosexual practices in ancient Greece are so inaccurate, in "Greek Homosexuality," in Omnibus #53, January 2007 (ISSN 0261-507X). The Omnibus author's introduction notes that his book Courtesans and Fishcakes: consuming passions of ancient Athens "was a runaway sucsess with both specialists and non-specialists and received rave reviews in all sorts of newspapers that normal books about the ancient world don't reach."

Once you set an idea free to fly, you can’t control where it goes. And sometimes it comes back, lands on your shoulder and starts pecking at your eyes.

--- John Murrell, Second thoughts from a first-rate mind, Good Morning Silicon Valley, 3 April 2007, on Jim Watson's decision to allow publication of his DNA sequence

[A] list of technologies that, when they appeared, people said would "create peace" includes battleships, Alfred Nobel's explosives, the radio, the aeroplane, the atomic bomb, television and the internet.

--- David Edgerton, professor of history of science and technology, Imperial College, London, New Scientist opinion piece "The stuff of technofantasy" 29 January 2007

More from the piece:

We also underestimate the importance of some modern technologies and sciences. Take chemistry. It hardly figures in most accounts of 20th-century technology or science, and its absence is barely noticed. But omit computers, even from histories of the 1950s, and your account would be questioned. We can easily exaggerate the significance of technologies, and ignore some really important ones.

Globalisation has very quickly, and for no really good reason, become associated with the internet. We could as easily have had today's globalised world without the internet, but without cheap air travel - carrying people and some cargo - and cheap shipping - carrying most of the world's tradable goods and some people - it would hardly be possible. A type of globalisation driven only by the internet, had it happened, would surely not see so much stuff surging around the world.

. . . .

IKEA subverts the modern and postmodern notions of what we are technologically in another way: it has shifted part of the production and transportation of furniture away from specialist (employed) producers back to the household. The company has created a new middle-class urban peasantry which has to load, transport and build its own furniture, though in new ways, of course.

It is easy to visualise the shape of ordinary objects because you can look at them from the outside. You can pick up a cup, view it at different angles, feel its curves and surfaces, poke a finger through the handle. But we can't do this with the universe because we're stuck inside it - in fact, according to some definitions, it is all that exists. There are, however, still ways to feel its shape from the inside.

--- Simon Battersby, "Fold testament: The shape of the universe," New Scientist, 7 December 2006

Science forgets that it too is based on faith: in particular that the universe is an orderly place with rules; and that information received by our senses is true.

--- David Odell, letter to the editors, New Scientist, 19 Dec 2007

The rest of his letter:

Do these scientists really believe the cosmos is a replacement for God? Atheists will look at the cosmos and realise, as my science teacher says, that our lives are so insignificant; a religious person will look to the cosmos and be awed by (God's) creation. This is not a way to defeat religion.

Many scientific discoveries only make people more awed by their God. Why do scientists want to get rid of religion, when religion has driven scientists for hundreds of years?

I have learned by experience that when a book makes a sensation it is just as well to wait a year before you read it. It is astonishing how many books then you need not read at all.

--- W. Somerset Maugham, in the short story The Voice of the Turtle, in Collected Short Stories Vol 1, Penguin 1963

The moment programs grow beyond smallness, their brittleness becomes the most prominent feature, and software engineering becomes Sisyphean.

--- Jaron Lanier, Why Gordian Software has convinced me to believe in the reality of cats and apples [11.19.03], edge.org

In context:

"Ivan Sutherland, the father of computer graphics, wrote a program in the mid 1960s called "Sketchpad" all by himself as a student. In it he demonstrated the first graphics, continuous interactivity, visual programming, and on and on. Most computer scientists regard Sketchpad as the most influential program ever written. Every sensitive younger computer scientist mourns the passing of the days when such a thing was possible. By the 1970s, Seymour Papert had even small children creating little programs with graphical outputs in his computer language "LOGO". The operative word is "little." The moment programs grow beyond smallness, their brittleness becomes the most prominent feature, and software engineering becomes Sisyphean."