Denken over Software
mr A.H.J. Schmidt
D E N K E N O V E R S O F T W A R E 1
Denken over Software is een bezigheid die niet altijd tot nuttige resultaten leidt maar die soms onvermijdelijk is. De methodologische richtlijnen die het pragmatische denken over Software binnen het keurslijf van concrete Soft-ware ontwikkelingsprojecten meestal vergezellen formen daarvan een illustra-tie. De opmars van de maatschappelijke betekenis van de toegepaste informa-tica heeft bovendien geleid tot juridische, politieke en tot ethische gedach-tenvorming over Software.
In dit stuk wil ik op een minder normatieve monier naar Software kijken en vrijmoedig mijn gedachten laten gaan over de vraag wat Software eigen-lijk is, over de vraag wat een software-fout is, over de vraag of program-ma's bewijsbaar zijn en tenslotte over de vraag of de geschiedenis zieh in het denken over Software dreigt te herholen. Het is niet mijn bedoeling om die vragen ook te beantwoorden. Met antwoorden op vragen die niet kunnen worden beantwoord schiet niemand op.
Denken
Wanneer we zouden aannemen dat denken zinvol kan worden gedefinieerd als de activiteit die ertoe leidt dat er antwoorden worden opgeleverd naar aanleiding van en als oplossing voor vragen, dan denk ik dat een van de gevaarlijkste vragen die kunnen worden gesteld als volgt luidt: "Wat is denken?".
Er zijn verschillende redenen om die vraag hier toch te stellen. De term denken is in de titel van dit betoog terecht gekomen en dat is niet toevallig. De Computerindustrie is vanaf het allereerste begin door buitenstaanders in verband gebracht met kunstmatige vormen van intelligentie. Sinds 1950 is de term kunstmatige intelligentie via het artikel van Alan Turing ook binnen de informatica-wereld serieus genomen, en vanaf die tijd is er zowel in weten-schappelijke als in industriele kring aan het ontwikkelen van intelligente machines gewerkt. Na 1975 wordt er gesproken over expert Systemen2, en die benaming is - los van wat er precies mee wordt bedoeld - in de tachtiger jaren een etiket geworden voor de producten van een tak van Industrie die goodwill ontmoet van financiers uit het bedrijfsleven en uit de overheid. In deze expert Systemen wordt getracht expertise onder te brengen op zo'n manier dat ze intelligente antwoorden op vragen kunnen geven. De denk-kracht van expert Systemen is tenminste voor een deel gevangen in Software. Denken over dit soort Software is daarmee onvermijdelijk een vorm van denken over denken geworden.
Ik acht het aannemelijk dat een deel van u bij het lezen van de eerste zin van deze paragraaf de indruk heeft gehad hem te begrijpen. Denken werd
l Bijdrage voor het ASI-symposium van 10 december 1986 onder de titei: Informatica 2000.
daarin opgevat als de activiteit die leidt tot het geven van antwoorden op vragen.
In Schema:
D E N K E N
V R A A G A N T W O O R D
Dit Schema is om verschillende redenen interessant. Allereerst vertoont het grote gelijkenis met de meest elementaire afbeelding die in verband wordt gebracht met de geautomatiseerde gegevensverwerking:
S O F T W A R E
I N P U T O U T P U T
Nu zijn alleen de termen vraag, denken en antwoord vervangen door achter-eenvolgens de termen input, Software3 en output. Wanneer we aannemen dat vragen kunnen worden opgevat als input, dat antwoorden kunnen worden opgevat als output en dat denken kan worden opgevat als een activiteit die in Software kan worden vastgelegd, dan lijkt het vermoeden gerechtvaardigd dat denkende machines kunnen worden gemaakt. Sterker nog, dergelijke machines bestaan al lang. In de gegeven definitie moet een machine die op de vraag
l + I = ? met het gewiekste antwoord
2.
op de proppen komt immers als een denkende machine worden beoordeeld. Hoewel vrijwel niemand deze conclusie onderschrijft wil ik de gegeven definitie niet verwerpen voordat ik heb geprobeerd om het Schema op een paar andere manieren te concretiseren. Zodra de machine die naar zojuist bleek in Staat is om tenminste tot twee te teilen op de vraag
is er een verband tussen energle, massa en snelheid? reageert met de mededeling
Ja, en wel: E = MC2.
zieh in sterk op natuurlijke taal gelijkende termen uit te drukken, en zelfs als het antwoord alleen maar zou zijn opgezocht in een omvangrijk gege-vensbestand dan zou dit vermögen er in deze tijd toe leiden dat dit apparaat vrijwel unaniem als een exponent van vergevorderde kunstmatige intelligentie zou worden beoordeeld. Gesterkt door deze gedachte zouden we aan deze machine de vraag
Wat is denken eigenlijk? kunnen stellen. Wanneer als antwoord de mededeling
Denken is het proces dat leidt tot antwoorden op vragen.
verschijnt, dan zou ik niet weten hoe ik het had. Vermoedelijk zou ik deze machine met honderden uiteenlopende vragen bestoken om uit te vinden of ik met een intelligente Computer te maken heb of met de een of andere prac-tical joke.
Dergelijke hypothetische mens-machine dialogen speien een rol in het betoog van Turing4. Weizenbaum5 realiseerde omstreeks 1966 in zijn pro-gramma ELIZA een context waarin mens-machine dialogen in natuurlijke taal functioneerden. Opmerkelijk is dat het programma van Weizenbaum in de wereld van de kunstmatige intelligentie wordt opgevat als een trivialiteit. De schrijver zelf denkt daar ook zo over6. Een essentiöle paradox bij het be-oordelen van de intelligentie van computerprogramma's wordt kennelijk gevormd door het vrij algemeen aanvaarde vermoeden dat wanneer we weten hoe iets werkt we dat ook kunnen programmeren (de Church-Turing these), tegenover het gevoel dat zodra een proces kan worden gemechaniseerd aan dat proces iedere vorm van intelligentie moet worden ontzegd. De konse-kwentie van deze paradox is dat we zodra we weten wat denken is een denkende machine kunnen maken, maar dat we - zodra we een denkende machine gemaakt hebben - deze niet meer als een denkende machine maar als een simpele automaat willen opvatten.
Het zou mijns inziens maatschappelijk niet ongevaarlijk kunnen zijn wanneer we hiermee impliciet zouden aannemen dat we "simpele" automaten gemakkelijk kunnen begrijpen en beheersen. Ik geef er dan ook de voorkeur aan om de eerder gegeven definitie van denken te hanteren. Het lijkt het me verstandig om onder de term intelligentie (of die nu kunstmatig is of niet) niet alleen superslim denkvermogen te vatten.
De tot zover gevolgde gedachtengang levert een aantal aanknopingspunten op voor opmerkingen over denkende machines:
(0) het black-box model
Ik heb de term denken gedefinigerd op een manier die kan worden weergege-ven in het klassieke black-box model. Op die manier wordt niet alleen gesug-gereerd dat denken kan worden opgevat als een procedure, als een
werkwij-4 A M Tunng, Computing machmery and mtelllgence, Mmd 1950
5 Joseph Weizenbaum, Computing power and human reasomng, San Francisco 1976
ze, maar wordt ook aansluiting gezocht bij het meest algemene model dat in de informatica bekend is. Het is niet onmogelijk dat dit model volstrekt ontoereikend is om het begrip denken zoals dat in natuurlijke taal wordt gebruikt te beschrijven.
(1) descriptieve en procedurele interpretaties
Wanneer de analogie tussen de Schema's die voor respectievelijk denken en voor de automatische gegevensverwerking staan wordt aanvaard, dan is het om over denkende machines te kunnen praten op zijn minst nodig dat som-mige formuleringen zowel een descriptieve als een procedurele interpretatie toestaan. Dit geldt in elk geval wanneer van de machine verwacht wordt dat hij antwoord zal kunnen geven op vragen als "wat is denken?". Een derge-lijke vraag leidt er immers toe dat die machine moet kunnen beschrijven wat hij doet.
(2) primitief recursieve procedures
In de loop van deze paragraaf heb ik aan een hypothetische machine drie vragen gesteld. De antwoorden die deze machine gaf leken heel redelijk. De mate waarin we riaar aanleiding van het vermögen van die machine om antwoorden op vragen te geven de machine zelf beoordelen hangt samen met de complexiteit van de besturingsstructuur die in het programma werd ge-bruikt. Wanneer de machine een limitatief lijstje vragen kent en daarbij een eveneens limitatief rijtje antwoorden kan vinden, dan zijn we geneigd om het apparaat relatief "dorn" te vinden. Een dergelijke besturingsstructuur wordt primitief recursief genoemd.
(3) algemeen recursieve procedures
Zodra in programma's meer gecompliceerde besturingsstructuren worden toegelaten is het niet steeds meer duidelijk of ze er ooit nog aan zullen toekomen Output te produceren. Programma's met deze besturingsstructuur die toch gegarandeerd tot een einde körnen bevatten op de een of andere manier kennis over zichzelf of over hun eigen gedrag (meta-kennis). Een dergelijke besturingsstructuur wordt algemeen recursief genoemd, en de resulterende programma's worden vaak "slimmer" gevonden dan primitief recursieve pro-gramma's. Mogelijk als gevolg van de omstandigheid dat algemeen recursieve programma's voor mensen vaak moeilijk te begrijpen zijn.
(4) partißel recursieve procedures
Helemaal ingewikkeld wordt het met programma's die een soortgelijke bestu-ringsstructuur kennen, maar die nooit aan het geven van output toekomen. Dergelijke programma's worden partiöel recursief genoemd7. Het is niet uitgesloten dat de vraag "wat is denken" leidt tot een partieel recursief proces waarop het antwoord achterwege blijft.
Dit zou als volgt in elkaar kunnen steken. Onze denkende Computer kent een programma dat denken heet en dat luidt: wat is X. De vraag "wat is denken?" wordt door dit programma al substituerend als volgt behandeld:
wat is wat is denken?
Bij het uitwerken van die vraag wordt "denken" vervangen door "wat is X", vervolgens wordt "X" vervangen door "denken" en zo per recursie ad infini-tum. Het voorkomen van een dergelijke eindeloze regressie vooronderstelt een ingreep vanuit een extern standpunt, en daarmee zijn we naar de alge-meen recursieve programma's teruggekeerd.
Software
De term Software is ontstaan om onderscheid te kunnen maken tussen dat gedeelte van Computers dat aan fysieke wetten gehoorzaamt en dat hardware wordt genoemd, en dat gedeelte dat gemakkelijker kan worden gewijzigd en dat de hardware bestuurt. Ik zou het prettig hebben gevonden wanneer Software in deze zin opgevat zou zijn gebleven, zodat daarbinnen het meer problematische onderscheid tussen programmatuur en gegevens(data) zou kunnen worden aangebracht. Nu dit niet zo is (onder Software wordt alge-meen programmatuur verstaan) zal ik moeten proberen Software op een zinnige manier van data te onderscheiden.
Dit onderscheid lijkt buitengewoon eenvoudig te kunnen worden gemaakt aan de hand van interpretaties. Informatie die een procedurele interpretatie door Computers toestaat behoort dan tot de categorie Software, terwijl informatie die door het programma wordt verwerkt als data moet worden gezien. Het programma dat ter compilatie wordt aangeboden is in die toe-stand te zien als data, de gecompileerde versie die wordt geexecuteerd als Software. Geen vuiltje aan de lucht, lijkt het.
Met het ontstaan van meer algemene programma-pakketten en met het meer gebruikelijk worden van programmeertalen als PROLOG sluipen er in het taalgebruik onzuiverheden die het geschetste onderscheid ondermijnen. Series instructies die programmapakketten (e.g. bedrijfssystemen, DBMS, SAS) besturen worden vaak weer programma's genoemd en worden conceptueel onderscheiden van de gegevens die door die programmapakketten worden bewerkt. lets dergelijks doet zieh voor bij het spraakgebruik rond PROLOG, waar programma's resideren in de data-base. Een interessante indicatie voor de Problemen die kunnen ontstaan bij het onderscheiden van programma's van gegevens duikt op bij de pogingen die Juristen ondernemen om bij het formuleren van auteursrechtelijke regelingen te definieren wat een pro-gramma is8.
Statements, met uitzondering van besturingscommando's). Die indeling sluit aardig aan bij practisch bruikbare begrippen en opent de weg voor de op dit moment modieuze analogie tussen theorieen over formele Systemen en de toegepaste informatica9.
Deze analogie verdient hier enige aandacht, niet alleen omdat computertalen als PROLOG er een exponent van zijn, maar ook en vooral omdat de ruim-schoots voorhanden meta-mathematische theorieen in het spoor daarvan direct toepasbaar lijken op computerapplicaties.
Formele Systemen10 zijn in het begin van deze eeuw voorwerp van warme belangstelling geweest van logici en wiskundigen bij nun pogingen om bewij-zen typografisch tot stand te kunnen brengen. Ze bestaan uit een aantal axioma's of premissen (zinnen waarvan de waarheid11 wordt aangenomen, gegevens) en een aantal productieregels (de regels die de toegelaten manieren beschrijven waarop wäre zinnen mögen worden veranderd, programma-state-ments). Met behulp van de productieregels kunnen hele reeksen wäre zinnen vanuit de axioma's of de premissen worden afgeleid. De laatste van een dergelijke reeks wordt theorema genoemd (en kan in de analogie worden gezien als output).
In de theorie van de formele Systemen is de volgorde waarin productiere-gels worden gebruikt en/of waarin axioma's of premissen voor bewerking worden gekozen irrelevant. Dat die volgorde van pragmatische betekenis kan zijn bij het gebruik van formele Systemen is evident. De keuzen die gemaakt worden behoren tot de heuristiek bij het gebruik van formele Systemen (en die keuzen kunnen in de analogie met computertoepassingen worden gerela-teerd aan besturingscommando's, of, zoals bij PROLOG, in een op brüte force gebaseerd algoritme zijn ondergebracht).
Op de betekenis van deze analogie wordt uitvoerig ingegaan door Hog-ger12, en hij werkt hem voor een subset van de predicatenlogica als formeel systeem uit. Twee kanttekeningen moeten echter hier al bij de analogie tussen computertoepassingen en formele Systemen worden gemaakt. Formele Systemen zijn statisch, hetgeen inhoudt dat het niet vanzelf spreekt dat de waarheid van de geproduceerde zinnen behouden blijft wanneer axioma's, premissen of productieregels worden veranderd of toegevoegd. De destruc-tieve assignatie, die kenmerkend is voor elke mij bekende computertaal, kan de analogie dan ook bederven.
Software-fouten
Hoewel elke programmeur gevoelsmatig precies weet wat een bug is, blijkt het verschrikkelijk moeilijk te zijn om in zijn algemeenheid overeenstemming
9 Zie bijvoorbeeld L C van der Gaag en P J F Lucas, Prolog Specilicatie - Implemeutatie, Informatie 1985, pp 766 - 774 Hierin wordt Kowalski's formale "algoritme - logica * besturing (eveneens) overgenomen
10 Zie voor een uitgebreide behandelmg van dit onderwerp S C Kleene, Introduction to metamathematics, Groningen 1980 (1952)
te bereiken over het antwoord op de vraag wat een software-fout is. Juristen krijgen in toenemende mate te maken met het beoordelen van conflicten hierover en zelfs zij kunnen er zieh niet langer aan onttrekken zieh in aspecten van de informatica te verdiepen. De juridische benadering van het identificeren van software-fouten is veelal gebaseerd op het vergelijken van contracten, de programma-documentatie en de werking van de programmatuur. In het licht van wat hiervoor over Software werd gezegd wordt op die manier maar een gedeelte van de mogelijk software-fouten bestreken. In aansluiting daarop wil ik hier enkele verschallende soorten software-fouten onderscheiden.
(1) fouten in de gegevens
Deze fouten leidden tot het adagium "garbage in - garbage out". Hoewel de schade die door dergelijke fouten wordt veroorzaakt aanzienlijk kan zijn, wordt de verantwoordelijkheid ervoor door informatici (en in contracten) meestal aan de gebruiker toegeschreven. Naarmate computertoepassingen gebruikersvriendelijker en "intelligenter" worden, of, meer in het algemeen, naarmate computertoepassingen meer bedoeld zijn om zelfstandig te opereren, valt deze opstelling moeilijker vol te houden. In het hypothetische geval dat een volledig geautomatiseerd nucleair verdedigingssysteem geen onderscheid maakt tussen een vlucht regenwulpen en een groepje vijandelijke bommen-werpers lijkt het niet onredelijk om het antwoord op de dan mogelijk irrele-vant geworden schuldvraag voor een deel bij de verantwoordelijke informatici te zoeken.
Het lijkt nie zinvol om dit soort fouten in verband te brengen met enkele meta-mathematische bevindingen. Tarski wijst erop dat bij het gebruik van formele Systemen alleen dan kan worden voorkomen dat er inconsistenties ontstaan, wanneer wordt aangenomen dat het systeem zieh uitlaat over een helder begrensde, niet dynamische wereld, terwijl (om over die wereld te spreken) gebruik wordt gemaakt van een eenduidige, kunstmatige taal13. Gödel liet zien dat formele Systemen met de kracht van de getaltheorie en die een in beginsel onbegrensde wereld beschrijven (computerprogramma's kunnen tot deze categorie van formele Systemen behoren) ofwel een deel van die wereld niet kunnen beschrijven, ofwel inconsistent zijn. Dit impliceert dat formeel deugdelijke programma's naar hun aard uitgaan van een ondeug-delijk wereldbeeld, en dat programma's die trachten zieh uit te spreken over een volledige en dynamische wereld formeel niet kunnen kloppen. Natuurlijke en kunstmatige intelligentie lijken elkaar wat dit betreft overigens in theorie niet veel te ontlopen. In die situaties waarin een keus kan worden gemaakt tussen deze twee is deze keus er een van (bedrijfs)politieke afweging waarbij het argument van de formele deugdelijkheid van de Software eigenaardig genoeg aanleiding zou moeten geven tot pragmatisch wantrouwen. Dit maakt dergelijke argumenten niet betekenisloos; zonder inzicht in de formele kwali-teit van Software is het beoordelen ervan helemaal een empirische kwestie
8
geworden. Met inzicht in de formele kwaliteit van Software weet je ten-minste waar je de fouten kunt verwachten.
(2) fouten in de productieregels
Hier gaat het om de klassieke "bugs". Hoare, Kowalski en anderen hebben laten zien dat het mogelijk is om de correctheid van programma's te bewij-zen wanneer de programma-specificaties in predikatenlogica worden geformu-leerd en wanneer de deugdelijkheid van de predikatenlogica wordt aanoaard14. In de praktijk blijkt het bewijzen van de deugdelijkheid van programma's op de hierbedoelde manier niet eenvoudig en nogal bewerkelijk, zodat gevreesd moet worden dat van dit middel niet veel gebruik wordt gemaakt. Met de bezwaren die aan het formele deugdelijkheidsbewijs kleven (het gezag ervan lijkt zieh bovendien soms tot de maatschappelijke interpre-tatie van die programma's uit te strekken) zij hier opgemerkt dat dit toch het beste is waarover we vanuit formele optiek kunnen beschikken. (3) fouten in de heuristiek
In die gevallen waarin de werking van een computertoepassing mede afhanke-lijk is van de besturing ervan door de gebruiker bestaat meestal de mogeafhanke-lijk- mogelijk-heid dat de gebruiker betere en slechtere besturingssignalen kan aanbieden. Het uitzetten van geautomatiseerde beveiligingssystemen van kerncentrales bij het uitvoeren van experimenten lijkt op het eerste gezicht er een van de tweede soort. Over het algemeen worden dergelijke fouten pas toegeschreven aan de software-leverancier wanneer deze de werking van zijn produkt on-deugdelijk heeft gedocumenteerd. Het beperken van dit soort fouten valt trouwens alleen te bereiken door er de gebruiker beter van op de hoogte te stellen hoe de Software werkt. Naarmate programma's complexer worden valt dit moeilijker te verwezenlijken.
Tenslotte kunnen er fouten worden gemaakt bij het interpreteren van de Output van computerapplicaties. Ook hier zitten we in beginsel buiten het gebied waarvoor de informaticus verantwoordelijk wordt geacht.
Bewijsbare programma's
Uit het voorafgaande kan worden opgemerkt dat er in beginsel twee manie-ren zijn om de kwaliteit van Software te beoordelen. De minst controversie'le invalshoek is die van de formele bewijsbaarheid. De beperkingen die aan deze werkwijze kleven (specificaties in termen van predikatenlogica, omslachtige en moeilijke programmeermethoden die aan de vereisten van formaliteit moeten voldoen, geen betekenis van het bewijs voor de materiele doelmatig-heid van de Software) zijn al aan de orde geweest. Aan de andere kant werd ook al opgemerkt dat de formele bewijsbaarheid van programma's voorlopig het beste is dat we hebben.
van aard en kijkt naar de materiele doelmatigheid van de opgeleverde compu-terapplicatie. In deze sfeer plegen praktijktests te worden uitgevoerd en hieronder valt in mijn optiek ook het "onderhoud", waaronder meestal mede wordt verstaan het incidenteel wijzigen van bestaande Software op een manier die ertoe leidt dat deze beter functioneert, al dan niet naar aanlei-ding van gewijzigde gebruikseisen in een zieh wijzigende wereld.
Het gaat hierbij om twee wezenlijk verschillende beoordelingsmethoden, die ook wezenlijk verschillende aspecten van Software beschrijven. De for-mele invalshoek is van grote betekenis omdat daarmee zinvolle uitspraken over de kwaliteit van programma's kunnen worden gedaan, los van het feite-lijk gebruik ervan; de empirische invalshoek is van nog grotere betekenis omdat deze werkwijze zijn in wezen pragmatische betekenis behoudt bij een informeel, niet a priori begrensd wereldbeeld.
Wanneer de vraag naar intelligente sofware aanhoudt verwacht ik dat beide beoordelingsmethoden in nog sterkere mate dan nu al het geval is tekort zullen schieten. Het ziet ernaar uit dat intelligente, lerende, Software niet kan voldoen aan de eenvoudigste vereisten van formaliteit omdat derge-lijke toepassingen gebruik zullen maken van de mogelijkheid nun eigen produktieregels te veranderen of - wat me veel waarschijnlijker lijkt - omdat dergelijke toepassingen zijn opgebouwd uit verschillende Subsystemen die elkaars gegevens, produktieregels en heuristieken kunnen veranderen. Me-thodologische en formele Instrumenten om de kwaliteit van dergelijke soft-warepakketten te beheersen en te beoordelen ontbreken bij mijn weten vrijwel geheel. Intussen is de potentiele kracht van dergelijke Systemen onderkend, zodat de feitelijke ontwikkeling ervan niet gemakkelijk meer valt tegen te houden. Wanneer ze niet worden ingezet bij het besturen van materieel onherstelbaar ingrijpende processen is daar mijns inziens ook weinig op tegen. Zolang de informatica-industrie nog niet in Staat is om een formeel foutloze tekstverwerker op de markt te brengen lijkt het aanbeveling te verdienen om bij het feitelijk gebruik van al dan niet lerende expert Systemen terughoudend te blijven.
De geschiedenes herhaalt zieh
Soms valt er bij het formuleren van toekomstverwachtingen het een en ander te leren uit de geschiedenis. Omdat in het kader van een Symposium onder de titel "Informatica 2000" vooruitzien vanzelfsprekend lijkt zal ik dan ook maar beginnen terug te kijken.
intelli-10
gente machines. Universiteitscomputers verwerken simultaan de meest uiteen-lopende en lastige vragen. Ze worden niet intelligent gevonden omdat ze onmiddelijk vergeten wat ze doen, en omdat er geen enkel verband wordt gezien tussen de verschillende toepassingen. Onder andere om redenen van privacy zou het ook helemaal niet wenselijk zijn dat dergelijke machines verbanden tussen toepassingen zouden leggen en vasthouden, zodat längs die weg het ontstaan van de meer intelligente, integrerende Software niet kan worden verwacht.
Sinds de opkomst van de personal Computer, vooral in de tachtiger jaren, lijkt de informaticawereld een stap terug te hebben gedaan. Bedrijfssystemen als DOS lijken sterk op de tot het eind van de zestiger jaren gebruikelijke single-user Systemen. Intussen valt een explosieve groei waar te nemen in het aanbod van gebruikersvriendelijke PC-programma's voor toepassingen die eerder op mainframes werden ontwikkeld en gebruikt.
Een groot deel van de PC-gebruikers zijn Individuen. De vanuit informati-ca-optiek bezien uiteenlopende toepassingen waarvan ze gebruik maken vertonen via de specificiteit van deze gebruiker een functionele samenhang die er toe leidt dat behoefte ontstaat om deze toepassingen te kunnen kop-pelen. Populaire pakketten beginnen Interfaces te bieden met andere popu-laire pakketten, programmeertalen als PROLOG maken het mogelijk om individuele bedrijfssystemen te ontwikkelen waarin het begin van een intel-ligente multi-tasking kan worden gerealiseerd. Intussen vertoont de ontwik-keling in de hoek van de expert Systemen een zeer vergelijkbare trend.
Vrijmoedig extrapolerend verwacht ik dat uit deze gang van zaken intelli-gente persoonlijke multi-tasking en time-sharing Systemen zullen ontstaan, en dat deze Systemen zullen groeien naar persoonlijke expert-systemen. De samenhang tussen de verschillende kennisgebieden van dergelijke Systemen is een van de kernvragen van het huldige onderzoek naar kunstmatige intelli-gentie waaraan vanuit verschillende hoeken wordt gewerkt. Veelbelovende practische resultaten lijken te worden bereikt bij het creeren van de mecha-nische "mierenhoop", Computers die zijn opgebouwd uit duizenden deelcompu-ters. Dergelijke connectie-machines geven, voorlopig op een uiterst primitief niveau, blijk van lerende, inductieve, associatieve en patroon-herkennende Vermögens15.
Het theoretisch denken over Software loopt voor zover zieh dat baseert op formele Systemen uit de pas met feitelijke ontwikkelingen in de automatise-ring. Wat volgens dat denken niet is toegestaan (het veranderen van premis-sen en productieregels) lijkt een noodzakelijk bestanddeel van intelligente Software, en kan ook feitelijk op Computers worden gerealiseerd. De hierbe-doelde discrepantie tussen theorie en praktijk valt voor zover ik kan over-zien misschien te overbruggen met verdere ontwikkelingen van het formele
11 denken in lambda-calculi (waarin relaties kunnen worden geindiceerd)16, mogelijk in samenhang met meerwaardige, eventueel deontische te interprete-ren logica's.
Nijhoff formuleerde als volgt een waarschuwing aan degenen die hun energie en tijd in dergelijke ondernemingen willen steken:
"Denken is voor een mens de pest! AI denkt hij nog zo opperbest
Tenslotte wordt zijn hoofd te groot En eindelijk denkt hij zieh dood"
Die waarschuwing moet serieus genomen worden. Het is lang niet zeker dat de bedoelde denkarbeid tot resultaten leiden zal. Bovendien is het niet waarschijnlijk dat de gevonden resultaten, mocht die arbeid succesvol blijken, in een vorm kunnen worden gepresenteerd die het mogelijk maakt dat ze in de praktijk bij het ontwikkelen van Software zullen worden gebruikt.
De betekenis van dergelijke resultaten kan aan de andere kant niet gemakkelijk worden overschat. Het maatschappelijk gebruik van Software waarvan de formele kwaliteit niet eens kan worden vastgesteld geeft nu eenmaal te denken.
Oegstgeest, 17 Oktober 1986 A.H.J. Schmidt
