Programming – the profession, or even the social phenomenon, since much programming is done non-professionally by open source volunteers – has stabilized into a certain relationship between human programmers exercising expertise and creativity, and programming constructs which automate certain aspects of machine instruction. The most important question in programming right now is why this relationship has stabilized in this particular place, and how it might be moved to a new equilibrium.
To begin with I would like to back up my claim that the relationship has stabilized. Any comment on the programming phenomenon as a whole must of course be somewhat guarded. It is too large an arena to comprehend entirely. However, a certain level of confidence in its basic status can be achieved, based on the following observations:
1) Productive or useful innovations in programming can be and are disseminated quickly, often through open-source. Distributed version control is one recent innovation which has become significantly used within a short time of first being well implemented. This pattern can also be discerned in the rapid spread of programming languages, or programming paradigms such as “design patterns.” Programming is a field in which genuine innovations rapidly become available to all.
2) The problems which programmers face are persistent. Whereas a book outlining specific technological tools is quickly outdated in programming, a book outlining broad technical challenges, such as algorithms, data representation, security, or programmer collaboration, never seems to become obsolete. This phenomenon has been made a slogan within programming commentary – “there is no silver bullet.” In other words, no matter what technologies are used, certain problems can not be solved without serious application of human energy.
Between these two points, a picture of programming emerges of whose broad outlines we can be fairly confident: programmers eagerly take up new tools to help them in their task of instructing machines; but the state of available tools today can not be utilized by any programmer whatsoever to achieve qualitatively superior results to any other programmer who is competent in the field. In other words, the present relationship between programmer and programmable machine is in fact stable, and is dictated by the nature of programmatic constructs rather than individual programmer skill.
This second point above may at first seem like an eternal truth or truism, because it is such a commonplace within modern thought about programming, and because in any other industry it would be obvious (e.g., an artist’s tools can not make an artwork by themselves). But it is anything but a truism. Even the existence of any problem which is intractably difficult for programmatic automation, but yields to persistent human creative thought, was not obvious to early AI theorists. We presently seem to have settled upon a certain border beyond which computation can not pass – but our own existence demonstrates that there is some way past that border. Therefore we can reject immediately the attitude that this border is the obvious or natural sticking point for our relationship to programmable machines.
A second attitude is to suppose that there is some silver bullet, but it is out of our reach as programmers. That is, humans can think because they have something which can only be granted by computation many orders of magnitude greater than what we have access to – namely, the computational power of evolution. This explanation has the flavor of a post-hoc justification for our present status. There is no specific reason to believe that fundamentally new programmatic constructs require new kinds of computation. A serious inquiry into the problem might conceivably turn up such an impasse, but the possibility of failure is never an excuse not to move ahead.
The shape of our inquiry must therefore be guided by this question: What causes the current boundaries of our relationship to programmable machines, and how can those causes be addressed? This question will be taken up in my next post on the topic.
