Nof S.Y. Springer Handbook of Automation

Подождите немного. Документ загружается.

305

What Can Be

18. What Can Be Automated?

What Cannot Be Automated?

Richard D. Patton, Peter C. Patton

The question of what can and what cannot be

automated challenged engineers, scientists, and

philosophers even before the term automation

was deﬁned. While this question may also raise

ethical and educational issues, the focus here is

scientiﬁc. In this chapter the limits of automation

and mechanization are explored and explained in

an effort to address this fundamental conun-

drum. The evolution of computer languages to

provide domain-speciﬁc solutions to automation

design problems is reviewed as an illustration and

a model of the limitations of mechanization. The

18.1 The Limits of Automation ...................... 305

18.2 The Limits of Mechanization.................. 306

18.3 Expanding the Limit ............................. 309

18.4 The Current State of the Art ................... 311

18.5 A General Principle ............................... 312

References .................................................. 313

current state of the art and a general automation

principle are also provided.

18.1 The Limits of Automation

The recent (1948) neologism automation comes from

autom(atic oper)ation. The term automatic means self-

moving or self-dictating (Greek aut

omatos) [18.1]. The

Oxford English Dictionary (OED) deﬁnes it as

Automatic control of the manufacture of a product

through a number of successive stages; the applica-

tion of automatic control to any branch of industry

or science; by extension, the use of electronic or

other mechanical devices to replace human labor.

Thus, the primarytheoretical limitof automationis built

into the denotative meaning of the word itself. Automa-

tion isall about self-moving orself-dictating as opposed

to self-organizing. Another way of saying this is that

the very notion of automation is based upon, and thus

limited by, its own mechanical metaphor. In fact, most

people would agree that, if an automated process began

to self-organize into something else, then it would not

be a very good piece of automation per se. It would per-

haps be a brilliant act ofcreating a new form oflife (i.e.,

a self-organizing system), but that is certainly not what

automation is all about.

Automation is fundamentally about taking some

process that itself was created by a life process and

making it more mechanical or in the modern computing

metaphor hard-wired, such that it can be executed with-

out any volitional or further expenditure of life-process

energy. This phenomenon can even be seen in living or-

ganisms themselves. The whole point of skill-building

in humans is to drive brain and other neural processes to

become more nearly hard-wired. It is well known that,

as the brain executes some particular circuit more and

more, it hard-wires itself by growing more and more

synaptic connections. This, in effect, automates a vo-

litional process by making it more mechanical and thus

more highly automated.Such nerve training isdrivenby

practice and repetition to achieve greater performance

levels in athletes and musicians.

This is also what happens in our more conscious

processes of automation. We create some new process

and then seek to automateit by making it more mechan-

ical. An objection to this notion might be to say that the

brain itself is a mechanism, albeit a very complex one,

and since the brain is capable of this self-organizing

or volitional behavior how can we make this distinc-

Part B 18

306 Part B Automation Theory and Scientiﬁc Foundations

tion? I think there are primarily two and possibly a third

answer to this, depending on one’s belief system.

1. For those who believe that there is life after death

it seems to me conclusive to say that, if we live on

then, there must be a distinction between our mind

and our brain.

2. For almost everyone else there is good research

evidence for a distinction between the mind and

the brain. This can especially be seen in people

with obsessive compulsive disorder and, in fact, The

Mind and the Brain is very persuasive in showing

that a person has a mind which is capable of pro-

gramming their brain or overcoming some faulting

programming of their brain – even when the brain

has been hard-wired in some particularly un-useful

way [18.2].

3. However, the utter materialist would further argue

that the mind is merely an artifact of the elec-

trochemical function of the brain as an ensemble

of neurons and synapses and does not exist as

a separate entity in spite of its phenomenological

differences in functionality.

In any case, as long as we acknowledge that

there is some operational degree of distinction be-

tween the mind as analogous to software and the

brain as analogous to hardware, then we simply can-

not determine to what extent the mind and the brain

together are operating as a mechanism and to what

extent they are operating as a self-organizing open

system. The ethical and educational issues related to

what can and cannot be automated, though important,

are outside of the scope of this chapter. Readers are

invited to read Chap.47 on Ethical Issues of Automa-

tion Management, Chap.17 on The Human Role in

Automation,andChap.44 on Education and Qualiﬁca-

tion.

18.2 The Limits of Mechanization

So, another way of asking what are the limits of au-

tomation is to ask what are the limits of mechanization?

or, what are machines ultimately capable of doing

autonomously? But what does mechanical mean? Fun-

damentally it means linear or stepwise, i.e., able to

carry out an algorithmically deﬁned process having

clear inputs and clear outputs. The well-known Carnot

circle used by the military engineer and founder of

thermodynamics L.N.S. Carnot (1796–1832) to de-

scribe the heat engine and other mechanical systems

(Fig.18.1) separates the engine or system under study

from the rest of the universe by a circle with an ar-

row in for input and an arrow out for output. This is

a simple but powerful philosophical(and graphical) tool

The rest of the universe

The system

under study

OutIn

Fig. 18.1 The Carnot circle as a system deﬁnition tool

for understanding the functions and limits of systems

and familiar to every mechanical and systems engi-

neer. More complex mechanical processes may have to

go beyond strictly linear algorithmic control to include

negative feedback, but still operate in such a way that

they satisfy a clear objective function or goal. When

the goal requires extremely precise positioning of the

automation, a subprocess or correction function called

dither is added to force the feedback loop to hunt for the

precise solution or positioning in a heuristic manner but

still subsidiary to and controlled by the algorithm itself.

In any case, mechanical means non-context-sensitive

and discrete, even if it involves dither. Machine the-

ory is basically the opposite of general system theory.

And by a general system we mean an open system, i.e.,

a system that is capable of locally overcoming entropy

and is self-organizing. Today such systems are typically

referred to as complex adaptive systems (CAS).

An open system is fundamentally different from

a machine. The core difference is that an open system

is nonlinear. That is, in general, everything within the

system is sensitive to its entire context, i.e., to every-

thing else in the system, not just the previous step in

an algorithm. This is most easily seen in quantum the-

ory with the two-slit experiment. Somehow the single

electron is aware that there are two slits rather than

one and thus behaves like a wave rather than a particle.

Part B 18.2

What Can Be Automated? What Cannot Be Automated? 18.2 The Limits of Mechanization 307

In essence, the single electron’s behavior is sensitive

to the entire experimental context. Now imagine a hu-

man brain with 100billion neurons interconnected with

some 100trillion synapses, where even local synaptic

structures make their own locally complex circuits. The

human brain is also bathed in chemicals that inﬂuence

the operation of this vast network of neurons whose re-

sultant behavior then inﬂuences the mix of chemicals.

And then there are the hypothesized quantum effects,

giving rise to potential nonlocal effects, within any par-

ticular neuron itself. This is clearly a vastly different

sort of thing than a machine: a difference in degree of

context sensitivity that amounts to a difference in kind.

One way toillustrate thismathematically is to deﬁne

a system of simultaneous differential equations. Denot-

ing some measure of elements, p

(i =1, 2,...,n), by

, these, for a ﬁnite number of elements and in the

simplest case, will be of the form

/dt = f

, Q

,...,Q

)

/dt = f

, Q

,...,Q

)

...

/dt = f

, Q

,...,Q

) .

Change of any measure Q

is therefore a function of

all Q, from Q

to Q

; conversely, change of any Q

entails change of all other measures and of the system

as a whole [18.3].

What has been missing from the Strong Artiﬁcial

Intelligence (AI) debate and indeed from most of West-

ern thought is the nature of open systems and their

propensity to generate emergent behavior. We are still

1st Generation

Machine code

2nd Generation

Assembler

Machine specific symbolic languages

≈10× over 1st generation

Allowed complex operating

systems to be built – cost was built

into hardware price.

3rd Generation

High level language

C, COBOL, FORTRAN

≈10× over 2nd generation

Allowed for independent software

companies to become profitable.

4th Generation

High-level language integrated with

a (virtual) machine environment

Visual Basic, Powerbuilder, Java

≈

10× over 3rd generation

Greatly increased the scale of how

large a software company could

grow to.

“5th Generation”

Non-existent as a general purpose

language must be domain-specific

Lawson Landmark (Business Applications)

10–20× over 4th generation

Fig. 18.2 Software language genera-

tions

mostly caught up in the mechanical metaphor believ-

ing that it is possible to mechanize or model any system

using machines or algorithms, but this is exactly the

opposite of what is actually happening. It is systems

themselves that use a mechanizing process to improve

their performance and move onto higher levels of emer-

gent behavior.

However, it is no wonder that we are so caught

up in the mechanical metaphor, as it is the very ba-

sis of the industrial revolution and is thus responsible

for much of our wealth today. In the ﬁeld of busi-

ness application software this peripheral blindness (or,

rather, intense focus) has led to huge failures in build-

ing complex business applicationsoftware systems. The

presumption is that building a software system is like

building a bridge; that it is like a construction project;

that it is fundamentally an engineering problem where

there is a design process and then a construction process

where the design process can fully specify something

that can be constructed using engineering principles;

more speciﬁcally, that thereis somedesign processdone

by designers and that the construction process is the

process of programming done by programmers. How-

ever, it is not. It is really a design problem through and

through and, moreover, a design problem that does not

have general-purpose engineering-like principles and

solutions that have already been reduced to code by

years of practice. It is a design problem of pure logic

where the logic can only be fully speciﬁed in a com-

pleted program where the construction process is then

simply running a compiler against the program to gen-

erate machine instructions that carry out the logic.

Part B 18.2

308 Part B Automation Theory and Scientiﬁc Foundations

There are no general-purpose solutions to all

logic design problems. There are only special-purpose

domain-speciﬁc solutions. This can be seen in the evo-

lution, or lately lack thereof, of computer languages.

We went from ﬁrst-generation languages (machine

code) to second-generation languages (assembler) to

third-generation languages (FORTRAN, COBOL,C)

to fourth-generation languages (Java, Progress) where

each generation represented some tenfold produc-

tivity improvement in our ability to produce sys-

tems (Fig.18.2). This impressive progression however

slowed down and essentially stopped dead in its tracks

some 20years ago in its ability to signiﬁcantly improve

productivity. Since then there have been many attempts

to come up with the next (ﬁfth) generation language or

general-purpose framework for dramatically improving

productivity. In the 1980s computer-aided software en-

gineering (CASE) tools were the hoped-for solution. In

the 1990s object-oriented frameworks looked promising

as the ultimate solution and now the industry as a whole

seems primarily focused on the notion of service-

oriented architecture (SOA) as our best way forward.

While these attempts have helped boost productivity to

some extent they have all failed to produce an order of

magnitude shift in the productivity of building software

systems (Fig. 18.3). What they all have in common is

the continuation of the mechanical metaphor. They are

all attempts at general-purpose engineering-like solu-

tions to this problem. General-purpose languages can

only go so far in solving the productivity problem.

However, special-purpose languages or domain-speciﬁc

languages (DSL) take us much farther. There are multi-

• The industry has only made

incremental progress from 4GLs

for 20+ years

• Creating a 5GL works only for a

specific problem domain

Vertical

domain-specific

language

20× improvement

CASE

Objects

SOA

5GL

4GL

(VB, Power-

builder)

3GL

(C, COBOL)

General purpose

& broad

Developer productivity

(log scale) Quality adaptability innovation

Fig. 18.3 Productivity progression of languages

ple categories of DSLs. There are horizontal DSLsthat

address some functional layer, like SQL does for data

access or UML does for conceptual design (as opposed

to the detail design which is the actual complete pro-

gram in this metaphor). And there are vertical DSLs

which address some topical area such as mathematical

analysis, molecular modeling or business process appli-

cations. There is also the distinction between a DSL and

a domain-speciﬁc design language (DSDL). All DSDLs

are DSLs but not all DSLs are DSDLs(aprescission

distinction in Peirce’s nomenclature [18.4]). A design

language is distinct from a programming or implemen-

tation language in that in a design language everything

is deﬁned relative to everything else. This is like the dis-

tinction between a design within a CAD system and the

actually built component. In the CAD system one can

move a line and everything changes around it. In the

actually built component that line is a physical entity

in some hardened structural relationship. Then there is

the further prescission distinction of a pattern language

versus a DSDL. A pattern language is a DSDL that has

built-in syntax that allows for speciﬁc design solutions

to be applied to speciﬁc domain problems. This tends

to be the most vertically domain-speciﬁc and also the

most powerful sort of language for improving the pro-

ductivity of building systems. Lawson Landmark is one

example of a pattern language that delivers a 20 times

improvement over fourth-generation languages in its

particular domain.

It is not possible to mechanize or model an entire

complex system. We can only mechanize aspects of any

particular system. To mechanize the entire system is to

destroy the system as such; i.e., it is no longer a system.

Analysis of a system into its constituent parts loses its

essence as a system, if a system is truly more than the

sum of its parts. That is, the mechanistic model lacks

the system’s inherent capability for self-organization

and thus adaptability, and thus becomes more rigid and

more limitedin its capabilities, although, perhaps, much

faster. And the limit to what aspects of a system can be

mechanized is really the limit of our cognitive ability to

model those aspects. In other words it is a design prob-

lem. In general the theoretical limit of mechanization is

always the current limit of our capacity to design lin-

ear stepwise models in any particular solution domain.

Thus the key to what can be automated is the depth of

our knowledge and understanding within any speciﬁc

problem domain, the depth required being that depth

necessary to be able to design automatons that ﬁt, where

ﬁt is determined both by the automaton actually pro-

ducing what is expected as well as ﬁtting appropriately

Part B 18.2

What Can Be Automated? What Cannot Be Automated? 18.3 Expanding the Limit 309

within the system as a whole; i.e., if the automation dis-

turbs the system that it is within beyond some threshold

then the verysystem that gives rise tothe usefulautoma-

ton will changeso dramatically thatthe automation isno

longer useful. An example of this might be a software

program for paying employees. If this program does

pay employees correctly but requires dramatic changes

to the manner in which time card information is gath-

ered such that it becomes too great a burden on some

part of the system then the program will likely soon be

surrounded by organizational T cells and rejected.

Organisms are not machines, but they can to a cer-

tain extent become machines, or perhaps congeal into

machines. Never completely, however, for a thoroughly

mechanized organism would be incapable of reacting

to the incessantly changing conditions of the outside

world. The principle of progressive mechanization ex-

presses the transition from undifferentiated wholeness

to higher function, made possible by specialization and

division of labor; this principle also implies loss of po-

tentialities in the components and of regularity in the

whole [18.5].

18.3 Expanding the Limit

Human business processes (buying, selling, manufac-

turing, invoicing, and so on), like actual organisms,

operate fundamentally as open systems or rather com-

plex adaptive system (CAS). Other examples of CAS

are cities, insect colonies, and so on. The architecture

of an African termite mound requires more bits to de-

scribe than the number of neurons in a termite brain.

So, where do they store it? In fact, they do not, be-

cause each termite is programmed as an automaton

to instinctively perform certain functions under cer-

tain stimuli and the combined activity of the colony

produces and maintains the mound. Thus, the entire

world is fundamentally made up of vastly complex in-

teracting systems. When we automate we are ourselves

engaging in the principle of progressive mechaniza-

tion. We are mechanizing some portion or aspect of

a system. We can only mechanize those aspects that

are themselves already highly specialized within the

system itself or that we can make highly specialized;

for example, it is possible to make a mechanical heart

but it is impossible to make a mechanical stem cell

or a mechanical human brain. It is possible to make

a mechanical payroll program but impossible to make

a mechanical company that responds to dynamic mar-

ket forces and makes a proﬁt. The result of this is that

any mechanization requires speciﬁc understanding of

some particular specialization within some particular

system. In other words, there are innumerable speciﬁc

domains of specialization within all of the complex

interacting systems in the world. And thus any mech-

anization is inherently domain- peciﬁc and requires

detailed domain knowledge. The process of mecha-

nization is therefore fundamentally a domain-speciﬁc

design problem. Thus, the limit of mechanization is our

ability to comprehend some particular aspect of a sys-

tem well enough to be able to extract some portion or

aspect of that system in which it is possible to deﬁne

a boundary or Carnot circle with clear inputs and clear

outputs along with a transfer function mapping those

inputs to those outputs. If we cannot enumerate the in-

puts and outputs and then describe what inputs result

in what outputs then we simply cannot automate the

process. This is the fundamental requirement of mecha-

nization.

This does not, however, mean that we are limited to

our current simple mechanical metaphor of a machine

as a set of inputs into a box that transforms those in-

puts into their associated outputs. Indeed the next step

of mechanization under way is to try to mimic aspects

of how a system itself works. One aspect of this is the

object-oriented revolution insoftware, whichitself grew

out of the work done in complex adaptive systems re-

search. Unfortunately, the prevailing simple mechanical

metaphor and lack of understanding of the nature of

CAS has blunted the evolution of object-oriented tech-

nology and limited its impact.

Object-oriented concepts have taken us from a sim-

plistic view of a machine as a black box process

or function F as shown in Fig.18.4,inwhich

(outputs = F(inputs)), to conceptualizing a machine as

an interacting set of agents or objects. These concepts

have allowed us to manage higher levels of complex-

ity in the machines we build but they have not taken us

to a higher order of magnitude in our ability to mecha-

The Black Box

InputOutput

Fig. 18.4 The engineer’s black box

Part B 18.3

310 Part B Automation Theory and Scientiﬁc Foundations

nize complex systems. In the realm of business process

software what has been missing is the following:

1. The full realization that what we are modeling with

business process software is really a portion or as-

pect of a complex adaptive system

2. That this is fundamentally a logic design problem

rather than an engineering problem

3. That, in this case, the problem domain is primar-

ily about semiotics and pragmatics, i. e., the nature

of sign processes and the impact on those who use

them

Fortunately there is a depth of research in these

areas that provides guidance toward more powerful

techniques and tools for making further progress. John

Holland, the designer of the Holland Machine, one of

the ﬁrst parallel computers, has done extensive research

into CAS and has discovered many basic principles that

all CAS seem to have in common. His work led to

object-oriented concepts; however, the object-oriented

community has not continued to seek to implement his

further discoveries and principles regarding CAS into

object-oriented computing languages. One very useful

concept is how CAS systems use rule-block formations

in driving their behavior and the nature of how adapta-

tion continues to build rule-block hierarchies on top of

existing rule-block structures [18.6].

Christopher Alexander [18.7] is a building architect

who discovered the notion of a pattern language for

designing and constructing buildings and cities [18.8].

In general, a pattern language is a set of patterns or

design solutions to some particular design problem in

some particular domain. The key insight here is that

design is a domain-speciﬁc problem that takes deep un-

derstanding of the problem domain and that, once good

design solutions are found to any speciﬁc problem, we

can codify them into reusable patterns. A simple ex-

ample of a pattern language and the nature of domain

speciﬁcity is perhaps how farmers go about building

barns. They do not hire architects but rather get together

and, through a set of rules of thumb basedonhowmuch

livestock they have and storage and processing consid-

erations, build a barn with such and such dimensions.

One simple pattern is that, when the barn gets to be too

long for just doors on the ends, they put a door in the

middle. Now, can someone use these rules of thumb or

this pattern language to builda skyscraper in New York?

Charles Sanders Peirce was a 19th century Amer-

ican philosopher and semiotician. He is one of the

founders of the quintessential American philosophy

known as pragmatism, and came up with a triadic semi-

otics based on his metaphysical categories of ﬁrstness,

secondness, and thirdness [18.9]. Firstness is the cate-

gory of idea or possibility. Secondness is the category

of brute fact or instance, and thirdness is the category of

laws or behavior. Peirce argues that existence itself re-

quires these categories; that they are in essence a unity

and that there is no existence without these three cat-

egories. Using this understanding one could argue that

this demystiﬁes to some extent the Christian notion of

God being a unity and yet also being triune by under-

standing the Father as ﬁrstness, the Son as secondness,

and the Holy Spirit as thirdness. Thus the trinity of God

is essentially a metaphysical statement about the nature

of existence. Peirce goes on to build a system of signs or

semiotics based on this triadic structure and in essence

argues that reality is ultimately the stuff of signs; e.g.,

God spoke the universeinto existence. At ﬁrst one could

seek to use this notion to support the Strong AI view

that all intelligenceis symbolrepresentation and symbol

processing and thus a computer can ultimately model

this reality. However, a key concept of Peirce is that

the meaning of a sign requires an interpretant,which

itself is a sign and thus also requires a further inter-

pretant to give it meaning in a never-ending process of

meaning creation; that is, it becomes an eternally re-

cursive process. Another way of viewing this is to say

that this process of making meaning is ultimately an

open system. And while machines can model and hence

automate closed systems they cannot fully model open

systems.

Peirce’s semiotics and his notion of ﬁrstness, sec-

ondness, and thirdness provide the key insights required

for building robust ontology models of any particular

domain. The key to a robust ontology model is not that

it is right once and for all but rather that it can be done

using a design language and that it has perfect ﬁdelity

with the resulting execution model. An ontology model

is never right; it is just more and more useful. This is

because of the notion of the relativity of categories.

Perception is universally human, determined by

man’s psychophysical equipment. Conceptualization is

culture-bound because it depends on the symbolic sys-

tems we apply. These symbolic systems are largely

determined by linguistic factors, the structure of the

language applied. Technical language, including the

symbolism of mathematics, is, in the last resort, an

efﬂorescence of everyday language, and so will not

be independent of the structure of the latter. This, of

course, does not mean that the content of mathematics

is true only within a certain culture. It is a tautologi-

Part B 18.3

What Can Be Automated? What Cannot Be Automated? 18.4 TheCurrentStateoftheArt 311

cal system of a hypothetico-deductive nature, and hence

any rational being accepting the premises must agree to

all its deductions [18.10].

The most critical aspect of achieving the theoretical

limit of automation is the ability to continue to make

execution models that are more and more useful. And

this is true for two reasons:

1. CAS are so complex that we cannot possibly under-

stand large portions of them perfectly ab initio. We

need to model them, explore them,and then improve

them.

2. CAS are continually adapting. They are continually

changing and thus, even if we perfectly modeled

some aspect of a CAS, it will change and our model

will become less and less useful.

In order to do this we need a DSDL capable of quickly

building high-ﬁdelity models. That is, models which

are themselves the drivers of the actual execution of

automation.

In order for the model of the CAS to ultimately ac-

tually drive the execution it is critical that the ontology

model be in perfect ﬁdelity with the execution model.

Today there is a big disconnect between what one can

build in an analysis model and the resultant executing

code or execution model. This is analogous to having

a design of a two-storey home on a blueprint and then

having the result become a three-storey ofﬁce building.

What is required is a design language that can both

model the ontology in its full richness as the analysis

model but also be able to model the full execution in

perfect ﬁdelity with the ontology model. In essence this

means a single model that fully incorporates ﬁrstness,

secondness, and thirdness in all their richness that can

then either be fully interpreted on a machine or fully

generated to some other machine language or a combi-

nation of both.

Only with such a powerful design or pattern lan-

guage can we overcome the inherent limitations we

have in our ability to comprehend the workings of some

particular CAS, model, and then automate those por-

tions that can be mechanized and continue to keep pace

with the continually evolving CAS that we are seeking

to progressively mechanize.

18.4 The Current State of the Art

The computing industry in general is still very much

caught up in the mechanical metaphor. While object-

oriented design and programming technology is more

than decades old, and there is a patterns movement

in the industry that is just over a decade old, there

are very few examples of this new DSDL technol-

ogy in use today. However, where it has been used

the results have been dramatic, i.e., on the order of

a 20-fold reduction of complexity as measured in

lines of code. Lawson Landmark

is such a pattern

language intended for the precise functional speciﬁca-

tion of business enterprise computer applications by

domain specialists rather than programmers [18.11].

The result of the domain expert’s work is then run

through a metacompiler to produce Java code which

can be loaded and tested against a transaction script

also prepared by the same or another domain ex-

pert (i. e., accountant, supply-chain expert, etc.). The

traditional application programmer does not appear

in this modern business application development sce-

nario because his or her function has been automated.

It has taken nearly 50 years for speciﬁcation-based

programming to arrive at this level of development

and utility and several other aggressive attempts at

automation of intellectual functions have taken as

long.

Automation of human intellectual functions is ba-

sically an aspect of AI, and the potential of AI is

basically a philosophical rather than a technical ques-

tion. The two major protagonists in this debate are

the philosopher Hubert Dreyfus [18.12, 13]andRay

Kurzweil [18.14–16], an accomplished engineer. Drey-

fus argues that computers will never ever achieve

anything like human intelligence simply because they

do not have consciousness. He gives the argument from

what he calls associative or peripheral consciousness in

the human brain. Kurzweil has written extensively as

a futurist arguing that computers will soon exceed hu-

man intelligence and even develop spiritual capabilities.

Early in the computer era Herbert Simon hypoth-

esized that a computer program that was able to

play master-level chess would be exhibiting intelli-

gence [18.17]. Dreyfus and other Strong AI opponents

argue that it is not, because the chess program does not

automatically play chess like a human does and there-

fore does not exhibit AI atall.Theygoontoshowthat

is impossible for a program to play an even simpler

game like Go well using this same technology. Play-

Part B 18.4

312 Part B Automation Theory and Scientiﬁc Foundations

ing chess was the straw man set up by Herbert Simon

in the mid-1950s to be the benchmark of AI,i.e.,if

a computer could beat the best human chess player,

then it would show true intelligence, but it actually does

not. It took nearly 50years to develop a special-purpose

computer able to beat the leading human chess master,

Gary Kasparov, but it does not automate or mecha-

nize human intelligence to do so. In fact, it just came

up with a different design for a computational algo-

rithm that could play chess. This is analogous to the

problem of ﬂying. We did not copy how a bird ﬂies

but rather came up with a special-purpose design that

suited our particular requirements. The Strong AI hy-

pothesis appears to assume that all human thought, or at

least intelligentthought, can be reducedto computation,

and since computers can compute orders of magnitude

faster than humans they will soon, says Ray Kurzweil,

exhibit human-like intelligence, and eventually intel-

ligence even superior to that of humans. Of course,

the philosophers who gainsay the Strong AI hypothesis

argue that not all intelligent human thought and its con-

sequent behavior canbe reduced tosimple computation,

or even logic.

An early goal of AI was to mechanize the function

of an autonomous vehicle, that is, to give the vehicle

a goal or set of objectives and the algorithms needed

to accomplish them and let it function. The annual au-

tonomous vehicle race in the Nevada desert shows that

at least simple goals canbe metautonomously or at least

as well as a mildly intoxicated human driver. The semi-

autonomous Mars rovers show off this technology even

better but still fall far short of being intelligent.

Another of the early intrinsically human activities

that AI researchers tried to automate was the typewriter.

Prof. Marvin Minsky started his AI career as a gradu-

ate student at MIT in the mid-1950s working on a voice

typewriter to type military correspondence for the De-

partment of Defense (DoD). Now, more than 50years

later, the technology is modestly successful as a soft-

ware program.

At the same time Prof. Anthony Oettenger did his

dissertation at the Harvard Computation Laboratory

on automatic language translation with the Automatic

Russian–English Dictionary. It was modestly success-

ful for a narrow genre of Russian technical literature

and created the whole new ﬁeld of computational

linguistics. Today, more than 50years later, a simi-

lar technology is available as a software program for

Russian and a few other languages with a library of

genre-speciﬁc and technical-area-speciﬁc vocabulary

plug-ins sold separately. The best success story on

automatic language translation today is the European

Economic Community (EEC), which writes its memos

in French in the Brussels headquarters and converts

them into the 11 languages of the EEC and then sends

them out to member nations. French bureaucratese is

a very narrow language genre and probably the eas-

iest case for autotranslation automation due not only

to the genre but the source language. No one has ever

suggested that Eugene Onegin will ever be translated

automatically from Russian to English, since so far it

has even resisted human efforts to do so. Amazing as it

may seem, Shakespeare’s poetry translates beautifully

to Russian but Pushkin’s does not translate easily to

English.

Linguists are divided, like philosophers, on whether

computational linguistics technology will ever really

achieve true automation, but we think that it probably

will, subject to human pre- and post-editing in actual

volume production practice, and then only for very nar-

row subject areas in a few restricted genres. Technical

prose in which the translator is only copying one fact

at a time from one language to another will be possi-

ble, but poetry will always be too complex, since poetry

always violates the rules of grammar of its own source

language.

18.5 A General Principle

What we need is a general principle which will cleanly

divide all the things that can be done into those which

can be automated and thosewhich cannot be automated.

You cannot automate what you cannot do manually, but

the converse it not true, since you cannot always au-

tomate everything you can do manually [18.4, 18, 19].

However, this principle is much too blunt. In his book

Darwin’s Black Box Professor Michael Behe argued

from the principle of irreducible complexity that neo-

Darwinism was inadequate to explain the development

of the eye or of the endocrine system because too

many mutations and their immediate useful adaptations

had to happen at once, since each of 20 or more re-

quired mutations would have no competitive advantage

in adaptation individually [18.20]. In his second book

The Edge of Evolution he sharpens his principle signiﬁ-

Part B 18.5

What Can Be Automated? What Cannot Be Automated? References 313

cantly to divide biological adaptations into those which

can be explained by neo-Darwinism (single mutations)

and those which cannot (multiple mutations). The re-

ﬁned principle, while sharper, still leaves a ragged edge

between the two classes of adaptive biological systems,

according to Behe [18.21].

In our case we postulate the principle of design.

Anything that can be copied can be copied automat-

ically. However, any process involving design cannot

be automated and any sufﬁciently (i.e., irreducibly)

complex adaptive system cannot be automated (as

Behe shows), however simple adaptive systems can be

modeled to some extent mechanistically. Malaria can

become resistant to a new antibiotic in weeks by Dar-

win’s black box if it requires only a one-gene change,

however in 10000 years malaria has not been able to

overcome the cell-cycle mutation in humans because it

would require too many concurrent mutations.

We conclude that anything that can be reduced to

an algorithm or computational process can be auto-

mated, but that some things, like most human thought

and most functions of complex adaptive systems, are

not reducible to a logical algorithm or a computational

process and therefore cannot be automated.

References

18.1 American Machinist, 21 Oct. 1948. Creation of the

term automation is usually attributed to Delmar S.

Harder

18.2 J.M. Schwartz, S. Begley: TheMindandtheBrain:

Neuroplasticity and the Power of Mental Force

(Harper, New York 2002)

18.3 K.L. von Bertalanffy: General System Theory:

Foundations, Development, Applications (George

Braziller, New York 1976) p. 56

18.4 D.D. Spencer: What Computers Can Do (Macmillan,

New York 1984)

18.5 K.L. von Bertalanffy: General System Theory:

Foundations, Development, Applications (George

Braziller, New York 1976) p. 213, revised edition

18.6 J. Holland: Hidden Order, How Adaptation Builds

Complexity (Addison-Wesley, Reading 1995)

18.7 C. Alexander: The Timeless Way of Building (Oxford,

New York 1979)

18.8 C. Alexander: A Pattern Language (Oxford, New

York 1981)

18.9 C. S. Peirce: Collected Papers of Charles Sanders

Peirce, Vols. 1–6 ed. by C. Hartshorne, P. Weiss,

1931–1935;Vols.7–8ed.byA.W.Burks,(Harvard

University Press, Cambridge 1958)

18.10 K.L. von Bertalanffy: General System Theory:

Foundations, Development, Applications (George

Braziller, New York 1976) p. 237

18.11 B.K. Jyaswal, P.C. Patton: Design for Trustworthy

Software: Tools, Techniques and Methodology of

Producing Robust Software (Prentice-Hall, Upper

Saddle River 2006) p. 501

18.12 H. Dreyfus: What Computers Can’t Do: A Critique

of Artiﬁcial Intelligence (Harper Collins, New York

1978)

18.13 H. Dreyfus: What Computers Still Can’t Do: A Critique

of Artiﬁcial Reason (MIT Press, Cambridge 1992)

18.14 R. Kurzweil: The Age of Intelligent Machines (MIT

Press, Cambridge 1992)

18.15 R. Kurzweil: The Age of Spiritual Machines: When

Computers Exceed Human Intelligence (Viking, New

York 1999)

18.16 R. Kurzweil: The Singularity is Near: When Humans

Transcend Biology (Viking, New York 2005)

18.17 H. Simon: Perception in chess, Cognitive Psychol.

4, 11–27 (1973)

18.18 B. W. Arden (Ed.): What Can Be Automated?,The

Computer Science and Engineering Research Study

(COSERS) Ser., (MIT Press, Cambridge 1980)

18.19 I.Q. Wilson, M.E. Wilson: What Computers Cannot

Do (Vertex, New York 1970)

18.20 M. Behe: Darwin’s Black Box: The Biochemical

Challenge to Evolution (Free, New York 2006)

18.21 M. Behe: The Edge of Evolution: The Search for the

Limits of Darwinism (Free, New York 2007)

Part B 18

“This page left intentionally blank.”