“There is no automatist revival in industry. There is one amongst people who wish to reduce every production process into a mechanical procedure.”
I’m not sure that claim would be entirely absurd.
In the software engineering business, there’s a subculture whose underlying ideology can be caricatured as “Programming would be so simple if only we could get those pesky programmers out of the loop.” This subculture invests heavily into code generation, model-driven architectures, and so on.
Arguably, too, this goal only sems plausible if you have swallowed quite a few confusions regarding the respective roles of problem-solving, design, construction, and testing. A closer examination reveals that what passes for attempts at “mechanizing” the creation of software punts on most of the serious questions, focusing only on what is easily mechanizable.
But that is nothing other than the continuation of a trend that has existed in the software profession from the beginning: the provision of mechanized aids to a process that remains largely creative (and as such poorly understood). We don’t say that compilers have mechanized the production of software; we say that they have raised the level of abstraction at which a programmer works.
Okay, but that point only concerns production of software, a relatively new “production output”. The statement (“there is no automatist revival in industry …”) would apply just the same to any factory, and ridicules the idea that there can be a mechanical procedure for producing any good. In reality, of course, this seems to be the norm: someone figures out what combination of motions converts the input to the output, refuting the notion that e.g. “There is no mechanical procedure for preparing a bottle of Coca-cola …”
In any case, my dispute with Callahan’s remark is not merely about its pessimism regarding mechanizing this or that (which I called View 1), but rather, the implication that such mechanization would be fundamentally impossible (View 2), and that this impossibility can be discerned from philosophical considerations.
And regarding software, the big difficulty in getting rid of human programmers seems to come from how their role is, ultimately, to find a representation for a function (in a standard language) that converts a specified input into a specified output. Those specifications come from … other humans, who often conceal properties of the desired I/O behavior, or fail to articulate them.
I’m not sure that claim would be entirely absurd.
In the software engineering business, there’s a subculture whose underlying ideology can be caricatured as “Programming would be so simple if only we could get those pesky programmers out of the loop.” This subculture invests heavily into code generation, model-driven architectures, and so on.
Arguably, too, this goal only sems plausible if you have swallowed quite a few confusions regarding the respective roles of problem-solving, design, construction, and testing. A closer examination reveals that what passes for attempts at “mechanizing” the creation of software punts on most of the serious questions, focusing only on what is easily mechanizable.
But that is nothing other than the continuation of a trend that has existed in the software profession from the beginning: the provision of mechanized aids to a process that remains largely creative (and as such poorly understood). We don’t say that compilers have mechanized the production of software; we say that they have raised the level of abstraction at which a programmer works.
Okay, but that point only concerns production of software, a relatively new “production output”. The statement (“there is no automatist revival in industry …”) would apply just the same to any factory, and ridicules the idea that there can be a mechanical procedure for producing any good. In reality, of course, this seems to be the norm: someone figures out what combination of motions converts the input to the output, refuting the notion that e.g. “There is no mechanical procedure for preparing a bottle of Coca-cola …”
In any case, my dispute with Callahan’s remark is not merely about its pessimism regarding mechanizing this or that (which I called View 1), but rather, the implication that such mechanization would be fundamentally impossible (View 2), and that this impossibility can be discerned from philosophical considerations.
And regarding software, the big difficulty in getting rid of human programmers seems to come from how their role is, ultimately, to find a representation for a function (in a standard language) that converts a specified input into a specified output. Those specifications come from … other humans, who often conceal properties of the desired I/O behavior, or fail to articulate them.