borresfagblog: Programmering og matematikk

Jeg er involvert i et prosjekt ved Høgskolen i Østfold som har som formål å se på programmering som et hjelpemiddel for å forstå matematikk.

Dette reiser en rekke interessante spørsmål. Jeg skal forsøke å ta opp noen av disse i noen blogginnlegg. Hensikten er ikke å forsøke og lage en komplett og balansert franmstilling men å peke på noen synspunkter.

Når daværende Kirke- og undervisningsdepartementet startet en stor offensiv for å se på bruk av IT (eller edb som det het) i undervisningen på 80-tallet hadde jeg gleden av å være med på laget og lærte mye av det. Hovedhensikten var å se om datateknologien kunne formidle kunnskap via innhold, og ikke primært som utviklingsverktøy. Det var imidlertid en del entusiaster som var ganske ivrige på å komme igang med programmering som en del av denne satsingen. Både valg av metoder og verktøy skapte en god del kontroverser.

For å forstå problemstillingen er det nødvendig å være klar over rammene for diskusjonen. Husk dette var lenge før internett og datamaskiner var en kostbar og begrenset ressurs. Programmering som allmenn beskjeftigelse var ikke noe tema. De dominerende språkene blandt ekspertene var typisk Cobol, Fortran, C, Algol og Basic. Informatikk som fag var en ganske unge disiplin og røttene for faget slik det ble definert på den tiden var å finne i matematikken.

Det interessante i diskusjonen var den konflikten som ganske raskt oppsto mellom den akademiske verden og de mer pragmatiske pedagogene. Informatikkens historie er full av «religionskriger» og jeg skal sette fokus på en av dem. Den akademiske verden var sterkt preget av ønsket struktur, systematikk og programmeringsverktøy som understøttet dette. Jeg vil bruke nederlenderen Edsgar Dijkstra som talsmann for denne tradisjonen med sterke røtter i matematisk tenking. Han hadde synspunkter og en form som, for å si det slik, skapte en ganske tydelig profil. Dijkstra sier selv at:

Programming is one of the most difficult branches of applied mathematics; the poorer mathematicians had better remain pure mathematicians.

Det var ikke alle i akademia som var enige med ham den gangen og det er nok ganske få som ubetinget vil gå god for dette idag. Etter mitt syn er det likevel viktig å være klar over hvor mye resonnementer i denne tradisjonen har betydd for utviklingen av programmering og programmeringsomgivelser. Dijkstra var selv aktiv i utformingen av det vi vel må kunne se som det første strukturerte språket, Algol. Dette sto i ganske sterk kontrast til andre programmeringsspråk som var i bruk på denne tiden, som Fortran, Cobol og Basic. Når programmeringstemaet dukket opp blandt pedagoger så var det Basic som var det nærmeste alternativet, både av praktiske og kunnskapsmessige årsaker. Dijkstra karakteriserte dette slik:

"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration"

og han hadde ikke mer sans for COBOL

"The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense"

Hva betyr nå egentlig dette for oss idag. Verden har gått videre og vi har fått enda mer strukturerte og strukturerende språk å modellere og å skrive i. Slik jeg ser det er det en ganske klar sammenheng mellom de matematiske røttene og dagens struktureret og objektorienterte språk.

La oss se på et superenkelt eksempel for å illustrere noen av Dijkstras poenger. Vi vil skrive ut alle Fibonaccitallene under 100. Der Fibonaccitallene er definert slik:

f₀ = 0, f₁ = 1 og f_n = f_n-1 + f_n-2 for n > 1

BASIC

...
f1=0
f2=1
again:
PRINT f2
 tmp=f2
 f2=f1+f2
 f1=tmp
IF f2 < 100 THEN GOTO again
...

Ikke alt for vanskelig verken å lage eller å lese. Den store svakheten er mangelen på inkapsling i en struktur. I prinsipp kan GOTO-kommandoen sende oss hvor som helst i et vilkårlig langt program. Vi kan ha mange labeler (again). Vi skal ikke ha for mange slike alternative hopp før vi mister fullstendig kontrollen over programmet, og rekkefølgen setninger utføres i.

Den matematiske tradisjonen innen informatikken hadde stort fokus på at programmer skulle være "riktige". Det vil si at de skal gjøre det de er tiltenkt. Det betyr at vi må definere problemet klart og vi må ha metoder for å etterprøve det vi har laget. Det har vært stor aktivitet for å forsøke å "bevise" programmer, uten at dette kan sies å ha kommet til særlig praktisk nytte for de fleste programmeringsoppgaver. Det vi da står igjen med er testing. Men også testing har begrenset verdi. Dijkstra konkluderer med at:

"Program testing can be used to show the presence of bugs, but never to show their absence!"

Dette forhindrer ikke at vi bør bruke alle de midler vi har for å ordne, strukturere og teste slik at vi finner flest mulig feil. Denne problemstillingen er selvsagt en helt annen i store programsystemer enn i de bitte små eksemplene jeg er innom her. Det skal imidlertid ikke mye fantasi til for å forstå at et program med et virvar av GOTO-setninger kan bli vanskelig å teste.

Vi prøver en annen innfallsvinkel til vår Fibonacci oppgave

MIT App Inventor

Selve språket er en variant av SCRATCH

Det som er interessant her er den faste, og uungåelige, strukturen i blokker som vi må bruke. Hver blokk har en inngang og en utgang. Dette er en av de mest grunnleggende prinsipene som ligger til grunn for strukturert programmering. Og altså slik jeg velger å tolke det her, en konsekvens av den strukturerende og matematiske tankegangen som har preget programmeringsfaget.

For en gammel programmerer kan det virke litt voldsomt å plukke sammen alle disse blokkene for å løse et ganske overkomlig problem. Det er fristende å gjøre det i litt enklere former, men beholde strukturen.

Javascript

function fib(){
   f1=0;
   f2=1;
   t=""
   while(f1 < 100){
      t+=f1+",";
      tmp=f2
      f2=f1+f2
      f1=tmp
   }
   alert(t)
}
...
fib();
...

Dersom vi ikke har noen begreper som hjelper oss, eller tvinger oss, til å skrive strukturert vil vi ha store problemer med å løse og teste selv ganske enkle problemer. Slike begreper vi være funksjoner, moduler, objekter og strukturerte utrykksformer i selve setningene.

Spørsmålet blir nå om det finnes noen motsatt effekt: Kan strukturert tenking og strukturert problemløsing, som i programmering, bidra til bedre matematikkforståelse eller mer interesse for matematikk? Eller sagt på en annen måte: Bidrar programmering generelt til bedre matematikkforståelse, eller skal vi kun ha ambisjoner om å illustrere enkeltproblemer. Dette er et interessant spørsmål. Jeg har ikke svaret, men vi kan jo sitere Dijkstra igjen:

"We must be very careful when we give advice to younger people: sometimes they follow it!"

I neste innlegg skal jeg forsøke og betrakte programmering fra et annet utgangspunkt, som en intuitiv undersøkende aktivitet.

En av de som har bidratt til slike resonnementer i Piagets ånd er Alan Kay. Kay som sikkert har sans for Dijkstras bidrag til informatikken, har mindre sans for stilen når han sier at: