Sosialgeometri

Av og til finner jeg at er det nyttig å introdusere noen begreper som ikke har noen rot i verken etablert teori eller praksis. Jeg gjør det for å etablere et holdepunkt for kommuniksajon og et en utfordring for min egen skriving og for argumentasjon. Sosialgeometri er et slikt begrep.

Begrepet har sin rot i et eksempel som er beskrevet nedenfor. Det er koplet til sammenhengen mellom programmering og matematikk. Hensikten er å se nærmere på hvordan samarbeid og deling av erfaringer kan realiseres og testes. Eksempelet bruker MicroBit og Processing.

Basiseksperimentet

Utgangspunktet er følgende scenario:

En PC med Processing installert, 5 MicroBits og 4 personer. Hver person har tilgang til en av microbitene 1..4. Når en person trykker på en av microbitens to knapper sendes et signal over radio til microbit 5. Denne sender meldingen videre til Proseccing-koden (sketchen) som identifiserer brukeren(1..4) og signalet(+/-), og tegner på skjermen.

I utgangspunktet er figuren på skjermen en rett linje. Oppgaven er, uten noen forklaring, helt enkelt slik: "Tegn et rektangel".

Dette eksperimentet er gjort med litt forskjellige brukergrupper i forskjellig alder. Deltagerne finner fort ut at streken brekker opp og at de har kontroll over vinkelen som endrer seg, pluss eller minus, når de trykker på en knapp. De har litt problemer med å finne ut hvem som kontrollerer vilken vinkel, og det kommer forslag av typen "vent litt vi må finne ut hvem som styrer hva". Hvis ikke alle fanger opp dette, og er enige, kan det bli misforståelser. Så begynner diskusjonen om rekkefølge og argumenter av typen "du må øke vinkelen for at..." og "vi må ta den vinkelen først".

Dette er en interessant sosial prosess som reiser spørsmål om innsikt, planlegging, ledelse og matematikkforståelse.

Når problemet er løst får gruppa en tilleggsoppgave: "Endre figuren til en trekant". Det er interessant å se hvordan erfaringene fra rektangelbyggingen påvirker strategien.

Et bredere perspektiv

Vi kan sette eksperimentet ovenfor inn i et større perspektiv for å kunne se litt mer på løsningsstratgier og læring. Et par skisser:

1. Vi kan tenke oss følgende oppsett: 1 eller flere grupper observerer hvordan en gruppe løser problemet. De kan observere arbeidet på storskjerm, men de får ikke lov til å påvirke prosessen med kommentarer eller forslag. Når gruppe 1 er ferdig skal den andre gruppa prøve å gjøre det samme. Det er da interessant å se om, og eventuelt hva, de har lært av å se den første gruppa. Dels er det interessant om diskusjonen raskt kan føre til enighet om en strategi (lik eller forskjellig) fra hva de første gjorde, og om noen får gjennomslag for en strategi. Det er nærliggende å bruke tidtaking som et mål på og som et incitament til rask problemløsning.
2. Et altenativt oppsett kan være slik: En gruppe løser problemet utan at de blir observert. Når de er ferdig skal de enten muntlig eller skriftlig overføre sine erfaringer til en ny gruppe. Dette gir en mulighet for å fomulere erfaringer, altså beskrive det de oppfatter som en effektiv problemløsningsstrategi. Hvis tidsforbruk trekkes inn bør det være slik at de to gruppene får en samlet tid, og at de konkurerer med andre slike "1 etter 1" gruppepar.

Begge strategiene ovenfor lar seg lett skalere opp med flere grupper og modifiserte strategier. Det er for eksempel enkeltt å kjøre flere grupper paralellt i samme rom. Radioverføringen av signaler mellom microbit kan knyttes til ulike frekvenser.

Oppsummering

Jeg mangler skolering i pedagogikk og didaktikk på et tilstrekkelig høyt nivå til å kunne framstille disse ideene i en velbegrunnet vitenskaplig setting. Det er min bakgrunn som lærer i programmering og problemløsning som inspirerer meg til å lete etter strategier som kan bidra til å forstå en del problemer som vi lett overser, eller muligheter vi ignorerer. Hvordan er det egentlig vi deler og organiserer erfaringer? Hva er snubletrådene og hva mulighetene?

Jeg begynte med å begrunne begrepet "sosial geometri". Begrepet er da i utgangspunktet knyttet til en sosial process for å i fellesskap(sosial) å lage et kvadrat(geometri). Kanskje det like godt kunne tolkes som strukturen (geometrien) i et gruppesamarbeid? Eller kanskje ikke.

Teknologien

Rent teknisk er eksempelet som er brukt svært enkelt. Det kan lett utvides programmessig og pedagogisk. Det er også slik at microbitene kan fange opp langt flere data enn knappetrykk, f.eks. aksellerasjon temperatur og orientering. Det dessuten mulig kjøpe tilleggsutstyr som øker repetoiret av sensorer betraktelig.

I eksempelet ovenfor er de 4 microbitene som gruppa har tilgang programmert slik (Javascript). "MB1" identifiserer microbit 1.

input.onButtonPressed(Button.A, function () {
    led.unplot(1, 2)
    led.plot(1, 1)
    radio.sendString("MB1:A")
})
input.onButtonPressed(Button.B, function () {
    led.unplot(1, 1)
    led.plot(1, 2)
    radio.sendString("MB1:B")
})
radio.setGroup(6)

Microbiten som tar i mot signalene og kommuniserer med Processing på PC er programmert slik:

radio.onReceivedString(function (receivedString) {
    led.toggle(1, 1)
    serial.redirectToUSB()
    serial.writeLine(receivedString)
})
input.onButtonPressed(Button.A, function () {
    led.toggle(1, 1)
    serial.redirectToUSB()
    serial.writeLine("Hallo")
})
radio.setGroup(6)

Oppsettet og programmeringen av PC'en i Processingog er detaljert beskrevet på websiden MicroBit og Processing

En enkel løsning kan være programmert slik (Java i Processing):

import processing.serial.*;
Serial port;
//Tegn et kvadrat
float side=100;
float[] vinkel;
float dv=5;// vinkel endring

void setup(){
  size(600,800);
  printArray(Serial.list());  
  port = new Serial(this,Serial.list()[0],115200);
  port.bufferUntil(10);
  
  vinkel=new float[4];
  vinkel[0]=vinkel[1]=vinkel[2]=vinkel[3]=0;
}
void draw(){
  background(255,255,255);
  translate(120,400);//origo
  scale(1,-1);// y oppover
  stroke(204, 102, 0);
  strokeWeight(3);
  for(int ix=0; ix < vinkel.length; ix++){
    rotate(radians(vinkel[ix]));
    line(0,0,side,0);
    translate(side,0);
  }  
}

void serialEvent(Serial port) {
 String inData = port.readString();
 // print(inData);
 decodeAndSet(inData.trim());
}

void decodeAndSet(String S){
  S=S.trim();
  String hva=S.substring(0,2);
  if(!hva.equals("MB")){
    println("error: "+hva);
    return;
  }
  //MB-indeks
  int ix=Integer.parseInt(S.substring(2,3));
  // button A or B
  String button=S.substring(4,5);
  println(ix+" : "+button);
  if(button.equals("A"))
    vinkel[ix-1]+=dv;
  else
    vinkel[ix-1]-=dv;
   
}
// mens vi tester:
void keyPressed(){
  if(key=='a') vinkel[0]+=dv;
  if(key=='A') vinkel[0]-=dv;
  if(key=='b') vinkel[1]+=dv;
  if(key=='B') vinkel[1]-=dv;
  if(key=='c') vinkel[2]+=dv;
  if(key=='C') vinkel[2]-=dv;
  if(key=='d') vinkel[3]+=dv;
  if(key=='D') vinkel[3]-=dv;
}

Linker

MicroBit
Processing
MicroBit og processing

Programmering er en sosial aktivitet

For mange er nok dette en drøy påstand. (F.eks. tror jeg min tålmodige hustru vil ha problemer med å godta den.)

Ikke desto mindre er det et aspekt som det er grunn til å legge vekt på både i en læringssituasjon og i programmering som yrkesuøvelse. I innlegget om iterativ utvikling pekte jeg på "Extreme programming" som en metode med noen interessant og anvendelige prinsipper.

• Problemløsning foregår i grupper. Alle i en gruppe har ansvar for løsningen
• Problemløsning foregår i små oversiktlige, veldefinerte steg.
• Testing foregår hyppig og testene er systematiske og planlagt.
• Parprogrammering. Det vil si at det alltid er to personer foran datamaskinen. Den ene skriver og den andre spør, foreslår og kommenterer. Rollene byttes, avhengig av oppgave eller ideer
• De enkelte stegene sjekkes ut mot oppdragsgiver

De to punktene som peker på gruppearbeid og parprogrammering er svært relevante også for undervising. Det er dette perspektivet, læringssituasjonen, jeg har som referanse i argumentasjonen nedenfor

Parprogrammering

Med parprogrammering mener vi at det alltid skal sitte to personer foran datamaskinen. Ofte betraktes dette som en nødløsning når f.eks. en klasse ikke har mange nok datamaskiner. Tvert imot er det en arbeidssituasjone med mange fordeler.

Det skal da være slik at de to samarbeider og deler kunnskap. Den ene skriver og den andre følger med og kommenterer og gir råd. Det er flere gevinster i dette

For det første den selvsagte at de tilsammen har mer kunnskap enn de har hver for seg.

For det andre er det slik at skrivingen i seg selv ofte virker litt blokkerende på resonnementet. Den lille ekstra vurdringen som er nyttig forsvinner mens du er opptatt med innrykk og parenteser. Den som ser på har akkurat den tiden til å resonnere og stille noen spørsmål.

Et trivielt eksempel er variabelnavn. Disse har en tendens til å oppstå nesten mens fingerenn er på vei ned på tastaturet og de blir ofte veldig korte, mens de burde vært laget med tanke på leselighet og eventuell omskrivning. Selv om det kan virke som litt overdrevent i øyeblikket kan det lønne seg å kalle en variabel "antallPunkter" istedet for "n".

Sidemannen kan komme med spørsmål av typen: "hvorfor deler du på 2 før du går inn i for-løkka ?". Hvis dette skjer er grunn til enten å skrive en kommentar som forklarer hvorfor, eller kanskje det etter litt ettertanke ikke skal gjøres.

Parprogrammering er mer enn at den ene skal lære av den andre. Det er selvsagt det også men tanken er at arbeidsformen i seg selv skal på virke arbeidet i positiv retning.

Det er et viktig poeng at arbeidsdelingen mellom tastaturansvarlig og kommentator skal veksle.

Gruppearbeid

Gruppearbeid og ansvarsdeling er jo ikke noe som er spesielt for programmering, men det er mitt intrykk at det ikke har fått den plassen det fortjener og at oppgaver ikke alltid legger opp til dette.

En kan godt tenke seg at en oppgave utformes slik at ulike grupper får ansvar for ulike deloppgaver. La oss se på et eksempel (som lar seg realisere i f.eks. Processing eller p5js). Oppgaven er ikke en begynneroppgave, men jeg bruker den her for for å illustrere tankegangen.

Anta at vi vil lage en løsning som skal kunne framstille ulike typer kurver (histogram, linjer, kakediagram,..) basert på data som er tilgjengelig i ulike typer dataformater (CSV, JSON, XML). Vi kan da formulere oppgave slik at vi setter opp et skjelett der vi spesifiserer hva en datafil skal inneholde og hva datasett skal kunne levere til en tegnefunksjon, typisk: getAntallVerdier, getVerdi(n), getNavn(n), getMaxVerdi(), getTittel()

En oppgave kan da være
"lage en klasse som leser en JSON-fil og etablerer et datasett-objekt med de spesifiserte leverings funksjonene"
,( eller i programmeringstermonologi: "implemeterer det ønskede interfacet".)

En annen oppgave kan være
"Skriv en funksjon som tar et generelt datasett som parameter og tegner et histogram"

For å teste sine egne delløsninger må alle gruppene ha et skjelett som tester at det de lager fungerer. De som arbeider med datasett kan minimalisere tegningen til f.eks. å skrive ut verdier som tekst, og de som arbeider med uttegning kan etablere dataset basert på variable, uten å lese og tolke filformater.

Deling

Det går an å legge opp oppgaver slik at deling og erfaringsutveksling foregår på en mindre organisert form. I blogginnlegget En rimelig oppgave beskrives en oppgave som har som å å produsere for utskrift. En av målene med dette er å skape en situasjon der elever/studenter kan vise sine produkter, sammenligne og kanskje bruke blyant til å komme med forslag til endringer.

Dersom produksjonen foregår mot websider som kan nås av andre er selvsagt også dette en måte å dele på. Diskusjoner og forslag kan formidles på alle slags måter på nettet og i samtaler, eller kanskje i plenumsvisninger.

Programmering er iterasjoner

Utvikling av ikke-trivielle programsystemer, systemløsninger, er en prosess som innebærer handtering av kompleksitet. Det har alltid vært en utvikling og løpende diskusjon om hvordan vi best skal handtere denne kompleksiteten på en metodisk måte som sikrer oss at vi får ut noe som er sikkert og vedlikeholdbart og som produserer det oppdragsgiveren vil ha.

Historisk sett har vi alltid hatt to skoler når det gjelder systemutvikling. Det kan sies mye om dette, men en kortform kan kanskje være slik:

På den ene siden har vi hatt "fossefalls"-metoden som baserer seg på at systemet kan gjennomanalyseres og designes på tegnebrettet, og at programmeringen blir en mer eller mindre mekanisk håndtverksjobb der alle spesifikasjonene er klare. Fordelene med dette er at vi gjøre en komplett analyse og lokaliserer alle de kritiske punktene i en tidlig fase av arbeidet. Ulempene er at verken utviklere eller oppdragsgiver er i stand til å se konsekvensene av krav eller beslutninger.

På den andre siden har vi hatt den iterative skolen som har har som basis at løsningen skal opp og stå fra dag en, og at den raffineres stegvis etter konsultasjon med oppdragsgiver. Fordelene er at vi avdekker designproblemer tidlig og at vi kan tilpasse oss erfaringene. Ulempene er at vi har dårligere kontroll over tidsplan og progresjon.

Det er den siste angrepsvinkelen som ser ut til å dominere programmeringsfagetfaget idag, og det er denne, som slik jeg ser det, er relevant for programmeringsundervisning. Det er de seneste årene utviklet noen tankesett som i aller høyeste grad er relevante.

Når vi sier at en metode er iterativ mener vi at vi definerer delmål og går fram stegvis. En sammenhengende metode som skal ivareta en slik arbeidsform er "Extreme Programming". Til tross for det noe dramatiske navnet er dette en jordnær arbeidsform som bygger på en del lettforståelige og effektive prinsipper. Slik vi ser det er disse prinsippene høyst aktuelle i programmeringsundervisning. De viktigste prinsippene, som vi bør vurdere, er:

• Problemløsning foregår i grupper. Alle i en gruppe har ansvar for løsningen
• Problemløsning foregår i små oversiktlige, veldefinerte steg.
• Testing foregår hyppig og testene er systematiske og planlagt.
• Parprogrammering. Det vil si at det alltid er to personer foran datamaskinen. Den ene skriver og den andre spør, foreslår og kommenterer. Rollene byttes, avhengig av oppgave eller ideer
• De enkelte stegene sjekkes ut mot oppdragsgiver

De momentene som tar opp de sosiale aspektene og de som handler konkret omfeilretting er drøftet for seg. La oss se litt nærmere på iterasjonsperspektivet.

Vi kan se på et enkelt eksempel. Oppdraget er formulert slik:

 Tegn en windmølle

Steg 1

løsning

Tilbakemelding på dette vil typisk være at en windmølle har tre blader, ikke 2

Steg 2

løsning

Tilbakemelding på dette vil kanskje være at møllebladne må jo festes på et hus

Steg 3

løsning

Og så vil vi måtte vurdere om bladene skal ha en annen form og hvordan huset skal utformes. Kanskje vi skal la oss inspirere til å la brukeren bestemme vindstyrken ?

Det er flere ting å merke seg med dette enkle eksempelet.

• Selv et enkelt eksempel som dette demonstrerer at det kan være nødvendig å gå stegvis fram.
• Den som har vært gjennom programmeringsøvelser av denne typen noen ganger vil trolig lære å lage kode som er forberedt for endringer.
• Ambisjonsnivået har en tendens til å øke etterhvert som løsningen utvikler seg. Dette er vel ikke alltid like bra og vi kan fort nærme oss det som er et problem for mange programmerere, et slags perfeksjonistsyndrom. Ting kan alltid bli bedre.
• Presisjonen i oppgaven kunne vært klarere i utgangspuktet, selv om intensjonen trolig var å lansere en enkel øvelse i vinkelberegning.

Hvis vi summerer opp noe av dette så er vi fort over på det som er et kjent problem i iterativ programutvikling, og som på engelsk kalles "the planning game". Essensen i dette er at en slik iteartiv arbeidsform med små steg med egne tidsfrister ofte kommer i konflikt med det som er rimelig eller avtalt som total utviklingstid. Det er åpenbart at dette kan være en vanskelig problemstilling i næringslivet, men det er også verdt å merke seg at denne problemstillingen er relevant også i undervisning.

Det finnes mange metoder innen programmering som er nær beslektet med Extreme Programming, f.eks. Scrum som også har et eksplisitt beskrivelse av kreative faser i arbeidet

Linker

Extreme Programming
Scrum

Programmering er en kreativ prosess

De fleste som betrakter programmering utenfra, altså uten å programmere selv, oppfatter det ofte som en slags øvelse i å skrive firkanta og uleselig tekst. Når det gjelder å skape nysgjerrighet og inspirere potensielle programmerere er det viktig å ta et slags oppgjør med slike holdninger. (nerdenes protest !).

Det er en generell og vanskelig diskusjon å vurdere innholdet i begrepet kreativitet. Et ganske vanskelig utgangspunkt er de som ensidig kopler begrepet til å komme opp med ideer uten å relatere det til verken handverkskompetanse eller gjennomføringsmuligheter. I og for seg en spennende aktivitet, men ikke nødvendigvis særlig produktiv. Det er min erfaring at en god del studenter som søker utdanning innen områder som digital design er hengt opp i et slikt holdningssett. De får ganske raskt sperrer når de innser at realisering av selv ganske enkle ideer krever både håndverk og systematisk planlegging. Det gjelder selvsagt ikke alle.

Det ligger en utfordring i å forsøke å få fram det kreative elementet i programmering, både for de som savner det og for de som ikke savner det. Etter min erfaring ligger de kreative utfordringene både i det du lager, produktet, og måten du konstruerer det på

Produktet

Mye av det vi som programmerere lager har et visuelt og ofte interaktivt grensesnitt mot brukeren. Vi skal presentere websider som helst skal fungere optimalt på ulike typer media, og vi skal lage konstrukjsoner som skal kunne vurderes og diskuteres ut fra utseende og funksjonalitet uten å kjenne alle detaljer i det som ligger bak. Det finnes naturlig nok metoder for å handtere prosesser for å finne gode løsninger som i stor grad følger aksepterte standarder, men det finnes også et stort rom for kreative, utradisjonelle løsninger

Spillprogrammering er på mange måter en historie for seg. Et spill skal formidle en setting, en metafor, og det skal implementere avansert interaksjon mellom spillere og mellom en spiller og de digitale omgivelsene.

Hvis vi setter dette inn i en opplæringssammenheng er det viktig å finne verktøy og oppgaver som utfordrer de kreative egenskapene. Det gjelder valg av programmeringsspråk og det gjelder valg av arbeisoppgaver. Vi må finne fram til oppgaver som hver for seg og i sammenheng gir en rask visuell respons på det som lages og som inviterer til å eksperimentere med løsninger.

For meg er det naturlig å se dette i sammenheng med de prinsippene som er nedfelt i Alan Kays referanse til Piaget når han bruker begrepet "Doing with Images Makes Symbols". Selv om Kays perspektiv i utgangspunktet ikke nødvendigvis er det kreative perspektivet, så er sammenhengen mellom konstruksjon og resultat et fundamentalt moment, på linje med det vi finner i tankegangen bak programmeringsspråket Logo. Vi må altså finne arbeidsoppgaver det det er kort vei fra programmeringen til den visuelle responsen. Jeg har skrevet mer om dette i innleggene "Piaget og programmering" og "En rimelig oppgave"

Det er også viktig å utvide perspektivet ut over "vanlige" skjermorientert programmer. Programmering av enheter av ymse slag som Lego, Arduino-enheter eller 3D-printing er en del av dette bildet.

Resonnementene mine over er direkte eller indirekte knyttet til en eller annen form for funksjonalitet. Vi vil finne kreative og gode løsninger for å vise fram noe eller gjøre det lett for brukeren av programmet å interagere med det vi lager. Det perspektivet som mangler er det som bruker digitale medier til å uttrykke noe. Det kan være et kunstverk, eller det kan være noe som skal promotere noe, en begivenhet, en sak eller et produkt, det vi kan kategorisere som reklame i vid forstand.

Mediene for dette er mange: Websider, TV, digitale plakater, projeksjoner på bygninger osv. For en programmerer som ser slikt materiale er det ikke vanskelig å se at det ligger ganske mye finurlig programmering bak for å få fram effekter av ulike slag, 3D-former, lyssetting, animasjon, relasjoner mellom objekter, for å nevne noen.

Et lite eksempel.

Dette eksempelet er ikke for å antyde at jeg er kunstner eller kunstekspert. Hensikten er bare å peke på at en digital innfalsvinkel kan gjøre noe med perspektivet

Den belgiske kunstneren Renè Magritte malte (første gang) i 1926 et bilde av en pipe som har tiltrukket seg en del oppmerksomhet. Som du ser på bildet under har han malt på bildet en tekst "Ceci n'est pas une pipe", eller på norsk "dette er ikke en pipe". Når Magritte ble spurt om hvordan han kunne mene dette svarte han: "Forsøk å stappe tobakk i den".

Det han forsøker å gjøre er altså å fokusere på forskjellen på en gjenstand og framstillingen av den. Det ligger langt utenfor min kompetanse å forsøke og forklare på en kort og konsistent måte surrealismens vesen og surrealistenes argumentasjon. Slik jeg oppfatter det, anser de en naturalistisk framstilling som lite interessant, og de forsøker å legge det "usynlige" inn i bildene. Magrittes naturalistiske bilde, med den gitte teksten, er slik forstått å understreke avstanden mellom bilde og "natur". De fleste av Magrittes bilder er ikke av denne naturtro typen. Tvert imot bruker han og andre surrealister argumentet til å endre den naturen han framstiller.

Hvis jeg nå, fra mitt teknologiske ståsted, vil ta dette et skritt videre kan jeg kanskje påstå om konstruksjonen nedenfor at "dette er ikke et bilde av en pipe" (Ceci n'est pas une image d'une pipe).

Med dette forstår jeg da at det finnes ikke noe fysisk bilde av noe som ser slik ut som det du ser på skjermen. Bildet skapes og gjenskapes hver gang vi ønsker å se det, i en eller annen synsvinkel.

Så kan man jo spørre seg hva surrealistene midt i forrige århundre ville ha laget dersom de kunne programmere interaktive framstillinger. I vår tid er det ikke akkurat mangel på manipulerte bilder med et visst "surrealistisk" preg.

Man kunne jo tenke seg at kommunikasjonsflaten mellom kunstner og publikum ville tjene på en dialog. Eller kanskje surrealismen ikke ville oppstått i den formen den fikk, dersom teknologien og mediebildet hadde vært som idag ?

For de som husker den første bølgen av digital kunst på 80-tallet har det skjedd mye med forutsetningen, men kanskje ikke like mye med aktiviteten ? Den gangen var det mitt inntrykk at det som ble vist fram var mislykkede eller manipulerte sirkelalgoritmer.

Konstruksjonen

Det som er vanskeligst å kommunisere til ferske programmerere er den kreative utfordringen og potensielle tilfredsstillelsen som ligger selve programmeringen.

Vi har i prinsipp nærmest ubegrensede muligheter når vi skal velge hvordan vi dekomponerer et problem og hvordan vi formulerer algoritmer.

Den metaforen som dukker opp i hodet mitt når jeg sliter med å finne "gode" løsninger er et slags landskap, med noen faste fjellformasjoner jeg kjenner igjen og noen uoversiktlige steinrøyser. For meg er det en kreativ utfordring å få orden på steinrøysene og stable stein i solide murer. En stein ligger ikke støtt hvis ikke underlaget er til å stole på. Når jeg står der med en stein i hånda har jeg mange muligheter og utfordringen er å finne en løsning som kan bringe meg videre.

Nå er det selvfølgelig slik at løsninger av den typen vi har vært innom ovefor i varierende grad er lagarbeid. Alle er ikke programmerere. Jeg tror imidlertid at det er slik at en viss insikt i prorammering er en forutsetning for å delta i et slikt lagarbeid på en konstruktiv måte.

Formidling av dette er etter min erfaring ganske vanskelig. For nye programmerere er ikke føleksen av handlefrihet så stor som den er hos de som har prøvd og feilet mange ganger. Igjen så dukker behovet for å kunne visualisere løsningen og å finne oppgaver som har kort vei fra kode til respons opp.

Linker

Piaget og programmering
En rimelig oppgave
Logo

Programmering er kopiering

Når vi skal løse et programmeringsproblem skriver vi i praksis aldri et program på blanke ark. Hovedregelen er at vi begynner jobben med å endre et program vi eller andre har skrevet før. Det vi tar med oss fra det vi kopierer fra kan være alt fra rene formalia som er nyttig eller nødvendig i alle programmer i det aktuelle språket, eller det kan være store deler av koden.

Praksis

Det kan være mange kilder for slik kopiering og omskriving.

Egne programmer

Dette gjør vi alltid og det er nyttig og i praksis nødvendig. Det er imidlertid noen momenter som en skal merke seg.

Det er lett å dra med seg dårlige løsninger og dårlige vaner uten å tenke på det, og det kan være at vi drar med oss løsninger eller lenker til ting som har gått ut på dato. De erfaringene vi gjør kan tilsi at vi bør gjøre noen endringer på "standardene" våre.

For eksempel bruker jeg alltid disse to filene når jeg starter arbeidet med en p5js-sketch:

<!DOCTYPE HTML>
<html lang="no">
<head>
 <meta charset="UTF-8"/> 
 <title>test</title> 
 <script src="https://borres.hiof.no/resources/p5js/p5.min.js">  
 </script>
 <script src="sketch.js"> </script>
</head>
<body> 
<div id="canvasHere"></div>
</body>
</html>

function setup() {
   var canvas = createCanvas(400, 400);
   canvas.parent('canvasHere');
}
function draw() {
   background(255,255,255);
   stroke(0,0,255);
   line(0,height/2,width,height/2);
}

lagrer dem som "test.html" og "sketch.js", åpner dem i editoren og jeg er i gang.

Min erfaring er at det er lett å undervurdere nytten av å skrive kommentarer til de løsningene vi bruker, både i selve koden og gjerne i en egen fil i det prosjektet vi arbeider med. Det er av og til forbløffende vanskelig å lese og endre sin egen kode som ble skrevet for noen måneder siden. Når vi skriver kode etablerer vi ofte et sett med logiske forutsetninger som vi sliter med å rekonstruere i en annen setting. Jeg har lært meg å lage en "readme.txt"-fil som har som eneste hensikt å forklare forutsetningene og løsningen for meg selv.

Medarbeideres programmer

Hvis vi arbeider sammen med andre i et prosjekt er dette både nødvendig og naturlig. Det bidrar til at flere øyne leser og flere tester blir gjort. I en startfase i programmering er det naturlig å bruke ganske enkle delingsmekanismer, som tilgang til en felles datalagringsplass og et eller annet kommunikasjonsmedium for å varsle om oppdateringer og endringer. Etterhvert er det naturlig å ta i bruk mer avanserte verktøy for versjonering.

Det er en rekke utviklingsmetodikk som på ulike måter og med ulike begrunnelser beskriver samarbeid i programutvikling og kodeproduksjon

Medstudenters programmer

I en studiesituasjon er dette en litt vanskelig problemstilling. På den ene siden er det åpenbart at det å dele erfaringer, ideer og programmer er et udiskutabelt gode. Når det gjelder gruppearbeid er situasjonen i prinsipp den samme som kommentert over.

På den andre siden er det vel alle underviseres erfaring at det foregår en del ureflektert kopiering for å bli ferdig med obligatoriske oppgaver innen tidsfristen. Det skjer uavhengig av tilbud om hjelp og veiledning. Det er av og til fristende som underviser ha en kynisk holdning til dette: Vil du ikke lære så er det din egen beslutning. På den annen side er det elementer i oppstart av en programmeringsundervisning som kan virke demotiverende på mange og føre til at arbeidsinnsatsen utesettes. Først og fremst gjelder dette trolig opplevelsen av å gjøre feil, av å mislykkes. Jeg har drøftet feilrettingsperspektivet i en annen artikkel.

Eksempler fra læremateriell

Dette er rimeligvis en god kilde, selv eksempler av og til kan være litt ensidige

Eksempler som er distribuert sammen med det utviklingsystemet vi bruker

Det varierer veldig hvor mye materiell som distribueres eller gjøres tilgjengelig i forbindelse med utviklingssystemer. Noen er eksemplariske gode og har svar på akkurat det vi lurer på. Det som ofte er et problem er at nivået på koden ikke er tilpasset nybegynnere.

Programmer vi finner på nettet

Dette er en interessant problemstilling og det er en del forhold som skiller programmering fra de fleste andre fagområder.

For det første er det en sterk kultur for å dele. Du vil finne forslag og forklaringen av de forunderligste problemer. Det finnes en rekke åpne utviklingsprosjekter der kode i nær sagt alle kompleksitetsgrader er tilgjengelige.

For det andre er det en slags "The truth is in the pudding" situasjon. Vi kan i de fleste tilfeller teste det vi finner og sjekke om det gjør det det gir seg ut for. Vi trenger normalt ikke gjøre systematisk bakgrunnssjekking for å se om noe er "sant". Dette er selvsagt ikke tilfeller der vi er ute etter mer avanserte systemer som f.eks. statistikkprogrammer eller lignende.

Metodisk

Som beskrevet over er kopiering og omskriving av kode en praksis som vi ikke greier oss uten, og etter mitt syn spiller det en avgjørende i rolle i læring. Det er interessant å se om vi kan finne angrepsvinkler der vi kan bruke kodekopiering systematisk i en oppstartfase.

Når det gjelder den grunnleggende forståelsen av syntaks og enkel algoritmeutforming kunne en tenke seg å la studentene få tilgang til kodebiter skrevet i forskjellige språk. Studentenes oppgave blir å forsøke å finne ut hva koden gjør og hva som må endres for å endre funksjonaliteten.

Vi kan illustrere det med et enkelt eksempel. Vi tar for oss en funksjon som skal summere tall fra 1 og opp til en grense. Vi kan se på dette i flere språk.

Java

int tall(int n){
  int sum=0;
  for(int i=1; i < n; i=i+1)
    sum=sum+i;
  return sum;
}
print tall(5);

JavaScript

function tall(n){
  var sum=0;
  for(var i=1; i < n; i=i+1)
    sum=sum+i;
  return sum
}
console.log(tall(5));

Python

def tall(n):
  sum=0
  for i in range(1,n):
    sum=sum+i
  return sum

print tall(5)

Basic

PRINT tall(5);

FUNCTION tall(n)
    sum=0
    FOR i = 1 TO n-1
        sum= sum + i
    NEXT i
    tall=sum
END FUNCTION

Det vi muligens kunne oppnå med dette er å illustrere noen prinsipper som er allmengyldige og det lar oss betrakte løsningen med litt forskjellige perspektiv. Det gir oss en anledning til å diskutere datatyper og syntaksregler.

Nå vil det være praktisk umulig å sette i gang en paralell prosess der vi inviterer studentene til å eksperimentere med flere utviklingsmiljøer. Den administrative jobben med å holde styr på omgivelsene vil trolig bli lang mer omfattende enn selve kodingen.

Vi kunne tenke oss et scenario der studentene arbeider, f.eks med JavaScript og undervisningen har innslag av kommenterte løsningsforslag i andre språk.

En åpenbar innvending er at dette er en veldig formalistisk angrepsvinkel og det vil neppe fungere som dominerende arbeidsform. Det kunne muligens brukes som et supplement, ikke i den kreative prosessen, men som en måte å få grep om noen syntaktiske og algoritmiske problemstillinger.

Programmering er feilretting

Opp gjennom årene har jeg erfart at mange, kanskje de fleste, studentene som begynner å programmere får en nedtur når de oppdager hvor mange feil de gjør. Det kommer som en ubehagelig overraskelse for de fleste at de må bruke noen timer på få rettet feil og få ting til å virke tilfredsstillende. Mange tar dette som et nederlag og havner i en situasjon der de opplevere at dette er ikke noe for dem; dette får det ikke til. Jeg tror det er flere årsaker til dette, og vi har kanskje ikke hatt tilstrekkelig fokus på de faktorene vi har kontroll med.

Programmering en øvelse som skiller seg ganske mye fra det de fleste nye studentene er vant med. Det finnes ingen ferdig formel som skal anvendes for å løse problemet. Det er ikke slik at vi enten kan løsningen eller ikke. Det finnes dessuten vanligvis ikke noen forutbestemt løsning, noen fasit. I starten gis det vanligvis ganske konkrete oppgaver som skal løses, men det finnes nesten alltid mange måter å gjøre det på.

Denne åpenheten skal kombineres med å lære seg noen formelle rammer som vi må arbeide innenfor, syntaksregler. Denne kombinasjonen av formalia og åpne problemstillinger er en utfordring. Vi er trolig for lite oppmerksomme på arbeidsformen og det tankesettet dette krever.

Det er kanskje slik at de fleste av oss som underviser er for nøye når det gjelder å vektlegge formalia. Kanskje inflytelsen fra Dijkstra er større enn vi vil innrømme, se Programmering og matematikk. Det manifesterer seg ved at vi er for opptatt av å vektlegge det som er optimalt og korrekt. Objektorientert programmering er et godt eksempel. For de av oss som har programmert en stund er det finessene som opptar oss og som vi gjerne vil formidle(interface, abstrakte classer, arv, innkapsling, aggregering). Kanskje vi skulle skulle bruke mer tid på at et objekt i grunnen er en samling av metoder og data, og utvide begrepsapparatet som svar på problemer når de dukker opp.

Vi har en tendens til å demonstrerer løsninger som tilsynelatende er naturlige og opplagte når vi viser dem i forelesninger eller legger løsninger på nettet. Vi kan bruke ganske lang tid dagen før på å forberede et eksempel som framstår som naturlig og "smart". Vi hopper lett over de timene vi brukte for å få eksempelet til å fungere, og vi underslår en beretning om arbeidsprosessen. Det vi underslår er feilretting.

For et par års siden gjorde jeg sammen med kollega Harald Holone et eksperiment i forelesningene der vi brukte to dobbelttimer til å utfordre hverandre til å løse et programmeringsproblem i plenum. Vi fikk oppgaven på stedet og vi var ikke forberedte på hva som skulle gjøres. Hensikten var at vi skulle forsøke og formidle hva og hvordan vi tenkte når vi gikk løs på en oppgave. Hovedfokus i våre intensjoner var å formidle hvordan vi skulle planlegge løsningen, men vi brukte nesten all tid på feilretting. Jeg tror ikke verken Harald eller jeg var særlig fornøyde med det vi laget, men studentene var veldig fornøyde med å oppleve at vi gjorde feil og faktisk rotet ganske mye, samtidig som vi faktisk kom fram til (litt ufullstendige) løsninger.

Jeg vil argumentere for å betrakte feilretting som normalsituasjonen i programmeringsarbeid. Det er det vi bruker tid på og det er det som er den mentale utfordringen for nye programmerere. En av inspirasjonskildene mine til dette perspektivet er John Pirzigs bok "Zen and the art of Motorcycle Maintainance". Hans forhold til reperasjon og vedlikehold av motorsykler kan lett overføres til programmer. Det interessante med Pirsigs resonnementer er at de er satt inn i en større sammenheng som berører begrepet kvalitet og beskriver en vitenskaplig innfallsvinkel til feilretting. Det vil føre for alt langt å gå løs på en komplett analogi mellom motorsykler og datamaskinprogrammer, men det er noen punkter i feilretingsstrategien som vi kanskje kan ha nytte av å tenke gjennom.

Når det oppstår en feil eller en utilfredstillende effekt. eller mangel på effekt, må vi forsøke og finne en feilrettingsstrategi. Tilfeldige innfall og kjapp fiksing fører oss ofte ut i et enda større uføre. Jeg tenker ofte på den situasjonen jeg var i når jeg begynte å programmere. Som studenter skrev vi programmene på hullkort og leverte dem i bunkevis til en datamaskinoperatør som la vårt program i en kø, leste dem etter hvert inn og kjørte dem. Hvis vi var heldige (og operatøren ikke hadde mistet hullkortene i gulvet) kunne vi hente en utskrift etter to-tre timer. Hvis noe gikk galt kunne det være en dump med sidevis fulle av oktale tall. Dette førte til at vi tenkte oss ganske godt om før vi leverte programmet til kjøring. I dag tar en slik test mindre enn et sekund. Av og til tenker jeg at de to sparte timene for manges vedkommende forsvinner i planløs testing.

Noen av nøkkelbegrepene i Pirsigs feilrettingsstrategi er: Dekomponering, systematisk komponenttesting, og hypoteser.

Når han skal fikse noe på motorsykkelen er han omhyggelig med analysere vilke komponenter som er involvert og hvordan de henger sammen. For oss som programmerere betyr vel det enkelt sagt av vi må ha oversikt over funksjoner, klasser og biblioteker, og hvordan de henger sammen. Læringseffekten av en slik dekomponering er forhåpemtligvis at vi tenker gjennom feilrettingsscenariet når vi planlegger koden. Jeg vil tro at de fleste drevne programmerere gjør dette, bevisst eller ubevisst.

Komponenttestingen krever at vi har laget koden slik at vi kan utsette delene for systematisk testing. Vi må f.eks. kunne kalle en funksjon med parametere der vi på forhånd har en hypotese om hva som lager feil og hvilke feil. Vi forstår ikke hva som er galt hvis vi ikke kan etterprøve slike hypoteser.

Det interessante med denne tankemåten er at den er svært generell og at den kan bearbeides og betraktes som en vitenskaplig metodikk. Hypotesetesting blir en jordnær og praktisk arbeidsform, og er et tankesett som er anvendbart i mange av livets situasjoner, enten det gjelder fag eller ikke.

En annen side ved feilretting er den sinnstilstanden vi har når vi går løs på arbeidet. Vi må oppfatte det som en konstruktiv og normal situasjon. Kanskje vi til og med har laget koden slik at feilen er som forventet i en tidlig fase av arbeidet. Hvis reaksjonen på en feilsituasjon er en følelse av utilstrekkelighet og rådløshet er sjansen for å finne feilen ganske liten. Det er også slik at vi av og til er i en modus der vi føler at vi ikke har overskudd, eller ro til å grave oss ned i en testfase. Min og mange andres erfaring er at det hjelper å komme vekk fra skjermen og ta med seg problemet gå en spasertur. Det er av og til forbløffende hvordan problemer kan falle fra hverandre, dekomponeres, når vi får litt avstand til dem.

Noen feil er lette å oppdage:

og lette og rette

mens noen feil krever litt mer analyse

Vi kan aldri bevise at et program er riktig, og vi må være forberedte på at det vil intreffe situasjoner der det oppstår feil. Feilkilder kan være vår kode, oppståtte feil eller endringer i datagrunnlaget eller nettverket eller systemet programmet inngår i.

Min tanke er at et program i prinsipp er i en slik situasjon fra det øyeblikk vi begynner å skrive, og i hele programmets "levetid".

Å forvalte et fag

Som underviser er fagforvaltning et sentralt begrep for meg. Det innebærer flere ting. Det betyr slik jeg ser det at du skal ha gode håndverksmessige ferdigheter, at du skal søke ny kunnskap og innsikt og at du skal formidle din forståelse av faget gitt de kulturelle og samfunnsmessig rammene du arbeider i. Det kan sies mye om dette og vektlegging av de ulike aspektene, men det jeg er opptatt av i dette innlegget er det preget den som underviser/formidler setter på faget.

Vi ser konturene av en ny runde med nettbasert læring med de såkalte MOOCs (Massive Open Online Courses). Det er lett å se en rekke fordeler med dette. Vi vil få gode formidlere, standardisering av innhold og mulighetene for å etablere læringskollektiver i form av samarbeid mellom studenter uavhengig av institusjon. Det er imidlertid noen årsaker til å gå litt forsiktig fram. Standardisering kan føre til mangel på innovasjon og det vil innebære en utfordring som en del institusjoner ikke kommer til å takle. Jeg vil imidlertid her fokusere en litt annen problemstilling. En av mine største bekymringer i forbindelse med nettundervisning og utviklingen av verdensomspennende MOOCs er at vi kan få en slags sterilisering av fag. Med det mener jeg at faget blir tatt ut av kontekst og tradisjon. Formidleren, læreren, og det samfunnet du lever i definerer en kontekst som er viktig i fagforvaltning.

Jeg tror de fleste har det slik at når de arbeider med et eller annet, enten som fagforvaltere eller som fagutøvere, så har de implisitt eller eksplisitt en referanse til sin egen læringssituasjon i tilsvarende fagområde. Jeg har hatt gleden av å lære av en del personer som ikke nødvendigvis alle var verdens beste pedagoger, men som forvaltet sin fagkunnskap og sine holdninger til faget og fagets rolle i samfunnet på ulike måter. Denne læringen har definitivt preget mitt syn på faget i ettertid. Jeg skal bruke noen eksempler for å illustrere hva jeg mener.

Som ung hadde jeg gleden av å være student hos og etter hvert kollega på Norsk Regnesentral med to av de mest markante personene i norsk databehandlingshistorie, Kristen Nygaard og Ole Johan Dahl.

Nygaard var en person som snakket i ganske store bokstaver og satte sitt preg på de fleste forsamlinger. Han arbeidet med faget i en svært vanskelig setting i de legendariske prosjektene med de ansatte og fagbevegelsens innflytelse på styringssystemer. Mye av dette er senere kjent som den nordiske modellen. Jeg lærte ikke så mye datafag i snever forstand av dette, men jeg fikk et innblikk i holdninger og arbeidsformer som ble laget der og da. Forskjellen på aksjonsforsking og deltagende forskning ble drøftet, analysert og eksemplifisert på en måte som neppe hadde kunnet blitt formidlet via et standardisert MOOC. Dette var en nyttig og nødvendig diskusjon for oss som tilhørte den moderate delen av 68-generasjonen. I ettertid har jeg jo forstått at denne måten å tenke på er en ganske generell måte å forstå og agere på i et samfunn som vårt og at det går rett i kjernen av mange av de generelle problemstillingene vi strir med i dagens samfunn. Stikkord er pulverisering av ansvar, reduksjon av betydningen av faglighet og konsekvensene av rigorøse styrings- og kontrollsystemer. Et annet perspektiv på dette var konflikten mellom Nygaard og den svenske professoren Børje Langefors i synet på systemutvikling. Sistnevnte var talsmann for en ren matematisk informasjonsanalyse ved systemutvikling, mens Nygaards søkte etter verktøy for å realisere en reell medvirkning. Det var lærerikt å ha Langefors arbeider som hovedfagspensum samtidig som jeg var kollega med Nygaard. Et generelt systemutviklingsfag som drøftet disse perspektivene under samme hatt ville umulig kunne gi den samme innsikten.

Ole Johan Dahls minimalistiske og presise analyser av algoritmer er legendariske og hele hans framtoning understreket dette på en måte som gjør at jeg den dag i dag forsøker å spare en byte eller to hver gang jeg skriver en triviell algoritme. Men samtidig, og det er ikke uviktig i denne sammenhengen, var han en veldig hyggelig fyr som røkte pipe og likte opera.

Senere arbeidet jeg i regi av Utdanningsdepartementet sammen med en canadisk ingeniør, Les Green, med utforming av pedagogisk programvare. Han formidlet et pedagogisk syn som var svært grunnleggende forskjellig fra den Skinner-pedagogikken som var framherskende i forbindelse med IT-basert læring på 80-tallet. Han hadde skrevet en bok om dette som ikke var spesielt overbevisende, men måten han forvaltet sitt syn på faget i praksis var ekstremt klar og informativ. Jeg husker en del veiledningssesjoner der ivrige designere viste hvor du skulle klikke på skjermen for å oppnå en eller annen reaksjon. Hans spørsmål var kort og godt: «Why would I like to do that ?». Dette var i all sin enkelhet grunnlaget for en uunngåelig og nødvendig diskusjon av pedagogikken i prosjektet. Jeg oppdaget at jeg ikke hadde forstått mye av prosjektveiledning før jeg så han i aksjon.

Nå er det jo ikke alltid at fagformidling er ensidig konstruktiv og givende, men læringen kan likevel være verdifull. Min første erfaring med fagforvaltning som gjorde inntrykk var på grunnskolen. Jeg hadde en lærer som konsekvent rettet «ansikt» til «andlet» i stilene mine. Han ga ikke noen grunn for dette og jeg husker jeg var ganske forbannet. I ettertid har jeg forstått (tror jeg) at han var en av de få som tok samnorsken alvorlig på 50-tallet. Hva jeg lærte av det? Jo jeg tror at hans bidrag til min språkbevissthet var lang større enn hans bidrag til samnorskens utbredelse, og det fjernet effektivt den unge elevens tro på skolen som formidler av den nøytrale og endelige sannhet.

Et annet eksempel er når jeg som kybernetikkstudent på Universitetet i Oslo hørte på et foredrag av den legendariske professor Balchen fra daværende NTH. Balchen var en meget anerkjent og respektert fagmann med klare meninger. Jeg husker han gikk langt i sitt foredrag i å peke på at store deler av samfunnet med fordel kunne styres mer eller mindre automatisk etter reguleringstekniske modeller. Antagelig, jeg er ikke sikker, ønsket han å provosere oss. Han lykkes i den grad at det ga opphav til ganske mange diskusjoner i studentmiljøet i etterkant om forholdet mellom det teknisk optimale og det menneskelige og demokratiske, hvilket jo ikke har blitt et mindre aktuelt tema med årene.

I sum tror jeg ikke så mye på at undervisning kan være nøytral og jeg tror ikke den bør være det. Det er generelt sett to viktige prinsipper som er relevante i denne sammenhengen og som må ligge til grunn når en skal fungere som lærer eller fagforvalter.

For det første må man være ærlig om hva en kan og hva en ikke kan. Som forvalter av IT-faget i mange år har jeg ganske god samvittighet på dette punktet. Det er min erfaring at studentene har forståelse for at det er begrensninger i hva enkeltpersoner kan av faglige detaljer og at ærlighet på dette området styrker troverdigheten.

For det andre bør en være tydelig på hva man mener om ulike sider ved faget og fagets plass i samfunnet. Her har jeg vesentlig dårligere samvittighet, og det burde de fleste av oss ha. Jeg har ofte undret meg over dette. De fleste av de kollegene jeg har hatt opp gjennom årene har vært samfunnsbevisste og reflekterte personer, men har som meg, vært tilbakeholdene med å eksponere sitt syn som en del av fagforvaltningen. Den nærmeste forklaringen er trolig redselen for det man litt lettvint kan kalle «å politisere» faget. Det er jo mulig å betegne alle meninger som politiske i en eller annen forstand og vi har hatt en utvikling der skillet mellom fag og politikk har blitt større. Det har for å si det litt innfløkt blitt politisk ukorrekt å blande fag og politikk. Dette bør ikke stoppe meningsutveksling om fagets samfunnsrolle. Når jeg ser dette i perspektiv er det en faktor som har med dette å gjøre som har endret seg kraftig, og det er studentenes engasjement. Ved den institusjonen jeg kommer fra har studentene blitt lokket til å være med på trekning av en iPad for å delta i valg til sine egne demokratiske organer. Det ligner, for å si det mildt, ikke mye på den situasjonen jeg opplevde som fersk student fra landsbygda på slutten av 60-tallet. Nå sier jeg ikke dette for å legge skylden på studentene, men en kan i alle fall trygt si at studentene ikke presser på for å få til en samfunnsdebatt om faget.

Det blir et dilemma når strategiske planer for utdanningen informatikk ved de fleste institusjoner peker på informatikkfagets spesielle situasjon som premissleverandør for nesten alle andre fag, uten at dette problematiseres i en samfunnsmessig og politisk sammenheng. Dette åpner for en ganske omfattende og viktig debatt i dagens samfunn der stikkord kan være big-data, personvern, falske data, sikring av infrastruktur, og tvilsom bruk av data både i forskning og som politisk premiss. Hvor mye ansvar har vi som fagforvaltere i informatikk for dette?

Dette får jeg se nærmere på i et senere innlegg, hvis jeg får tid og gjerne noen konstuktive innspill.

Å undervise i en grenseløs verden

Vi opplever (igjen) et sterkt fokus på nettbasert læring. Dette gir grunnlag for noen refleksjoner. Mitt utgangspunkt er lang erfaring i undervisning i informatikk og beslektede fag. Dette er fag som er basert på en del grunnleggende prinsipper og begreper. Disse prinsippene og begrepene er ganske stabile men anvendelsene og betraktninger rundt disse er, for å si det mildt, svært dynamiske. Det er i dag et fag der den komponenten vi kan kalle livslang læring er helt nødvendig og vi er avhengig av å beherske internett som informasjonskilde.

Den første bølgen av nettbasert læring, eller egentlig utdanning, på 90-tallet levde av flere grunner ikke opp til de store forventningene som ble skapt. Mange av de løsningene som har røtter i denne bølgen er vel med respekt å melde ikke særlig interessante. I beste fall er de kanskje livbøyer for lærere som ikke er bekvemme med å bruke digitale verktøy. Når vi nå ser en ny bølge representert med de såkalte MOOCS (Massive Open Online Courses), er det grunn til å se nærmere på noen sider av temaet igjen. Teknologien og bruken av den tilsier at vi trolig står overfor en interessant utvikling og at vi etter hvert vil møte på en del dilemmaer som er lite debatterte.

NOU 2014:5 MOOC til Norge – Nye digitale læringsformer i høyere utdanning gir et godt øyeblikksbilde over temaet men er etter mitt syn litt utydelig når det gjelder konsekvenser og dilemmaer.

Noen antatte utviklingstrekk

Hvis MOOC blir så massivt som mange tror.

• Utdanning når ut til fler og lar seg tilpasse ulike livssituasjoner. Geografi betyr ingenting og du kan følge kurs på heltid eller deltid.
• Det vil bli billigere. I utgangspunktet ser det ut til at tilbudene er gratis og at prisen for å få en godkjent eksamen blir svært mye lavere enn kostnadene ved et studieopphold. Det er jo også mulig at vi vil se firmaer eller institusjoner som lager godkjenningstilbud basert på andre institusjoners kurs.
• Det vil bli mulig å sette sammen kompetanse på en mer fleksibel måte med å plukke kurs fra forskjellige leverandører. Dette med nye fagprofiler er en utvikling vi har sett lenge og som har fått forbløffende liten oppmerksomhet. Sherry Turkle pekte i sin bok «Life on the Screen» på dette alt på 90-tallet. Etter mitt syn er dette en bra og uunngåelig utvikling. Det er imidlertid ikke uproblematisk verken for arbeidstager, arbeidsgiver eller utdanningssystemet.
• Det er trolig uunngåelig at vi får en rekke standardiseringsinitiativ. Det er i alle fall fire mulige initiativtagere til dette.
1. Det er sannsynlig at nasjonale utdanningsmyndigheter vil søke og rasjonalisere utdanningen ved å realisere spesialiseringer der ressurser kan settes inn ett eller noen få steder på øremerkede fagdomener.
2. Det vil også være ganske rart om ikke EU vil oppfordre til standardisering og i noen grad spesialisering. Begrunnelsen vil som tidligere være ønsket om å gjøre arbeidssøkernes kompetanse sammenlignbar på tvers av landegrensene.
3. Internasjonale organisasjoner innen forskjellige fag vil kunne anbefale, rangere eller legge rammene for kurs.
4. Firmaer vil bruke kurstilfanget som basis for både sertifisering og rangering av søkere. Et godkjent kurs fra et prestisjeuniversitet vil trolig tillegges mer vekt enn et kurs fra en norsk høgskole. Det er ikke noe nytt i dette, men problemstillingen vil bli en helt annen når MOOCene med formell godkjenning blir vanlige.

Noen dilemmaer

Enkeltinstitusjoner vil måtte ta noen svært vanskelige beslutninger. Det virker på meg som det er noen relativt grunne vurderinger som råder. I hovedsak er drivkraften å få lagt ut kurs på nett, uten å tenke gjennom verken metoder, kostnader eller konsekvenser.

En del entusiaster begynner resonnementet med å snakke ned forelesninger som undervisningsform med begrunnelsen at slik har vi gjort i tusen år og nå er vi i en annen tid. Dette etterfølges pussig nok av en litt lettvint argumentasjon for å legge forelesningene på nett.

For det første undervurderes kostnadene med å gjøre noe så tilsynelatende enkelt som å legge ut en forelesning kraftig. Det er ikke bare å sette opp et kamera og la det gå. En slik lettvint holdning vil være den sikre veien til å tape den konkurransen som er uunngåelig. De store aktørene vil etter hvert gjøre dette på en måte som både i form og innhold er teknisk bra. En kollegas forsøk på å ta videodokumentasjonen alvorlig tilsier at etterproduksjon og redigering er langt mer tidskrevende enn det det er mulig å forsvare innenfor rammene av en normal arbeidstid. I hvert fall i vårt fag er det en farlig illusjon å tro at varigheten på materialet er lenger enn i beste fall 2 år.

Det neste momentet er at forelesningene i seg selv har begrenset verdi. Youtube er i dag full av videoklipp av varierende kvalitet som forklarer de forunderligste ting i varierende grad av detalj. Dersom en skal komme forbi den rene videoformidlingen må virksomheten støttes med andre virkemidler på sosiale medier. Vi må forvente at slike mekanismer vil være godt utbygd hos de tunge leverandørene, enten fordi de tilrettelegges av leverandøren selv eller fordi de organiseres av kursdeltagerne.

En av mine største bekymringer er at vi kan få en slags sterilisering av fag. For meg er dette med fagforvalting et sentralt begrep. Det innebærer at faget må sees både i kulturelle og samfunnsmessig rammer og det må sees i lys av de personene som er forvaltere. Jeg skal komme tilbake til dette i en senere blogg.

Hva i all verden skal vi gjøre

Noen punkter jeg tror er viktige:

• Målgruppa med kursene må defineres klart og eksplisitt. Skal vi lage et kurs for hele verden, for Norge eller for østfoldinger som skal slippe å gå på forelesning.
• Kvaliteten må stå i første rekke. Det er utrolig enkelt å skaffe seg et dårlig rykte, og det er nesten umulig å rette det opp. Vi må ikke falle i den samme fallgropa som vi til dels har gjort i den vanlige undervisningen: Kvaliteten og kravene justeres for å tilpasses en studentgruppe som er lite målbevisste og dårlig trent i egen læring. En digital satsing kan være en metode for å redefinere kvalitetsnivået.
• Koplingen mellom faget og synspunktene og holdningene til den som forvalter det må være tydelige.
• Det må sikres en digital infrastruktur som støtter virksomheten i form av fora for diskusjon, spørsmål, kommentarer og selvtester. Denne infrastrukturen må bygges på allmenne verktøy, ikke gamle «læringssystemer» fra forrige generasjon.
• Vi må være veldig tydelige på hva dette koster og villige til å ta kostnadene. Dette er ikke gratis.

En rimelig oppgave

Ved innføring av et nytt tema i en læringsprosess er en av utfordringene å finne oppgaver og demonstrasjoner som er egnet til å øke innsikten og å fremme motivasjonen. Dette er selvsagt en helt generell problemstilling og i de fleste tradisjonelle skolefagene har pedagoger og lærebokforfattere lang erfaring i hva som virker og under vilke betingelser. Det er en løpene debatt om dette innen de fleste fag. En debatt basert på læringsteorier og personlig erfaring.

Når jeg tar opp denne i og for seg trivielle problemstillingen her er det fordi programmering som fag kanskje reiser noen litt spesielle problemstillinger. Vi har relativt lite erfaring med programmeringsundervisning i skoleverket, fra barneskole til videregående. Jeg innrømmer gjerne at jeg også på høgskolenivå har bommet gjentatte ganger, spesielt i innføringskurs.

I dette innlegget vil jeg ta opp noen utfordringer knyttet til det "å finne rimelige oppgaver" i programmeringsundervisningen. Jeg vil først forsøke og fomulere noen premisser som i hvert fall for meg er viktige. Deretter vil jeg se litt på oppgaver som ble brukt i prosjektet ProgPed der temaet er programmering som pedagogiske verktøy i matematikkundervisningen i skolen.

Noen generelle betraktninger

• Programmering er på den ene siden et fag som stiller store krav til kreativitet, samtidig som det stiller absolutte krav til presisjon. Vi har stor handlefrihet i hvordan vi formulerer oss i forhold til de som skal bruke det vi lager (tekst, bilder, sidelayout, dynamikk), og stor grad også i hvordan vi formulerer regneregler (algoritmer). Men når vi først har bestemt oss kreves det en absolutt presisjon i beskrivelsen (syntaks). Konflikten mellom evnen og lysten til å skape på den ene siden og evnen til å implementere på den andre siden er en utfordring for mange. Spesielt fordi elevene til daglig ser og bruker programmer som det er lagt ned store ressurser og erfaringer i å framstille, enten det er spill eller andre anvendelser.
• Vi må forholde oss til en blanding av noen grunnleggende stabile prinsipper, samtidig som anvendelsesmulighetene og løsningen endrer seg svært raskt. De vanlige programmeringsspråkene har endret seg forbløffende lite, men anvendelsene av dem og konsekvensene er totalt annerledes enn for noen tiår tilbake. Det er verken mulig eller riktig å overse det siste perspektivet, selv i grunnleggende programmering. Elevene kjenner deler av denne virkeligheten godt og har forventninger og kanskje noen betenkligheter. (Hvis de ikke har noen betenkligheter bør de kanskje oppfordres til å tenke litt på det.)
• Programmering forutsetter et omfattende begrepsapparat (variable, lister, objekter, funksjoner, datatyper, logiske tester, løkker). De som er trent i faget bruker ikke disse begrepene bare for å beskrive noe, men de brukes til "å tenke med". Erfaringsmessig er ikke alle disse begrepene trivielle i en innføringsfase. En av de store utfordringen i å lage rimelig oppgaver blir å finne enn motivert progresjon i forståelsen av begreper.
• Programmer skal gjøre noe. Vi må med andre ord velge en anvendelse. Denne anvendelsen bør oppfattes som meningsfull i en eller annen kontekst. Denne konteksten kan være hentet eksplisitt fra pensum i et annet skolefag eller fra en eller annen dagligdags situasjon. I eksempelet som følger er det matematikk som er konteksten. Veien fram til det som oppfattes som løsningn må tilpasses elevgruppa, og må spesielt i starten ikke være for lang.
• Oppgavene må ha en rimelig progresjon. Denne progresjonen må kombinere ambisjonsnivået på selve løsningen og ambisjonsnivået i begrepsforståelsen. Det ideelle er at vi greier å få disse til å forsterke hverandre. Nye begreper forenkler ofte koden vår, øker handlingsrommet og tillater større kreativitetet i problemløsningen. Vi må altså være veldig oppmerksomme på mestringsgraden.

I eksempelet nedenfor har ikke alle disse vurderingen blitt tillagt like mye vekt, men noen av dem ligger eksplisitt til grunn.

Et prosjekt

Det aktuelle prosjektet er knyttet til matematikkundervinsing i ungdomsskolen, 9.trinn. Tema var beregning av flater og volum. Rammene for prosjektet var 3 økter på tilsammen 8 timer. Elevgruppa var 24 elever som i hovedsak arbeidet to på en maskin. To matematikklærere var med, men instruksjoner og veiledning ble gitt av bachelorstudenter fra Høgskolen i Østfold. En detaljert beskrivelse av prosjektet er gitt i studentenes bacheloroppgave

Programmeringsomgivelsene som ble valgt var Processing. Oppgavene og programmeringsomgivelsene var demonstrert og drøftet med lærerne i forberedelsene av prosjektet. Processing ble valgt fordi det er enkelt å kontrollere grafisk output og fordi det er mulig å ha en progresjon i begrepsbruken som kan tilpasses oppgavene, i hvert fall innen rammene for det temaet som var aktuelt i dette tilfellet.

Introduksjon

Processing ble introdusert i en sesjon der elevene arbeidet paralellt med instruktøren som forklarte på storskjerm. Det viste seg å gå greitt å introdusere de helt nødvendige begrepene som variable (float), tegnekommandoer som rect(), color(), og flytting av origo ved hjelp av translate(). Målet var at elevene skulle kunne eksperimentere på en flate med origo oppe til venstre på et A4-ark, og de skulle kunne tenke i cm. Tilrettelegging av dimensjonene (punkter til cm) ble ferdiglagd i en mal som elevene arbeidet i.

Den første selvstendige oppgaven som ble løst:

Tegn det italienske flagget med en gitt dimensjon (cm) og riktig forhold mellom bredde og høyde (3:2).

Elevene hadde her tilgang til et løsningsforslag som de kunne se på hvis de ville:

void minTegning(){
  
  // sett opp A4-ark med origo oppe til venstre
  // og merk siden med et navn du vil bruke
  lagA4("jens");
  
  // hoyden
  float hoyde=4.0; //cm
  // bredde
  float bredde=hoyde*1.5; 
  
  // litt usikker på om jeg skal la alle kolonnen omgis av en svart strek ?
  // jeg skrur den av
  noStroke();
  
  // tegner den grønne kolonnen
  fill(0,255,0);
  rect(0,0,bredde/3,hoyde);
  
  // tegner den midterste hvite kolonnen
  fill(255,255,255);
  rect(bredde/3,0,bredde/3,hoyde);
  
  // tegner den høyre røde kolonnen
  fill(255,0,0);
  rect(2*bredde/3,0,bredde/3,hoyde);
  
  // må vel lage en omgivende svart strek
  stroke(0,0,0);
  noFill();
  rect(0,0,bredde,hoyde);
}

Denne introduksjonsdelen gikk relativt problemfritt og den øyeblikkelige visuelle responsen på enkel kode fungerte slik at det var enkelt å eksperimentere. Dette er en av styrkene til Processing, arbeidssyklusen Programmer - Vis er svært kort og enkel.

En typisk oppgave

Oppgaven var formulert slik:

Terninger har lik bredde, lengde og høyde.
Tegn en terning utbrettet slik at når vi klipper og bretter figuren til en 3-dimensjonal figur får vi en terning med sidekanter på 5 cm.

Vi har da lagt opp til følgende arbeidssyklus:

Dette istedet for det som trolig ville være de fleste programmereres først forslag:

Det er noen vurderinger bak problemformuleringen og den løsningsfilosofien det legges opp til.

For det første er det klart at vi kunne ha preparet visningssiden som et ruteark med svake markeringer av cm-ruter. Da ville mer av oppgaven kunne gjøres i den korte løkka Programmer -> Vis. På den annen side kunne vi ha unngått å forberede visningssiden med ferdigsatt pixel-pr-cm. I så fall måtte elevene ha forsøkt seg fram med skalering. Også dette ville øke fokus på løkka Programmer -> Vis. Ulempen er at det ville ta mye fokus vekk fra den pensumbegrunnede problemstillingen. Den løsningen som er valgt er ment på å holde fokus på den matematiske problemløsningen og forståelsen av flate og rom. Hvis noen elever kommer opp med forslag av den typen som er nevnt over er det jo bare å applaudere.

For det andre kan en spørre seg hvorfor i det hele tatt printe, klippe og brette ? Det ville være mulig å diskutere løsningen ut fra å inspisere visningen på skjerm. Det er to momenter her. Det ene er at det å fysisk handtere den utklipte figuren vil, forhåpentlig, bidra til at elever som har problemer med romforståelse kan lære noe av det. En kan også trekke inn et "Doing with Images makes symbols"- resonnement basert på Piagets ideer slik de er beskrevet i et annet innlegg på denne bloggen Piaget og programmering. Det andre momentet er at denne klipp-brett aktiviteten kopler programmeringen til noe utenfor datamaskinen og har både et sosialet og et pedagogisk aspekt. Når elevene er på vei til printeren og når de skal finne seg en saks så er det naturlig å vise fram både gode og "rare" løsninger, og diskutere alternativer. (Det er jo dessuten slik at vi har satt opp en veldig generell arbeidsrutine for å produsere mye annet rart, som f.eks. julepynt, dukketeaterkulisser, visittkort, plakater og jeg vet ikke hva.)

En slags fasitløsning kan se slik ut:

void minTegning(){ 
  // sett opp A4-ark med origo oppe til venstre
  // og merk siden med et navn du vil bruke
  lagA4("jens");
  
  // Jeg vil tegne en utbrettet terning der alle sider er 5 cm
  // det vil si tilsammen 6 kvadrater
  // dette kan gjøres på mange måter
  // jeg har gjort det ved å tegne et kors
  float side=5; // cm

  // tegner 4 kvadrater under hverandre
  translate(side,0);
  rect(0,0,side,side);
  
  translate(0,side);
  rect(0,0,side,side);
  
  translate(0,side);
  rect(0,0,side,side);
  
  translate(0,side);
  rect(0,0,side,side);
  
  // tegner 2 stk på sidene av den nest øverste
  // må flytte origo oppover igjen, og til venstre
  translate(-side,-2*side);
  rect(0,0,side,side);
  
  translate(2*side,0);
  rect(0,0,side,side);
}

Andre oppgaver

Noen andre oppgaver som ble lagt fram i samme settingen:

En lukket sylinder (tettet i begge ender) har et gitt volum på 200 kubikk cm.
Bestem diameter og lengde og tegn sylinderen utbrettet.

En pyramide har en kvadratisk grunnflate på 5x5 cm og høyde 6cm.
Tegn pyramiden utbrettet slik at dersom vi klipper og bretter figuren får vi en pyramide med riktige dimensjoner.

En eske har et gitt volum på 170 kubikk centimeter.
Høyden er 2 cm og lengden er 8 cm. Finn bredden og tegn esken utbrettet

Det er mange muligheter. Av begreper trenger vi å regne ut kvadratrota (sqrt()). Dersom trigonometri er en del av pensum vil dette kun kreve å utvide begrepsapparatet med de trigonometriske funksjonene i Processing(sin(),cos()).

Det ble også laget tilbud på oppgaver av en litt annen karakter. Et eksempel var å tegne en ferdig oppmerket fotballbane,og beregne hvor mange meter med linjer det faktisk finnes på en bane.

Oppsummering

Dette eksperimentet vil bli rapportert mer inngående med tanke på hva vi kan lære av det med tanke på matematikkforståelse, sammen med et paralellt eksperiment i barneskolen (7.trinn) med et annet verktøy, Scratch.

Det ser imidlertid ut til at resonnementene omkring kompleksitet i problemstillinger og verktøy er verdt å forfølge. Elevene behersket tilstrekkelige deler av verktøyet raskt og eksperimentet skapte stor interesse og innstasvilje. (Elevene ville ikke gå ut i friminuttene )

I slike eksperimenter må en selvsagt alltid ta hensyn til "Hawtorne-effekten", der oppmerksomhet og det å være med i et forsøk i seg selv skaper en positiv holdning. Selv om vi tar dette med i beregningen står vi igjen med det faktum at kompleksiteten var håndterbar, og at problemformuleringene gir betydelige muligheter for både å fokusere og generalisere.

Linker

Processing
ProgPed
Piaget og programmering
Børres Processing

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

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

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

Alan Kay på wikipedia

Alan Kay: Doing with Images make symbols part1

Alan Kay: Doing with Images make symbols part2

Alan Kay on TED

MIT App Inventor

Scratch

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:

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

Linker

Dijkstra på wikipedia

Dijkstra sitater på wikiquote

Kay på wikipedia

MIT App Inventor

Scratch