søndag 15. november 2015

Processing

I de foregående blogginnleggene har fokus vært mot enkle progarmmeringsomgivelser som er tilrettelagt for eksperimentering i en begynnerfase, i hovedsak for barn. Jeg har sett på Scratch, Logo og MIT App Inventor og har så vidt sett på noen enkle paralelle programbiter i andre språk. Nå tenkte jeg å se litt på et programmeringsverktøy med en litt annen innfallsvinkel og begrunnelse: Processing.
På hjemmesiden presenteres Processing slik:
Processing is a flexible software sketchbook and a language for learning how to code within the context of the visual arts
.
Teknisk sett er språket et subsett av Java.
Det er også interessant å merke seg at store deler av Processing kan kjøres på en webside ved hjelp av et Javascriptbibliotek. Denne løsningen, Processig.js, er beskrevet som et eget produkt. Jeg bruker denne nedenfor for å illustrere noen enkle skisser, men merk at det er bergrensninger på hvor mye av Processing vi kan handtere på denne måten. Du finner flere eksempler på bruk av Processing.js på mine fagsider, Børres Processing .
Det er interessante å se Processing fra tre perspektiver:
  1. Hvor lav er inngangsterskelen, eller med andre ord hvem er en potensiell målgruppe.
  2. Hvor langt bringer Processing oss i retning av avansert programmering. Eller sagt på en annen måte: Er dette en vei å gå for å bli programmerer.
  3. Hvilke kvaliteter har det som uttrykksform, jfr. "...within the context of the visual arts", som nevnt ovenfor.

Basis

Vi tegner og skriver på en canvas. De grunnleggende rutinene er setup() og draw(). F.eks. slik:
// set up size and permanent settings
void setup() {
  size(200, 50);
  fill(0);
}
// draw a frame
void draw() {
  text("Hello World", 50, 20);
}

I prinsipp er det dette vi trenger for å fortsette å eksperimentere. Vi ser at det dukker opp en del uunngåelige ord (void) og parenteser av forskjellig type, () {}. Dette er da en del av javasyntaksen. Denne må vi ta med oss fra starten. Ikke så vanskelig å forklare, men det setter nok opp en barriere for noen potensielle brukere, erfaringsmessig mer avhengig av motivasjon enn av alder.

Fleksibilitet

Processing tilbyr oss et stort spekter av grunnleggende uttrykksformer når vi skal formidle noe på tegneflaten. Vi kan håndtere en rekke forskjellige former, linjer, tekst og farger. Dokumentsajonen er god og oversiktlig, men det tar trolig litt tid å skille det enkle fra det mer avanserte.
Vi kan ta vårt enkle hello-program et steg videre.: F.eks. slik:
/* @pjs preload="data/bs1.png"; */
PImage bs;  
float v=0.0;
// set up size and permanent settings
void setup() {
  size(200, 200);
  fill(0);
  textFont(createFont("SansSerif",18));
  bs = loadImage("data/bs1.png");  
  frameRate(30);
}
// draw a frame
void draw() {
  background(255, 255, 180);
  text("Hello World", 50, 150);
  translate(90,60);
  rotate(radians(v+=2));
  image(bs, -bs.width/2, -bs.height/2, bs.width, bs.height);
}
Sett fra en pedagogs synspunkt synes den umiddelbare grafiske responsen som Processing innbyr til som et godt læringsverktøy. Den gjør det mulig å assosiere til noen av tankene rundt Logo og beslektede uttrykksformer. Erfaringsmessig er det nok grunn til å være litt forsiktig med å legge for stor vekt på den ferske programmererens nysgjerrighet.

Struktur

Vi lager en skisse med noen baller som endrer farge når vi klikker på dem. Her har vi introdusert en egen beskrivelse av en ball, vi har laget klassen ball, og vi kan lage forekomster (objekter) av denne klassen. Det vil si at har innført objekt-begrepet i koden vår. Dette er på mange måter et viktig prinsipp som bringer oss et langt steg videre i forståelse av effektiv og strukturert programmering.
/* some balls on a table */
ArrayList <ball > allBalls = new ArrayList <ball >();

void setup(){
  size(150,300);
  allBalls.add(new ball(50,50));
  allBalls.add(new ball(100,150));
  allBalls.add(new ball(50,250));
  background(255);
  fill(0);
}

void draw (){
  for (int i = 0; i < allBalls.size(); i++) {
    allBalls.get(i).display();
  }
}

void mouseClicked(){
  for (int i = 0; i < allBalls.size(); i++) {
    allBalls.get(i).check();
  }
}

/* one ball with position radius and color*/
class ball{
  int xpos;
  int ypos;
  int rad;
  color clr;
  /* construct it, new ball() */
  ball(int xpos,int ypos){
    this.xpos=xpos;
    this.ypos=ypos;
    rad=30;
    clr=color(0,0,255);//blue
  }
  /* display it */
  void display(){
    fill(clr);
    ellipse(xpos, ypos, rad, rad);
  }
  /* check if hit and change color if so*/
  void check(){
    /* clicked on it ?*/
    if( (abs(mouseX-xpos)<rad) && (abs(mouseY-ypos)<rad) ){
      if(clr==color(0,0,255)) // is blue ?
         clr=color(255,0,0);  // red
      else 
         clr=color(0,0,255);  // back to blue
    }
  }
}

Hva kan vi gjøre med Processing ?

Det tredje perspektivet vi lanserte ovenfor var, ut fra Processings hjemmeside,: "...within the context of the visual arts". Nå er ikke min hovedbeskjeftigelse knyttet til denne typen anvendelser, men de verkøyene og bibliotekene vi finner tilsier at det er dekning for si at dette er en av Processings styrker. Det er også viktig å merke seg av lyd/musikk er godt ivaretatt.
Det er en side med Processing som kanskje er litt underkommunisert. Vi har en rekke verktøy for å handtere ulike typer dataformater og vi har verktøy som gjør det rimelig enkelt å visualisere data, i form av kurver, tabeller osv.
Dessuten styrkes støtten for 3-dimensjonal framstilling fra versjon til versjon. Dette basert på OpenGL.
Jeg vet ikke om skissene og argumentasjonen over bidrar til innsyn i Processing, men håper det kan bidra til nysgjerrighet på å finne ut mer. Det er ganske moro. Lykke til !

Linker

Processing
Processing.js
Børres Processing

søndag 1. november 2015

LOGO

Programmeringsspråket Logo ble lansert så tidlig som i 1967. Den personen som har stått som frontfigur for Logo er Seymour Papert. Papert hadde nær tilknytning til Piaget og ideen bak Logo knyttes til Piagets utviklingslære og det som pedagogene kaller en konstruktivistisk læringform. Det vil vel i korthet si at vi former mentale modeller baser på våre erfaringer. Alan Kay som jeg nevnte i forrige bloggpost var influert av Papert, og det er ikke så vanskelig å se at det paralelle tanker i Kays resonnementer om brukergrensesnitt ("doing with images makes symbols") og Paperts tenking bak Logo.

Jeg har ikke til hensikt å gå i detlaj om alle sider med Logo som språk. Kort sagt er Logo i sin opprinnelige form bygget på Lisp. I det halve sekelet som har gått siden Logo ble introdusert har det dukket opp et utall av varianter med litt forskjellige egenskaper og basert på forskjellige plattformer. Det finnes løsninger for websider, og det finnes "turtle"-biblioteker i mange forskjellige språkomgivelser.

Det er noen grunnleggende egenskaper ved alle implementasjonene som reflekterer den opprinnelige ideen. Metaforen er en skilpadde (turtle) som vi kan bevege ved hjelp av kommandoer. Vi kan la den gå framover (forward 20), vi kan la den snu seg et antall grader til høyre (right 30) eller til venstre (left 30) og vi kan la den etterlate seg et spor (pendown) eller gå sporløst (penup).

Logo ble opprinnelig implementert som robot og etter hvert som tegneomgivelse på skjerm.

Ideen er da for å si det enkelt at vi skal sette oss i skilpaddas sted når vi tenker og forsøker å lage noe eller utføre noe.

Noen enkle kodebiter

Ett (av mange) muligheter for å leke litt med Logo-konseptet er Turtle Academy.

Vi kan tegne et kvadrat med f.eks. følgende kode:

forward 100 left 90
forward 100 left 90
forward 100 left 90
forward 100 left 90

eller

repeat 4[forward 100 left 90]

Vi kan, og det er viktig begrepsmessig, lære skilpadda sammensatte begreper, f.eks. å lage et kvadrat. Merk at på engelsk framstår dette som angivelse av et verb. Vi burde kanskje si på norsk "å firkante" eller "å rute", men siden infinitivsmerket, TO, er en del av språket beholder jeg det.

TO square 
repeat 4[forward 100 left 90]
END

Da har square blitt en del av skilpaddas handlingsmuligheter. Vi har definert et begrep, et verb, en funksjon eller hva vi måtte ønske å kalle det. Aksjonen trigges kanske enkelt ved å skrive:

square

Og vi kan tegne flere kvadrater på forskjellige steder ved å skrive f.eks.

square
forward 100
square

Erfaringene med å introdusere Logo til lærere og elever på 80-tallet var at det i utgangspunktet skapte stor begeistring. Selv enkle innføringer som ovenfor åpnet øynene for at her ligger det nær sagt ubegrensede muligheter for å leke med geometri. Alle synes det var morsomt. Det er viktig å sette denne begeistringen inn i en situasjon der de teknologiske forutsetningene var sterkt begrenset, og det å få utført tegninger på en skjerm i seg selv var ganske innovativt.

Problemer oppsto imidlertid ganske raskt når man skulle gå videre og lage situasjoner der læringspotensialet skulle undersøkes. Kravet til forberedelse fra lærernes side ble nok kraftig undervurdert. Det var vel egentlig så enkelt som:
"Vi har en penn og nå kan du tegne hva du vil. Ja men hva skal jeg tegne og hvorfor ?".
Dette reiser noen interessante pedagogiske utfordringer eller dilemmaer. På den ene siden ønsker vi en situasjon der verktøyet er enkelt og inviterer til nysgjerrighet og utprøving. På den annen side er det trolig nødvendig med noen mer eller mindre klare utfordringer og oppfølging i bruk av verktøyet. Uansett hvor enkelt det kan synes er det større avstand mellom en ide og realiseringen av den enn det er med en penn på papir. Skolerte pedagoger kan analysere denne balansen i et konstruktivistisk perspektiv bedre enn jeg kan, men det er viktig å forstå hvordan verktøyet legger både praktiske og logiske føringer.

Nå er det mye mer i de fleste Logodialekter enn det som er skissert ovenfor. Vi kan arbeide med lister av tekster eller tall, vi har flere strukturer i språkkunstruksjonen, vi kan fylle områder med farge osv. Jeg forfølger ikke dette her. Du finner lett beskrivelser av litt ulike versjoner på nettet.

La oss ta for oss en tilsynelatende enkel problemstilling og se hva den kan føre til av problematisering og kanskje forståelse.

Vi lager en polygon-funksjon med parametere:

to polygon :kanter:lengde 
  repeat :kanter [
    forward :lengde 
    right 360/:kanter] 
end
 

Vi vil altså at skilpadda skal lage et polygon med kanter sider og der hver kant skal være lengde lang.

Dersom vi skriver polygon 4 30 får vi et kvadrat med sidekant 30

Dersom vi skriver polygon 8 30 får vi en åttekant med sider som er 30 lange.

Dersom vi skriver polygon 50 10 begynner resultatet å ligne på en sirkel.

Ikke så rart, men det reiser noen spørsmål.

  • hvorfor kommer skilpadda tilbake med samme orientering?
  • hvorfor kommer skilpadda tilbake til samme sted?
  • hvor stor er radien i den omsluttende sirkelen, gitt en bestemt verdi på parameteren lengde ?

Python turtle

En interessant implemntasjon av turtle-gtafikken er Turtle-biblioteket som er integrert i programmeringsspråket Python. Dette er interessant fordi det bevarer de grunnleggende ideene samtidig som det åpner for et bredere spekter av programmeringsmuligheter, dersom vi måtte ønske det.

import turtle

def polygon(steps,length):
    for i in range(1,steps+1,1):
        turtle.forward(length)
        turtle.right(360.0/steps)

polygon(4,50)
polygon(10,20)
polygon(36,15)

Vi ser blandt annet at vi snakker til objektet turtle med en vanlig dot-notasjon, turtle.forward(). Vi har dessuten brukt def til å definere funksjonen polygon, og løkkekonstruksjonen er litt annerledes. Python er på mange måter et språk med to ansikter. Enkle ting er veldig enkle, og mer intrikate ting krever ganske mye trening.

Scratch

For å trekke trådene tilbake til forrige blogg så ser vi at vi kan arbeide med det samme problemet ved hjelp av Scratch.

Linker

Logo på Wikipedia
Papert på Wikipedia
Turtle Academy
Dokumentasjon av Turtle-biblioteket i Python

mandag 26. oktober 2015

Piaget og programmering

En av de mest interessante pedagogisk forelesningene jeg har sett er Alan Kays foredrag med tittelen "Doing with images makes symbols" fra 1987. Originalvideoene ligger på nettet og det finnes en kortversjon på Youtube. Kay har også et innlegg i TED der han forfølger noen av de samme tankene.

Jeg skal ikke gi meg ut for å være noen velskolert pedagog, men jeg tolker tittelen "Doing with images makes symbols" direkte inn i Piagets utviklingslære der de tre begrepene "doing", "images" og "symbols"beskriver Piagets trappetrinn i barns forståelse og økende abstraksjonsevne.

Tidlig utviklingstrinn Kroppslig erfaring (doing)
Barndom Bilder (images)
Voksen alder Symboler (symbols)

Alan Kay er på mange måter kanskje den viktigste enkeltpersonen bak utvikling av grafiske, interaktive grensesnitt. Han utviklet dette hos Xerox forskningssenter og tok det senere med over til Apple, der det var basisen for programvaren for maskinene Macintosh og Lisa (1984).

Han står også, sammen med andre, bak programmeringsspråket Smalltalk som er et av de tidligste objektorienterte språkene, laget etter inspirasjon og mønster av Simula som jo er utviklet av våre landsmenn Ole Johan Dahl og Kristen Nygaard.

Det Kay gjør er altså å sette utformingen av grafiske interaktive grensesnitt direkte inn i Piagets pedagogiske modell. Han mener dessuten at uavhengig av alder er det viktig å kunne arbeide med alle disse nivåene (doing,images,symbols). Han hevder at samspillet mellom de tre stadiene generelt er viktig og kompletterende. Det er altså ikke slik at doing og images blir uviktig nå vi behersker symbolene. Han viser til Einstein som hevdet at han nærmest kunne føle modellene sine. Et annet eksempel er den paralelle og kompletterende utviklingen av elekrisitetslæren der Farady bidro med det eksperimenterende (han fikk antagelig støt), mens Maxwell tok seg av symbolene.

Vi kan illustrere grafiske grensesnitt slik, i den tidsånd der tankene ble lansert:

Nå vet vi at det har skjedd mye siden den tid. Musa er borte, eller i hvert fall mindre viktig, og scenarier der vi kan manipulere ulike typer symboler er, for å si det mildt, langt flere. Vi husker alle den oppmerksosmheten det reiste for noen år siden når vi oppdaget både ved personlig observasjon og via uttallige publiserte videoer, barn som manipulerer symboler med pekefingeren på en pad. Barn yngre enn to år sitter og leker med figurer og lyder på en pad. Terskelen for responsive "doing" er altså lang lavere enn den var og lavere enn de fleste av oss trodde den skulle kunne bli.

Det er tre interessante perspektiver på dette:

  • Kays hovedmotiv må vil vel kunne formulere slik at han ønsket at det skulle bli lettere for oss å handtere mer komplekse operasjoner på en datamaskin. I dag blir det nesten litt merkelig å si at dette har lykkes. Det er ikke så mange som husker alternativet; Hvordan det var å arbeide kun på en kommandolinje på en tekstskjerm.
    Riktig nok er det fortsatt slik at på noen områder der vi har god trening foretrekker vi å bruke kommandospråk eller enkle og direkte hjelpemidler. Personlige foretrekker jeg f.eks. å skrive HTML-kode "for hånd" i en flat editor fram for å bruke spesialiserte verktøy, for å ha full kontroll.
    Et interessant spørsmål er hvor bevisste dagens grensesnittdesignere er på Piagets utviklingsmodell når de utvikler metaforer og begreper. Av og til havner jeg bort i systemer der det åpenbart ikke er forstått.
  • Har denne tankegangen bidratt til at datamaskiner som medium har blitt bedre til å formidle kunnskap på en måte vi kan lære av? Dette var hovedhensikten med det initiativet som ble tatt i Norge og en del andre land på 80-tallet. Svaret er nok også her et ganske ubetinget ja. Svært små barn sorterer elementer, kopler bilder og lyder og bilder og tekster, kler på dukker med plagg og farger de liker og de møblerer rom i interaktive scener, spiller av videoer de liker for nte gang, for å nevne noen eksempler. Det er imidlertid fortsatt slik at det er ganske arbeidskrevende å lage slike læreprogrammer på en god måte. En del av de programmene som har eksplisitte holdningsdannende eller målrettede læringsformål, ut over ren symbolmanipulering, sliter både med motivasjon og innholdsutforming.
    Det trengs bedre skolerte pedagoger enn meg for å gå i dybden av dette, men en kan jo gjøre seg noen interessante observasjoner. F.eks. når den svært pad-aktive fireåringen svarer på engelsk eller teller til fem på en rekke forskjellige språk og har et ordforråd som er vesentlig større og mer presist enn det som var vanlig for en generasjon siden.
    Jeg er ikke i tvil om at mengden av kunnskapsbrokker har økt kraftig. Det som er den store utfordringen er å forstå hvordan denne økte kunnskapen blir sortert og hva dette vil bety for de kunnskapsbyggverk vi som individer sitter igjen med. Jeg vil dessuten tro at læringsvanene blir formet av disse tidlige erfaringene. Dette får bli tema for en senere blogg (full av spørsmålstegn).
  • Har denne tankegangen bidratt til at det er blitt lettere å forstå programmering? Kay var opptatt av dette helt fra starten. Av ulike årsaker øker behovet for å forstå og forme teknologien i den digitale verden vi lever i. Det er vel ikke slik at alle skal være programmere i tradisjonell forstand, men på den ene siden er en generell innsikt nødvendig for å forstå hva som skjer bak skjermen og på den andre siden er det i mange sammenhenger vanskelig å sette grensen mellom programmering og det vi kan kalle generell konfigurering og tilrettelegging av arbeidsomgivelser. Dette har selvsagt også et samfunnsperspektiv. Tilværelsen vår er målt og styrt av et nett av programmer som åpenbart former vår samfunn mer enn de fleste er klar over.
    Vi ser litt mer på programmering i dette Piaget-perspektivet nedenfor.

Hva med programmering?

Alan Kay hevdet han oppnådde langt raskere programmeringslæring med det nye grensesnittet. Det er opprinnelig Smalltalk som er referanserammen. I ettertid og etter mange års erfaring med å lære bort programmering i tilsvarende omgivelser er det vel rimelig klart at det er mye lettere enn det hadde vært uten et slikt grensesnitt, men "doing with symbols" - effekten har vel ikke vært helt overbevisende ut over en slags effektiviseringsgevinst på verktøysiden. Kay har i ettertid vært involvert i mange språkutviklingsprosjekter og forsøk uten at dette har hatt de helt store gjennomslag.

Det er imidlertid grunn til å se nærmere på en del av de verktøyene som dukker opp basert på den alminnelige "pek-dra-klikk" erfaringen som er nevnt ovenfor.

Vi kan jo kikke litt nærmere på Scratch fra MIT og se hvordan dette passer inn i bildet. I den forrige bloggen brukte vi en Scratch-variant i MIT App Inventor til å illustrerer kravene til struktur. La oss betrakte Scratch i et "Piaget-perspektiv".

La oss se på et enkelt eksempel der vi har plukket figurene fra standardtilbudet i Scratch. Eksempelet er kanskje ikke helt galt i forhold til det vi kunne finne på å invitere 1. eller 2.klassinger til å (være med på å) lage, med eller uten stavehjelp.

Vi har altså drag and drop (doing) tilgang til funksjonalitet og konstruksjoner. Merk for øvrig at vi har introdusert tidsstyring og vi sender meldinger som de andre aktører i scenen kan plukke opp. I og for seg avansert programmering, men altså her lett tilgjengelig og intuitivt(?). Vi kan kanskje også påstå at vi har definert objekter og gitt dem utseende og handlingsmønstre.

Vi hadde en tilsvarende konstruksjon i den forrige bloggen der vi brukte MIT App inventor som eksempel. Her er kravet til struktur litt annerledes, men prinsippene er de samme. Vi trekker elementer inn i konstruksjonen og elementene har former som angir om de passer eller ikke. Spørsmålet nå er: Hvor intuitivt og enkelt er dette ? Eller sagt på en annen måte: Hvor vanskelig er "doing" og hvor kort vei er det til "symbols"? Og videre hvor langt i symbolforståelse skal vi ha ambisjoner om å gå?

Vi kan se på et annet eksempel som nepper er typisk for de anvendelsene vi vil se flest av i Scratch, men siden matematikk var et tema i den forrige bloggen er jeg interesserte i å få kontroll over koordinater og bevegelse. Jeg har altså satt opp en bakgrunn som viser aksene, og jeg har valgt en figur som er et lite eple. Det er dette eplet jeg ønsker å kontrollere (bevege) ved hjelp av programmering. Det har dessuten en liten stilk som viser hvordan det er orientert i planet.

Vi ser at det fort blir litt mer utfordrende i den forstand at vi må snakke om grader og vi må kanskje abstahere litt når vi planlegger bevegelsen. Målgruppa er nok en annen enn eksempelet over. Jeg tenkte å se litt nærmere på dette eksempelet i forbindelse med Payperts Logo i en senere blogg.

Linker

mandag 19. oktober 2015

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:

f0 = 0, f1 = 1 og fn = fn-1 + fn-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:

"You probably know that arrogance, in computer science, is measured in nanodijkstras"

Linker

tirsdag 20. januar 2015

Om denne bloggen

Denne bloggen er ment å formidle noen refleksjoner og synspunkter på informatikkfaget (i vid forstand).

Min bakgrunn er 45 år med en salig blanding av programmering og forvaltning av IT-faget i et samfunnsperspektiv og i et pedagogisk perspektiv først ved Norsk Regnesentral og siden ved Høgskolen i Østfold.

Jeg har skrevet kode i det meste av gamle og nye programmeringsspråk. De jeg husker i farten er i kronologisk rekkefølge: Algol60, Basic, Simula, Cobol, C, Fortran, Pascal, C++, Smalltalk, Modula, Java, JavaScript, C# og Python.

Jeg var sterkt engasjert i arbeidet med informatikkfagets samfunnsbetydning i tiden ved Norsk Regnesentral på 70 tallet og jeg var aktiv både nasjonalt og internasjonalt i de innledende fasene med bruk av IT i undervisning på 80 og 90 tallet.

Det morsomste jeg har vært med på er vel byggingen av en informatikkutdanning ved daværende Høgskolen i Østfold i 1977. Vi startet tre stykker i en gammel skofabrikk uten andre føringer enn at vi skulle lage en edb-utdanning. Det gir grunnlag for mange refleksjoner å se den utviklingen som har skjedd av byråkratisering i høgskolesystemet, som på andre samfunnsområder, i tiden som har gått siden.

Mine ambisjoner er å komme tlbake til en del av dette i denne bloggen.