Programmeringsteori i Scratch

Mange kjenner til Scratch – et barnevennlig programmeringsmiljø, der læringen ofte går ut på å lage kreative prosjekter fra «enkelt til komplisert». Den «klassiske tilnærmingen» til å lære programmering (variabler → forgreninger → sløyfer → funksjoner → strukturer → objekter → …) er imidlertid utfordrende i Scratch.

Å endre rekkefølgen på begrepene (la oss kalle dem konsepter) innen strukturell, objektorientert og hendelsesorientert programmering, og å skjule dem bak fargerike sprites og interaktiv animasjon, betyr ikke at man ikke bør legge vekt på konseptene. Spesielt hvis målet er ikke bare å utvikle kreative evner, men også å lære programmering. Denne ideen har jeg forsøkt å gjenspeile i min kurs.

Det første som en nybegynner i Scratch møter, er sprites. Selv om det ikke finnes objektorientert programmering i Scratch, kan sprites betraktes som objekter. På dette stadiet ser eleven at programmet kan ha mange objekter som blir styrt av skripter som er eksterne for dem. Sprites får kommandoer eller sender informasjon om sin tilstand etter behov, noe som betyr at programmering går ut på å kontrollere objektene.

Det andre som faller over hodet på en ung programmerer i Scratch, er konseptet med multitråding. Hver sprite kan ha flere skripter som kjøres samtidig. Flere sprites kan også kjøre programmene sine samtidig med hverandre. Det viser seg imidlertid å være mer komplisert å organisere sekvensiell utførelse.

Allerede i den første leksjonen kan vi ikke unngå å bli kjent med sløyfer. Ellers vil katten ikke få fart. På dette stadiet må introduksjonen forbli intuitiv og overfladisk. Vi begrenser den til sløyfer som «gjenta alltid» og «gjenta … ganger», som er lettere å forstå. Sløyfen med betingelse studeres i en leksjon som er spesielt viet til sløyfer. Denne leksjonen forutsetter kjennskap til logiske uttrykk og variabler.

Siden Scratch er et hendelsesorientert miljø, er det lettere å studere blokkene for betingede setninger før variablene. Betingelsen kan være ulike hendelser.

Etter min mening er denne rekkefølgen bedre, fordi vi introduserer et minimum av begreper for hver leksjon. Dessuten ser vi umiddelbart den praktiske nytten av dem.

Hvis man først lærer om variabler, er det vanskelig å demonstrere deres hensikt og nytte, fordi man ikke har lært om betingede utsagn, inndata og generering av tilfeldige tall.

I Scratch, med unntak av lister, støter programmereren på tre datatyper: tall, strenger og boolske typer. Typen er knyttet til verdien, ikke variabelen. Det er ikke nødvendig å konvertere strenger til tall og omvendt. Strenger settes ikke i anførselstegn.

Blokken som returnerer en boolsk verdi og har en karakteristisk vinklet form, kan settes inn i runde felt. Det motsatte er ikke sant: der hvor det forventes et logisk uttrykk, kan man ikke sette inn en vanlig variabel.

Scratch er designet slik at det ikke oppstår kritiske feil under kjøring. Det er trolig derfor, hvis man prøver å bruke en streng i en aritmetisk operasjon, blir den erstattet med null (se første skjermbilde).

Programmereren må vite at mulighetene til programmeringsspråk utvides av biblioteker. Når man arbeider i Scratch, kan eleven koble til tillegg som fører til nye kommandoer i miljøet.

Funksjoner i Scratch er implementert i delen «Andre blokker», hvor man på den ene siden lager sin egen blokk som kan settes inn i andre skript. På den annen side må man samle funksjonaliteten til denne blokken, det vil si hva den skal gjøre.

Det er ingen returverdier fra Scratch-funksjoner.

Dermed setter læringen av programmeringskonsepter i en hendelsesdrevet omgivelse sitt preg. I bunn og grunn lærer vi først mer komplekse og abstrakte begreper, og når vi dykker dypere inn i prosessen, går vi videre til elementene av strukturell programmering. Om dette er en fordel eller ulempe for førstegangsbrukere er et omdiskutert spørsmål.

Kilde: habr.com