Streven. Vlaamse editie. Jaargang 52

[p. 634]

Computers in de klas
Waarom, waartoe, hoe?
H. Christiaen

Meer en meer worden wij door computers omgeven. Alleen al voor het jaar 1983 verwachtte men dat hun aantal over de hele wereld met zo'n twee tot tweeëneenhalf miljoen zou toenemen. In het gebruik dat wij ervan maken of zullen maken, kan men vier niveaus onderscheiden:

1. Het transparante en al lang vertrouwde gebruik van een microprocessor die ingebouwd is in een wasmachine, een tuner, een bankterminal enz...

2. Het gebruik van pasklare programma's ten behoeve van (door de) Computer Ondersteund Onderwijs, tekstverwerking, visicalc enz...

3. Het zelf ontwerpen en schrijven van eenvoudige programma's.

4. Het volledig gebruik/beheersing van computertalen en -systemen.

De meesten onder ons zullen zich beperken tot het tweede niveau. Er bestaat eveneens een grote consensus over de wenselijkheid of noodzaak dat het onderwijs op deze informatisering van de maatschappij zou inspelen. Al veel moeilijker is de vraag: wat moet dan in het onderwijs worden opgenomen? Zowel over de beoogde doelstellingen als de inhoudelijke en didactische invulling ervan bestaat nog lang geen eenstemmigheid.

Een waaier van vragen

Sommigen menen dat men zo vlug mogelijk moet leren programmeren. Anderen beweren dat dit soort programmeren in het lager en middelbaar onderwijs voor de vorming van een informaticus even nuttig is als het spelen met een meccano voor een toekomstig ingenieur! Evenals natuurkunde is informatica wel geen wiskunde, maar zij veronderstelt wel een behoorlijke wiskundige bagage. De vraag wordt dan: hoe ver kun je springen zonder die bagage? En loont het dan de moeite? Moet integendeel de opleiding van de toekomstige gebruikers op een volkomen andere leest geschoeid worden dan die van de toekomstige specialisten? Ook op dit punt kunnen wij de vergelijking met het fysica-onderricht doortrekken. In

[p. 635]

alle studierichtingen van het middelbaar onderwijs wordt natuurkunde geleerd, maar dat gebeurt niet om de leerlingen voor te bereiden op verdere specialisatie in die richting. Trouwens, het fysica-onderricht aan onze universiteiten begint als het ware ab ovo, zonder beroep op enige voorkennis. Die vergelijking leidt tot een tweevoudige vraag. Moet er, zoals voor natuurkunde het geval is, ook een soort algemeen vak informatica komen, om het even welke naam het krijgt? Of volstaat het de inhoud van een paar bestaande vakken aan te passen en bij te werken: b.v. iets over de werking van de apparatuur in het fysica-onderricht, iets meer over algoritmen in het wiskunde-onderwijs, iets over formele grammatica's in de taallessen? En in beide gevallen is de hamvraag: willen (moeten) wij onze jeugd veel meer bijbrengen over de computer dan wij haar ooit over de stoommachine, de auto, de televisie hebben bijgebracht?

Men kan het informatica-onderricht ook nog vanuit een heel ander standpunt - de zogeheten vormende waarde - benaderen. De computer blijkt een machine te zijn die bij de uitvoering van een programma een uiterst rigide logica volgt. Het is een al oude aanspraak dat leren programmeren een vorming in logisch denken zou geven. Is dat waar, of worden oorzaak en gevolg hier met elkaar verward? Gesteld dat die vormende waarde inderdaad bestaat, zijn we dan methodologisch al zo ver gevorderd dat wij een vorming in logisch denken kunnen meegeven via enkele (brok)stukken uit de informatica? Eertijds heeft men de studie van het Latijn ook gezien en gepropageerd als een training in analyse en synthese. Als eerste doelstelling kan het Latijn-onderricht echter ook de kennismaking met een van de pijlers van onze westerse cultuur beogen. In het eerste geval zal vertalen van Nederlands naar Latijn heel belangrijk zijn, in het tweede geval hoegenaamd niet. Mutatis mutandis zal de vormende waarde die men al dan niet aan de informatica toekent, in hoge mate de inhoud en de didactiek van het vak bepalen. Waarbij nog één opmerking op haar plaats is: gaat het daarbij om een nieuwe doelstelling dan wel om een oude die men nu met moderne middelen wil realiseren? Als het een oude doelstelling is, dan is het m.i. belangrijk aan de weet te komen waarom men nu naar een nieuw middel zoekt. Voldeed de vroegere methode niet? En mocht zulks het geval zijn, hoe kan men dan voorkomen dat men in dezelfde fouten vervalt?

[p. 636]

Minimale of maximale leerprogramma's

Het is niet verwonderlijk dat er nog steeds geen duidelijk antwoord bestaat op de vraag wat men nu eigenlijk van de informatica als vak in het onderwijs verwacht. Het zou een brede introductie kunnen worden, vooral als men er tamelijk vroeg mee begint, of een eerder specialistisch optievak dat ik dan in de laatste twee jaar zou situeren. M.i. is er vooral behoefte aan zo'n brede introductie: een soort kennismaking met de computer, een meegeven van ‘computer-geletterdheid’ of ‘computer literacy’, een opleiding tot ‘intelligent gebruiker’. In Nederland is in dit verband de term burgerinformatica opgedoken. Deze vorm van informatica-onderricht kan reeds vrij vroeg gegeven worden. Die introductie zou wel niet louter technisch mogen zijn en evenmin een encyclopedische verzameling van weetjes, maar zou inderdaad ook een zekere vorming dienen te geven. En dat behelst volgens mij dat men ook oefeningen en opgaven dient te voorzien. Van zo'n introductie verwacht men thans nog dat zij vertrouwd zou maken met de apparatuur. Zeker moet zij ‘proberen die relevante zaken te onderwijzen die toelaten problemen op te lossen met de middelen waarover onze leerlingen in de toekomst zullen beschikken’¹. Steeds meer probeert men dit te doen via pasklare paketten zoals tekstverwerkers, ‘spread sheets’ en dergelijke. Ik meen dat deze introductie ook een inleiding op het programmeren zou moeten omvatten. Dat wordt evenwel door steeds meer mensen in twijfel getrokken, in scherpe tegenstelling trouwens met de reeds ingeburgerde praktijk, waarin meestal veel aandacht aan het programmeren wordt besteed. Ik acht een inleiding in het programmeren nodig of ten minste heel nuttig om te voorkomen dat de leerlingen de idee en overtuiging meekrijgen dat de computer een eigen intelligentie heeft. Op het feit dat alles wat de computer doet hem door iemand werd voorgeschreven, krijgt men het snelst een goed zicht wanneer men zelf een paar korte programma's heeft leren schrijven. Dat leren programmeren scherpt tevens de aandacht voor de fouten die (aanvankelijk) haast altijd in een programma zitten en voor de gevolgen die zulke fouten kunnen hebben. Het eerste wat een inleiding op het programmeren zou moeten doen, is: de leerlingen correcte ideeën bijbrengen over het programmeren zelf. Dat is eigenlijk een heel moeilijke opgave, omdat men hun enig inzicht zou moeten bijbrengen in de complexiteit van de feitelijke, toegepaste programma's. De echte problemen die rijzen bij het vervaardigen van program-

1 J. Hebenstreit in H. Christiaen, Interview met J. Hebenstreit, in School en Computer, 1983 (III), 6, p. 2.

[p. 637]

ma's die werkelijk in b.v bedrijven worden gebruikt, houden o.m. verband met het feit dat die programma's veel omvangrijker zijn dan de programmaatjes die men in een inleidende cursus kan schrijven. Bij het schrijven van die grotere programma's hoort veel meer voorbereidend werk, met name op het vlak van de in te winnen en te verwerken domeinspecifieke informatie. Daar gebeurt heel wat anders dan dadelijk achter een klavier kruipen om te gaan programmeren. De leraar informatica heeft derhalve de ondankbare taak, ook al naar aanleiding van de eerste kleine programma's aandacht te eisen voor de methodische aanpak, de leesbaarheid van het programma, de correcte commentaar en desgevallend een goede documentatie. Ook op het vlak van de didactiek van het programmeren is er beslist nog veel werk aan de winkel. Ik vermeld hier slechts één punt. Vele zogenaamde inleidingen die bij een micro-computer geleverd worden, schijnen de instructies aan te leren in een volgorde die bepaald wordt door de groeiende complexiteit van de syntaxis van de verschillende instructies. Pedagogisch gezien lijkt mij dat een betwistbaar criterium. Men zou zo snel mogelijk een (samenhangende) subset van instructies moeten aanleren, waarmee zin volle programma's te maken zijn. En dat is heel goed mogelijk.

Gestructureerd programmeren, gestructureerd denken?

Men heeft het thans voortdurend over ‘gestructureerd programmeren’². Maar what's in a name? Gestructureerd programmeren bestaat m.i. vooral uit de volgende drie componenten:

1. ‘Top down’-ontwikkeling van het algoritme en zeker van het programma.

2. Gebruik van een beperkt aantal besturingsstructuren (‘control structures’).

3. Gebruik van invariante betrekkingen om de correctheid van het programma te verzekeren.

Bij de ontwikkeling van een programma werken leidinggevende informatici bij voorkeur in een welomschreven pseudo-code, liever dan met de meer bekende stroomschema's. Ik heb de indruk dat men bij het werken in

2 Voor een verkenning en beschrijving van begrippen als top down-analyse, algoritme, gestructureerd programmeren, stroomschema, Nassi-Schneidermanndiagram, Computer Assisted Instruction (CAI)... cfr. Jacques Haers & Henk Jans, Informatica en computer in het onderwijs, in Streven, juli 1984, pp. 928-940.

[p. 638]

pseudo-code verplicht wordt om meer aandacht te besteden aan de logica van het programma, om meer op logisch niveau te redeneren. Bij het gebruik van stroomschema's laat men zich voor vele punten leiden door (louter) visuele, grafische aanwijzingen; het ligt b.v. voor de hand dat in zo'n schema geen lijnen mogen voorkomen die op niets eindigen. Drukt men een selectie-instructie in een pseudo-code uit, dan dient men al dadelijk na te denken over de plaats waar de verschillende takken opnieuw zullen samenkomen. Bij het gestructureerd programmeren hebben alle structuren immers slechts één ingang en één uitgang. Bij dit alles stel ik mij echter wel de vraag of dit logische (allerminst natuurlijke) niveau wel voor iedereen toegankelijk is. Voor zwakkere richtingen blijven stroomschema's toch misschien aangewezen.

Van de term gestructureerd programmeren, die door Dijkstra gelanceerd werd, zijn tal van uitdrukkingen afgeleid zoals ‘gestructureerde stroomschema's’, ‘gestructureerde talen’ en zelfs ‘gestructureerd denken’. Met die uitbreiding en overdracht van betekenis zijn m.i. serieuze bezwaren verbonden.

Natuurlijk kan men zich bij het tekenen van stroomschema's ook de beperking opleggen slechts een beperkt aantal basisstructuren te willen gebruiken (naar analogie met wat het programmeren uiteraard en per definitie doet). In die omstandigheden wordt de term ‘gestructureerd stroomschema’ acceptabel. Wat mij betreft blijf ik die stroomschema's toch eerder zien als een hulpmiddel bij het ontwikkelen van programma's, een beetje zoals het rekenmachientje een hulpmiddel is bij het oplossen van problemen: het rekenmachientje kan niet in jouw plaats denken, jij moet de oplossingsmethode kennen. De stroomschema's zijn een (hulp)middel om het resultaat van een denkproces op papier te zetten. En het is tijdens dit denkproces dat men de regels van het gestructureerde programmeren moet volgen.

Men heeft het ook over ‘gestructureerde talen’. Daarmee worden de talen bedoeld waarin instructies zijn voorzien om het beperkt aantal controle-structuren van het gestructureerd programmeren rechtstreeks weer te geven. Dat zijn instructies als: ‘repeat... until’ (herhaal... tot dat), ‘while’ (zolang als... doe...), ‘if... then... else’ (indien... dan... zoniet). Persoonlijk zou ik dergelijke talen liever (m.i. juister) ‘algoritmische talen’ noemen. Maar dat is waarschijnlijk vechten voor een verloren zaak.

Tenslotte is men nog een stap verder gegaan en gewaagt men van ‘gestructureerd denken’. Daarmee wordt de draagwijdte van het gestructureerd programmeren nodeloos overtrokken. Om het nog maar eens te herhalen: het gebruik van een beperkt aantal basisstructuren, waarvan men de eigen-

[p. 639]

schappen goed kent, werd door de informatici ingevoerd als middel om de complexiteit van een programma onder controle te houden en tevens de correctheid van de uitvoering te verzekeren. Deze methodiek is hoegenaamd geen afspiegeling van onze normale manier van denken, die voortaan als verkeerd verworpen zou dienen te worden! Het enige wat in die methode naar andere gebieden overgedragen kan worden is de ‘top-down’- strategie voor de oplossing van problemen. Maar dat onderdeel kan men beter met zijn eigen naam blijven aanduiden, in plaats van te suggereren dat heel ons denken de weg van het ‘gestructureerd denken’ op moet. Het ‘gestructureerd programmeren’ is slechts een programmeringstechniek volgens de huidige stand van de informatica.

Vorming in logisch denken

Als doelstelling voor een inleidende cursus informatica in het secundair onderwijs wordt vaak de ‘vorming in logisch en probleem-oplossend denken’ genoemd. Men gaat daarbij uit van de onderstelling dat de in dit vak ontwikkelde denkwijzen ook gebruikt zullen worden in en overgedragen worden naar andere vak- en kennisgebieden. Die overdrachtskwestie is een heel delicate zaak. Ook het aanleren van Latijn en Grieks heeft men vaak verdedigd vanuit zo'n overdrachtsfilosofie. Voor Latijn en Grieks is die overdracht nooit bewezen. Maar toch werd en wordt er nog door velen in geloofd. Wat het informatica-onderricht betreft, zijn er reeds verschillende pogingen ondernomen om de overdracht naar andere gebieden te meten. Die metingen hebben vooralsnog geen positief resultaat opgeleverd. Waaruit je m.i. nog niet mag besluiten dat zo'n overdracht niet bestaat of niet mogelijk is. Bij alle onderzoekingen kwamen namelijk zwakke punten aan het licht, die het (voorlopig) uitblijven van duidelijke positieve resultaten kunnen verklaren. Eén zeer belanrijk punt bleek de opleidingsduur van de leerlingen te zijn: Latijn wordt gedurende zes jaar als hoofdvak onderwezen, terwijl de metingen voor informatica sloegen op een vak van 30 tot 40 lesuren. Vervolgens is steeds duidelijker gebleken dat overdracht van het ene vakgebied naar het andere doorgaans slechts gebeurt op voorwaarde dat men er uitdrukkelijk op aanstuurt. Ook in mijn persoonlijke ervaring vind ik dat bevestigd. Het verwondert mij telkens weer dat wij in onze boekbesprekingen er voortdurend moeten op wijzen dat probleemstellingen en probleemanalyses vaak zo onvolledig behandeld worden. Vele werkjes zijn nochtans geschreven door mensen met een degelijke wiskundige vorming. Ook bij die auteurs schijnt minder

[p. 640]

‘overdracht’ voor te komen dan men mag verwachten. Overdracht naar andere vakken lijkt mij pas haalbaar na een eerder specialistisch optievak in de laatste jaren van het secundair.

Wat nu van de aanspraak van de informatica dat ze een training in logisch denken zou geven? Vanzelfsprekend wordt een zekere mate van logisch denken vereist om b.v. fouten op te sporen. Iedereen die wat geprogrammeerd heeft, heeft beslist al vaker voor een programma gezeten waarin hij lange tijd naar de fout of fouten heeft moeten zoeken... Om te bekennen dat ze, eenmaal gevonden, eigenlijk evident waren. Zo'n situatie treedt b.v. op wanneer men in een BASIC-programma een logische variabele gebruikt, die bij conventie slechts de waarden 1 en 0 kan aannemen. Het kan dan gebeuren dat men bij de uitvoering constateert dat noch de sectie voorafgegaan door ‘if var = 0’ noch die voorafgegaan door ‘if var = 1’ door de computer uitgevoerd worden. Sommige leerlingen zijn dan geneigd om de computer menselijke trekjes toe te kennen: ofschoon de variabele volgens hun berekeningen b.v. 1 is, zou de computer weigeren de betrokken sectie uit te voeren. Dat soort reacties kent de computer natuurlijk niet; in dergelijke kwesties is hij volkomen logisch. De enige correcte conclusie luidt: de variabele heeft door een of andere fout van de programmeerder, andere waarden dan 0 of 1 gekregen. In zo'n geval noopt het programmeren de leerling inderdaad tot logisch(er) denken.

Vorming in probleemoplossend denken

Meestal echter wordt vorming in logisch denken in veel ruimere zin verstaan: het zou gaan om het leren problemen oplossen. Een tijd lang heeft men gedacht dat men algemene oplossingsstrategieën zou kunnen vinden, die voor nagenoeg alle toepassingsgebieden bruikbaar zouden zijn. Meer en meer blijkt echter dat voor het oplossen van problemen veel tot zeer veel domeinspecifieke kennis vereist is. Toch zijn er wel een paar elementen die in zowat alle oplossingsprocedures voorkomen. Eén daarvan is de al vaker vermelde strategie van de ‘top down’-benadering van het probleem. Het gestelde probleem wordt in deelproblemen opgedeeld, zodat het probleem opgelost is zodra men een oplossing voor die deelproblemen heeft. Vervolgens gaat men elk deelprobleem op een analoge manier aanpakken. Men vertrekt dus van een globale, weinig gedetailleerde oplossing en werkt die geleidelijk uit naar een volledige gedetailleerde oplossing. Men vergelijke dit met de manier waarop iemand tewerk gaat die een huis wil laten bouwen. Hij doet een beroep op een architect, die eerst een

[p. 641]

globaal plan van het huis maakt: aantal slaapkamers, grootte van living, garage, kelder enz. Dan wordt het plan verfijnd en in detail uitgewerkt tot het aan de aannemer overhandigd kan worden. Bij een van de topprestaties van de moderne techniek is precies dezelfde strategie gevolgd: toen de VS voor het eerst een mens op de maan wilden brengen, moesten ook zij beginnen met eerst de grote lijnen van die onderneming vast te leggen, om ze dan stapsgewijze tot in het laatste detail uit te werken.

Ook bij het oplossen van problemen in wetenschappen als de fysica is de ‘top down’-strategie meestal de begrijpelijkste manier van werken. Gewoonlijk kan men, puttend uit het bestand van de verworven wetenschap, een formule neerschrijven waarmee het gevraagde resultaat berekend zou kunnen worden. In die formule zullen nog verschillende onbekenden voorkomen: men gaat op zoek naar formules of betrekkingen, op grond waarvan deze onbekenden bepaald kunnen worden, tot men evenveel vergelijkingen als onbekenden heeft. Op dat ogenblik weet men dat de rest nog alleen een kwestie van uitwerking is.

Voor het inzicht derhalve in wat men aan het doen is (of hoort te doen) bij het oplossen van problemen, acht ik vertrouwdheid met de ‘top down’- strategie inderdaad heel belangrijk. Ter illustratie daarvan een eenvoudig en frequent voorbeeld. Geregeld komen leerlingen bij mij met oplossingen van oefeningen die zij van een medeleerling afgeschreven hebben: vaak zijn ze dan eerlijk genoeg om te bekennen dat die oplossingen hun wel correct lijken maar dat zij hoegenaamd niet begrijpen hoe men die kon vinden. Meestal gaat het om oplossingen die niet ‘top down’ maar ‘bottom up’ neergeschreven werden. Waarschijnlijk heeft de schrandere en mededeelzame medeleerling zelf de oplossing eerst ‘top down’ ontwikkeld maar is pas de uitwerking van de detailberekening aan het papier gaan toevertrouwen. De student die een aldus genoteerde oplossing in handen krijgt, blijft zich terecht afvragen hoe iemand ooit kan inzien dat hij met die detailberekeningen moest beginnen om bij de gevraagde oplossing te komen.

Indien men een vorming en training in het oplossen van problemen wenst te geven, dient men daarbij ook, zoals dat eertijds eveneens het geval was, oefeningen te voorzien. Heel in het algemeen kan het oplossen van problemen opgesplitst worden in een zogeheten analysefase en een uitwerkingsfase. Tijdens de analyse moet men proberen het probleem te situeren in een theoretische context: en daar komt opnieuw de (en vaak heel grote) domeinspecifieke wetenschap of informatie om de hoek kijken. Om een probleem behoorlijk in zijn theoretisch kader onder te brengen, is het nodig goed het toepassingsgebied van de theoretische formules te zien en de

[p. 642]

criteria te zoeken waaraan een probleemsituatie moet voldoen opdat zij in dat bepaalde theoretische model of die verklaring zou passen. Dat is een punt waarin ons onderricht waarschijnlijk nog dikwijls te kort schiet.

Wat heeft nu de informatica, en in het bijzonder het leren programmeren, op dit gebied als vorming te bieden? Voor men gaat programmeren moet men eerst een algoritme vinden om het gestelde probleem op te lossen³. Om dat algoritme te vinden zal men meestal een beroep moeten doen op domeinspecifieke kennis. In feite zal men het grootste gedeelte van de oplossing moeten suggereren. Men denke vooral niet dat een oplossing die gemakkelijk te begrijpen is ook gemakkelijk te vinden is! Dat hoeft helemaal niet het geval te zijn. Het legendarische ei van Columbus illustreert op treffende wijze hoe groot de afstand tussen het vinden van een oplossing en het begrijpen ervan kan zijn. Voor de omzetting tenslotte van het algoritme naar een concreet programma gebruikt men als referentiekader de richtlijnen voor het gestructureerd programmeren. Hierbij is het opnieuw heel belangrijk dat men duidelijke criteria aangeeft voor de toepassingsgebieden van de verschillende constructies. Hier komt dan het fundamentele verschil kijken tussen de klassieke stroomschema's en een goed begrepen gestructureerd programmeren. De kern van deze laatste methode is een systematiek om te zoeken naar het gegeven waarop getest moet worden, naar de vraag waar die test moet komen. Vooral in deze systematische analyse, in het systematisch opbouwen van het programma zit de vormende waarde. Bij de klassieke stroomschema's wordt dit alles overgelaten aan de vaardigheid van de programmeerder, in dit geval van de leerkracht. Al te dikwijls herleidt de uitleg bij een algoritme of programa zich dan tot een sequentieel met woorden weergeven van wat in het uiteindelijke stroomschema of programma voorkomt. De dynamische wording, de criteria die gehanteerd werden om die bepaalde constructie te kiezen, komen meestal veel te weinig uit de verf.

In de uitwerkingsfase tenslotte zal men de algoritmes en formules uitwerken volgens de eigen regels van die algoritmes en formules. Bij het eigenlijke programmeren - soms ook coderen genoemd - behelst dit vooral: zich heel strikt houden aan de syntaxis van de taal die men gebruikt. Hierbij is een grote zin voor accuratesse vereist. Het belang van deze synthese of realisatiefase moet men niet onderschatten. Ze mag zeker niet weggelaten worden. Er zouden aanduidingen zijn dat het leren programmeren bij kinderen een gunstig effect zou hebben op de nauwkeurigheid waarmee zij

3 Cfr. Het algoritmisch denken, in J. Haers & H. Jans. o.c., pp. 933-939.

[p. 643]

zich uitdrukken. Maar kan men een nieuw vak rechtvaardigen op basis van deze neveneffecten?

Tenslotte nog deze overweging. Als de informatica een nieuwe aanpak van het oplossen van problemen gevonden zou hebben, zou het dan niet efficiënter zijn deze nieuwe aanpak zo snel mogelijk in de opleiding van alle leerkrachten te integreren, liever dan ervoor een afzonderlijk vak te creëren?

Informatica in beweging

De informatica is minder af of voltooid dan men bij de veralgemeende introductie ervan in het onderwijs veelal schijnt te veronderstellen. Men zou wel eens te vlug bepaalde vormen of doelstellingen ervan als definitieve verworvenheden aan het jeugdige publiek kunnen opleggen. Zo hoort men nog dikwijls verkondigen dat het informatica-onderwijs, in alle geval, het algoritmisch denken moet bevorderen. Dat lijkt mij tegelijk overdreven en voorbarig. Om te beginnen wordt in deze uitspraak het algoritmisch denken soms nog verward met de veel algemenere strategie van de ‘top down’-ontwikkeling van een oplossing. Vervolgens is het algoritme in wezen een oplossing voor een probleem met behulp van (in de tijd) opeenvolgende handelingen. Er is dus een zekere tijdsafhankelijkheid mee gemoeid. En nu is juist deze tijdsafhankelijkheid afwezig in de meeste wiskundige bewijzen. In de wiskunde werkt men meestal met equivalenties, en die zijn niet afhankelijk van de tijd. Men heeft dan ook speciale technieken moeten ontwikkelen om de correctheid van algoritmes te kunnen bewijzen. En die technieken zijn verre van eenvoudig.

Het gevolg daarvan is dat men op dit ogenblik duidelijk streeft naar nieuwe talen, die dichter bij de normale wiskundige manier van werken staan. Men zoekt talen waarin men kan specificeren wat men wil bereiken zonder in detail te moeten specificeren hoe dat bereikt dient te worden. Men spreekt van declaratieve in plaats van procedurele talen. Dat is reeds zeer duidelijk het geval voor talen om een gegevensbank op te vragen. Men wenst te kunnen volstaan met b.v. de verklaring dat men al de personen wenst die in een bepaalde afdeling werken en in een bepaalde provincie wonen: hoe men daarvoor de gegevensbank moet doorzoeken, moet het systeem zelf maar uitmaken. In die talen zou het voor de berekening van het gemiddelde van een aantal waarden volstaan te specificeren dat het gemiddelde gelijk is aan de som van de reeks gedeeld door het aantal elementen van de reeks: hoe de berekening wordt uitgevoerd is de zaak

[p. 644]

van het systeem. Dit is ook de manier waarop ‘spread sheets’ geprogrammeerd worden.

Misschien is het feit dat wij nog zo veel aandacht (moeten) besteden aan algoritmes - aan het hoe meer dan aan het wat - een typisch trekje van een nog jonge, ik durf haast zeggen primitieve informatica. En zou derhalve de algoritmische werkwijze toch niet die grote verworvenheid zijn die wij absoluut aan heel onze jeugd moeten zien mee te geven. Anderzijds is het zo dat dit algoritmische aspect belangrijker wordt naarmate men dichter bij de machine komt. Het blijft dus een noodzakelijk element in de vorming van specialisten.

En daarmee zijn we weer bij een van onze eerste vragen beland: welk soort introductie in dit soort informatica hebben onze leerlingen nodig als toekomstige gebruikers van de computer? Men kan dit gebruik vergelijken met het gebruik van de auto: om een wagen - zelfs voortreffelijk - te kunnen besturen hoeft men geen specialist in automechaniek te zijn. Veruit de meeste gebruikers van de computer hoeven helemaal geen kennis te hebben van de elektronica en niet eens van het programmeren. Om de vergelijking met de auto door te trekken: er is allicht meer behoefte aan chauffeursopleiding dan aan opleiding van garagehouders. Als men het accent legt op het apparaat, dan krijgt men zeer terecht de vraag of we niet bezig zijn onze jeugd veel meer te leren over de computer dan over de auto of de televisie. Maar als de computer een instrument wordt waarmee iedereen in zijn beroepsleven en zelfs in de huiskring geconfronteerd zal worden, dan is de vraag of het niet de taak van de school is een efficiënt gebruik ervan aan te leren, zoals ze nu ook leert lezen en schrijven. Vandaar ook dat er een strekking is om informatica meer te organiseren rond het thema ‘informatie’ (verwerving, opslag, verwerking, verspreiding) dan rond het apparaat ‘computer’. In Nederland b.v. werd de term ‘burgerinformatica’ vervangen door ‘Informatieleer en Computerkunde’⁴.

Stilaan wint de overtuiging veld dat voor de meerderheid een opleiding uitgedacht moet worden die hoegenaamd niet gekopieerd is van een opleiding voor informatici. Dat soort onderricht zou meer de macroscopische aspecten moeten benadrukken en meer toepassingsgericht moeten zijn. Wordt hiermee de vormende waarde van de informatica niet voorgoed op de helling gezet? Wij menen van niet: het komt er veeleer op aan de juiste

4 Informatieleer en Computerkunde: over de inhoud van en apparatuur voor ‘Burgerinformatica’, Tweede rapport van de adviescommissie voor Onderwijs en Informatietechnologie, maart 1984, Staatsuitgeverij, 's Gravenhage (in België verkrijgbaar bij uitg. Van In).

[p. 645]

dosering te vinden tussen de vormings- en gebruikswaarde, afgestemd op de verschillende behoeften van het publiek en de daarbij beoogde doelstellingen. Ik blijf erbij dat er twee vormen van ‘denken’ zijn die wij vooral en in elk geval moeten stimuleren: logisch denken en creatief denken. Binnen dat wijde pedagogische veld moeten wij aan informatica en computer de plaats zien te geven die hun werkelijk toekomt.

Onlangs was het me gegund enkele ogenblikken van gedachten te wisselen met prof. Weizenbaum van het Massachusetts Institute of Technology. Ik vroeg hem wat hij vond van de verplichting aan sommige Amerikaanse universiteiten dat elke student zijn eigen micro-computer moet hebben. Zijn antwoord luidde dat niet iedereen het daarmee eens is en dat met name de fysica-afdeling van zijn universiteit geweigerd had de computerfaciliteiten voor haar studenten sterk uit te breiden. De uitdrukkelijke reden was: beslist voorkomen dat de studenten de bijgebrachte leerstof voortdurend of nog uitsluitend zouden gaan bekijken vanuit het standpunt: wat kan hierover geprogrammeerd worden? Wil men de computer zinvol inschakelen in het onderwijs, dan moet men vermijden dat hij er te pas en te onpas wordt bijgesleept. Er kan zeer veel, op een zeer goede manier, bijgebracht worden zonder computer. Wij moeten de leerstof niet aanpassen aan de computer, maar de computer gebruiken als een instrument naast andere, en liefst alleen daar waar hij superieur is aan die andere. Er zijn voldoende domeinen waar hij nieuwe mogelijkheden biedt.