Pat Hayes:
There's a persistent misunderstanding lurking here: that a program is like a recipe which the computer 'obeys' blindly. Some are like that, but others arent. [poetry deleted] They do all kinds of things in all kinds of machine architectures. ...Sam Salt:
Well I think some of this is giving unnecessary colour by the words chosen. I do not believe that programs 'learn', 'adapt', 'pounce' and so on, except by very broad analogy to how humans do these things. Programs mostly implement only three things (sequence, selection and iteration) by the way in which they can be pushed through a central processing unit(CPU) which only accepts inputs sequentially.As this seems to be an ongoing source of communicative difficulty, let me try to clarify what I meant. Many people have a more or less reductionist view of software; if one looks at it closely enough, it tends to look trivial or even to disappear. Searle goes all the way to the hardware and concludes that software only exists in the mind of the beholder, as it were [Note: this is not a philosophically accurate transcription of Searle's exact position, which would take too much room here and in any case is only mentioned for emphasis. One should read his book to get his full meaning. Back to Salt.] Salt, like many electrical engineers, stops at the processor circuitry. Even here he is is way out of date with 'sequence, selection and iteration', but never mind: the point is that all software can be implemented, ultimately, on very simple machines.
However it is not true to claim that programs only implement three things: this has 'implement' the wrong way around. The surprising thing about computers is precisely that such very complex behaviors can be produced from such relatively simple hardware, merely by adding more and more memory - itself fairly simple from an engineering point of view - and then by sending it messages down a telephone wire.
Most machines can be 'reverse engineered': once one understands how their components work and what they do, one can, by careful dissection, figure out how they do it. This might not be true if the machine used some kind of physical principle completely unknown to the dissector (imagine Isaac Brunel faced with a vacuum-tube radio), so if the operation is a total mystery then one might be tempted to invoke an unknown mysterious force or field to 'explain' how the thing works. (Does this remind one of any JCS discussions?)) Now, a sophisticated electronic engineer with no idea of software could figure out what a Mac was 'doing' at Salt's level of description, but she would have no idea how such a basically simple device could do such remarkable things (play chess, answer the phone, correct spelling mistakes, etc.) especially since these tasks seem to involve symbols and their meanings, rather than having anything to do with voltages or even numerals. One can't reverse engineer software from hardware, or even high-level software from lowlevel assembler language.
One reason this is so difficult is that Salt's claim is actually technically false. Much software doesn't run on the electronic hardware; it runs on one or another virtual machine which itself is implemented on another machine (at a 'lower level'). The term 'virtual machine' is a technical one, but these machines are just as real as any other machine, when running. These levels of inner machines can get extraordinarily complicated. Winograd's old language program, now considered somewhat primitive, had seven or eight levels of such interpretation between its code and the hardware machine. Much modern hardware has at least one level already encoded into the CPU chip itself, so what appears to be the hardware machine is in fact more correctly described as a virtual machine in RAM running on a simpler 'inner' electronic machine. (In these things, Salt's bottom level is only accessible by using an electron microscope.) The importance of this for the present discussion is that these intermediate machines can have quite different architectures from the electronic hardware. This is one reason why it is perfectly correct to say that programs do things which the hardware they are running on can't do. A trivial example is provided by LISP, which operates on arbitrarily long lists. Now, one can't actually build a physical machine which does that directly: but one can, with some ingenuity, implement such a machine on a machine with a simpler architecture.
And Salt is wrong: it is simply an objective fact that programs can learn and adapt, in the sense that their behavior alters as a direct causal result of the history of their interactions with their surroundings. The CPU doesn't change, but the software does. They can even alter themselves, so that after running for a while they are no longer what the programmer originally wrote, even at Salts' level. And they do 'pounce' (although I'll concede the scarequotes) in the sense that they lie passive watching complex inputs and react suddenly when certain conditions become true. (Such programs are used routinely to buy and sell stocks, for example, and brokers' fortunes depend on their millisecond response times.) Programmed machines operate in real time, a fact which escapes all Turing-machine models.
.... whether your high-level language is COBOL, a word-processing package or a genetic algorithm, the low-level implementation uses the same lowly sequential CPU.Yes, of course. This to be celebrated! Here we have a simple physical mechanism which can produce extraordinarily complex, symbolically significant, behaviors which can grow and change, without altering the machine at all! All it needs is more and more memory, which itself is a simple mechanism. Isnt this more like a brain that any other mechanism we have ever come across?
This is like asserting that every building is just a pile of bricks, steel and wood, when it comes down to it. Indeed, this is true in a sense, but not a very useful one. In particular, it doesnt follow from this that arches, domes, buttresses, walls, ceilings and other more architectural entities are not real, or do not play a significant role in maintaining the function of a building.
...... The practice of giving programs names such as genetic algorithms etc seems rather more to do with marketing and trying to make it sound good than the reality of what they really do. It seems rather like the anthropomorphising of animals.This is simply insulting to many of my colleagues who work (hard) in this area. Let me respond in kind: its a pity that someone who apparently has a post in a school of computing knows so little about the field he professes.
Pat Hayes
Phayes@uiuc.edu
jcs-online menu