Mikä on WikiWiki?
nettipäiväkirja
koko wiki (etsi)
viime muutokset
Aikoinani, 7-vuotiaana vuonna 1986, opettelin ohjelmointia ala-asteellani Logo-ympäristössä. Tämä ohjelmointiympäristö on edelleen mielestäni yksi parhaita opetusympäristöjä niin ohjelmoinnin kuin ajattelunkin kannalta. Sen ainoa varsinainen "puute" oli se, että komennot koostuivat kirjaimista ja numeroista; tämä teki ohjelmoinnin oppimisen vaikeaksi niille, jotka eivät vielä olleet tajunneet kirjaimia ja numeroita.
Nykyiset koneet ovat kuitenkin valitettavasti niin täynnä visuaalista karkkia, etten tiedä, jaksavatko lapset enää kirjoitella "fd 10 rt 90 fd 10 lt 90" tehdäkseen portaita; ja jos ei jaksa tehdä ensimmäistäkään viivaa, ei myöskään saa sitä uskomatonta hallinnan tunnetta, joka tulee ensimmäisen kerran, kun panee koneen piirtämään 60 porrasta yhden sijaan. Ohjelmointia uhkaa se, että tietokoneella on nykyään niin paljon muutakin hauskaa tekemistä. Sitä paitsi tämä muukin tekeminen on oikeasti kehittävää ja hauskaa.
Niin tai näin, nykyiset lapsille suunnatut ohjelmointiympäristöt näyttävät lähes sääntönä käyttävän "blokkiparadigmaa": niiden kielet muodostuvat "palasista", joita yhdistellään toisiinsa komentosarjojen tuottamiseksi. Tämä auttaa ohjelmoinnissa kahdella tavalla. Ensinnäkin erilaiset komennot ovat lueteltuina blokkipaletissa, jolloin ei ole opettajan hyväntahtoisuudesta kiinni, opitko koskaan tyhjentämään ruutua (logon komento tähän oli "cs"). Toisekseen, kirjaimista koostuvien komentojen korvaaminen blokeilla vähentää luku- ja kirjoitustaidon tarvetta. Numerot, tosin, ovat yleensä täysin symbolisia edelleen.
Blokkiparadigma on myös äärimmäisen epätyydyttävä monestakin syystä. Ohjelmat vievät paljon tilaa, ja ne täyttävät ruudut nopeasti. Blokkipaletit ovat sekavia. Ylipäänsä ohjelmoiminen blokkeja ympäriinsä vetelemällä on turhauttavaa. Lisäksi asioiden kokeileminen on hankaloitunut: logossa saattoi sanoa "print [heips]" ja sana "heips" ilmestyi ruutuun; blokkiparadigmassa tästä pitää ensin tehdä skripti ja sitten skripti pitää osata ajaa. Niinpä en ole ihan varma, onko blokkiparadigma loppujen lopuksi edes parempi kuin suora komentojen kirjoitus näppäimistöltä.
Olen hahmotellut vaihtoehdoksi "esimerkkiohjelmointia". Tässä ohjelmia ei syötetä erikseen, vaan käyttöliittymässä tehdään jotain ja sitten nimetään se ohjelmaksi. Käyttöliittymä nauhoittaa kaiken, mitä teet, ja näitä "transkriptejä" voi suorittaa uudestaan ja muokata.
Esimerkki:
Maalaat (=aktivoit) tekstistä tietyn kohdan. Transkriptiin ilmestyy "valikoi tekstin X 3. linjan 2. sana" (tai jokin ikoninen esitystapa tälle). Vaihdat sanan toiseksi, esimerkiksi sanaksi "jee". Transkriptiin ilmestyy "vaihda tekstivalinta merkkijonoksi jee". Tässä vaiheessa otat jälkemmäisen toiminnon transkriptistä irti omaksi transkriptikseen ja annat sille nimen "muuta-jeeksi". Alas ilmaantuu uusi transkripti.
Sitten siirryt nuolinäppäimillä kolme sanaa eteenpäin ja maalaat seuraavan sanan. Transkriptiin tulee "siirry 3 sanaa eteenpäin" ja "valikoi sana kohdistimen ympäriltä". Klikkaat "muuta-jeeksi"-transkriptin suorituspainiketta, jolloin uuteen transkriptiisi ilmestyy "suorita muuta-jeeksi-transkripti" ja valikoimasi sana muuttuu jeeksi. Nyt nimeät uuden transkriptisi "muutos", jolloin alkaa taas uusi transkripti.
Klikkailet "muutos"-transkriptin suorita-painiketta monta kertaa peräkkäin, jolloin tekstistä muuttuu aina joka kolmas sana "jee":ksi. Nämä kaikki myös tallettavat uuteen transkriptiin "suorita muutos-transkrikpti" -merkintöjä. Jossain vaiheessa voit irrottaa taas tämän transkriptin ja suorittaa sitä tehdäksesi esim. 7 muutosta kerralla.
Tämä on siis perustapa, jolla ohjelmia tehdään: transkriptit syntyvät tekemisen ohessa, ja niitä voi käyttää osana toisiaan. Tämä riittää proseduraaliseen perusohjelmointiin, mutta on hyvin rajoittunut paradigma. Ohjelmiin pitää voida saada myös muuttujia.
Muuttujia käytetään siten, että jostain talteen otetusta transkriptistä voi muuttaa konkreettisen objektin (kuten "teksti X" tai "3 sanaa") esimerkiksi objektista. Tällöin "3 sanaa" vain edustaa jotain sanamäärää; todellinen sanamäärä voi vaihdella ja määritetään aina transkriptia ajettaessa. Esimerkiksi, jos meillä on tällainen transkripti:
mene eteenpäin 3 sanaa.
lisää merkki ")".
mene taaksepäin 3 sanaa.
lisää merkki "(".
Niin siitä voi tehdä yleisen "pane sulkeisiin" -ohjeen muuttamalla 3 sanaa esimerkiksi, joka korvataan jollain todellisella etäisyydellä transkriptia suoritettaessa esimerkiksi osoittamalla etäisyys maalaamalla. Samaan tapaan esim. kuvalle tehdyn monimutkaisen operaation voi yleistää siten, että sen voi tehdä useammalle kuvalle.
Suurimpia ongelmia tässä ohjelmointiparadigmassa ovat nähdäkseni rekursiivisten rakenteiden tutkimisen vaikeus, sekä se, etten ole keksinyt mitään intuitiivista esitystapaa ehtorakenteille. Ehtorakenteet nimittäin eivät yleensä todennu käyttöliittymän käytössä, vaan syyt, miksi käyttäjä tekee jotain tai ei tee, ovat käyttäjän päässä, mistä niitä on mahdotonta kaivaa transkripteihin.
Rekursiivisiin rakenteisiin voi tutustua rekursiivisilla kuvilla, mutta siitä kerron ehkä joskus myöhemmin :)