The connection between the language in which we think/program and the problems and solutions we can imagine is very close. For this reason restricting language features with the intent of eliminating programmer errors is at best dangerous.

The inability to isolate software components from each other is the main reason why many popular programming languages cannot be used for making robust system software. (page 32)

When we had no computers, we had no programming problem either. When we had a few computers, we had a mild programming problem. Confronted with machines a million times as powerful, we are faced with a gigantic programming problem.

For twenty years programming languages have been steadily progressing toward their present condition of obesity; as a result, the study and invention of programming languages has lost much of its excitement. Instead, it is now the province of those who prefer to work with thick compendia of details rather than wrestle with new ideas. Discussions about programming languages often resemble medieval debates about the number of angels that can dance on the head of a pin instead of exciting contests between fundamentally differing concepts. Many creative computer scientists have retreated from inventing languages to inventing tools for describing them. Unfortunately, they have been largely content to apply their elegant new tools to studying the warts and moles of existing languages.

I think that the key problem we face is unproductive ways of doing things. I don't think it’s the technical problem.

In addition to technical problems, systems also have organizational and logistical problems. Many different people may be involved over a wide physical or geographic coverage and over a long period of time. Many may work for different companies or organizations with different rules and methods of operating. Very many data and much knowledge are involved. The organizational problem concerns itself with the question of how all these people can work together most effectively for the common purpose.

Present-day applications are rather different in many respects. Present-day programs are often very large and are being developed by teams that collaborate over periods spanning several years. These teams may be scattered across the globe. The programmers are not the future users of the system they develop and they have no expert knowledge of the application area in question. The problems that are being tackled increasingly concern everyday life: automatic bank tellers, airline reservation, salary administration, electronic commerce, automotive systems, etc. Putting a man on the moon was not conceivable without computers.

Specifications evolve together with programs and programmers. Writing a program is a process of learning — both for the programmer and the person who commissions the program.

Computer scientists have so far worked on developing powerful programming languages that make it possible to solve the technical problems of computation. Little effort has gone toward devising the languages of interaction.

The system problem is essentially the problem of the limitation of analytical procedures in science. This used to be expressed by half-metaphysical statements, such as emergent evolution or ‘the whole is more than the sum of its parts,’ but has a clear operational meaning.

Perl is another example of filling a tiny, short-term need, and then being a real problem in the longer term. Basically, a lot of the problems that computing has had in the last 25 years comes from systems where the designers were trying to fix some short-term thing and didn't think about whether the idea would scale if it were adopted. There should be a half-life on software so old software just melts away over 10 or 15 years.

This is a thing that really scares me, are people developing large applications that they don’t understand.

I've noticed that just about every time I find a large program with known glitches that no one seems able to fix, that program is written in C and is likely written by a programming team in a remote location.

Indeed, one of my major complaints about the computer field is that whereas Newton could say, "If I have seen a little farther than others, it is because I have stood on the shoulders of giants," I am forced to say, "Today we stand on each other's feet." Perhaps the central problem we face in all of computer science is how we are to get to the situation where we build on top of the work of others rather than redoing so much of it in a trivially different way. Science is supposed to be cumulative, not almost endless duplication of the same kind of things.