in eesti keeles

Ma läksin arvutiteaduse bakasse üsna suvaliselt. Põhi- ja keskkoolis käisin paljudel olümpiaadidel, kusjuures kõige halvemini läks füüsikas (tunnen siiani, et võiksin omada füüsika alustest paremat ettekujutust) ja informaatikas (sealt pärineb mu ainuke riigivooru viimane koht). Seetõttu otsustasin 2012. aastal astuda Tartu ülikooli informaatikasse ja võtta esimese ülikooliaasta jooksul paralleelselt ka kõiki füüsika 1. kursuse aineid.

Umbes märtsikuuks oli mulle selge, et IT1 on paremini õpetatud õppekava. Õpetamise kvaliteedi hinnang pole ainult minu oma: 2012. aastal (ja tõenäoliselt ka praegu) olid TÜ füüsika ained ühed madalama tagasisidega; arvutiteaduse instituudis oli tagasiside oluliselt parem. Arvestades, et informaatika tundus mulle ka põnevam2, jätsin füüsika maha ja keskendusin ainult arvutiteadusele.

Ma ei ole kindel, mis mind informaatikasse tõmbas. IT-s ei olnud vist üht säravat asja, vaid aegamisi sel alal paremaks saades hakkas mulle ka aina enam meeldima, mida programme kirjutades teha suutsin. Esimese ja teise kursuse vahelisel suvel viis toonane IT programmijuht (ja nüüdseks hea sõber) Margus mind kokku ühe Tartu leiutajaga, kel oli vaja ühe oma masina jaoks kaamerapildi põhjal ketta pöördenurka tuvastada. Kaamera vaatas ketta serval olevaid (asukohast sõltuvaid) triipkoode, mida mina tuvastama pidin.

Selle asemel, et kasutada mõnd tehisnägemise (computer vision) vahendit, mõtlesin kõik ise välja alates pildilt triipkoodide ülesotsimisest kuni numbrijadaks tõlgitud triipkoodist pöördenurga arvutamiseni. Tagantjärele on see muidugi väga rumal lähenemine — oleksin võinud sama tulemuse palju väiksema vaevaga saavutada, kui oleksin kasutanud olemasolevaid tööriistu –, aga sealt sain oma esimese kogemuse koodiga päris probleemi lahendamisest.

Programmeerimine annab võimu. Otse annab see võimu koodi jooksutava arvuti üle, aga sealt on vaid pisike samm “päris” maailmani. Näiteks on võimalik lühikese koodijupiga saata e-kiri, kuvada kasutajale veebilehel või äpis pilte, luua virtuaalseid maailmu nii lõbu pärast (mängud) kui ka maailma toimimise uurimiseks (simulatsioonid), tuvastada videost objekte ja teha väga palju muid asju. Veidi rohkem tööd nõuab robotite kontrollimine, aga see raskus tasub ära, kuna annab võimaluse maailma füüsiliselt mõjutada.

Parim osa on, et suurema osa tööst on tihti keegi teine ära teinud: väga paljude probleemide lahendamiseks on olemas tarkvarapaketid, kus paari käsuga saab teha sama, mis 20 aastat tagasi nõudnuks sadu käske. Arvutimängu looja ei pea mõtlema, kuidas valgus seintelt ja inimestelt peegeldub ning lõpuks inimsilma jõuab, ega kuidas muuta kolmemõõtmeline stseen kahemõõtmeliseks kujutiseks ekraanil. Ta saab toetuda teiste inimeste loodud koodile, mis kõiki neid probleeme lahendab, ning keskenduda ise haarava stsenaariumi ja parima mängukogemuse loomisele.

Selle idee nimi on abstraktsioon: käsklustest moodustub püramiid. Näiteks võib mõelda, et “prae muna” on abstraktsioon, mis sisaldab endas (lihtsustatult) kolme osa: 1. aja pann kuumaks, 2. löö muna pannile, 3. kontrolli iga 30 sekundi tagant, kas muna on valmis, ja kui on, siis võta pann tulelt. “Aja pann kuumaks” on omakorda abstraktsioon, mis sisaldab endas samme panni väljaotsimisest ja pliidile asetamisest kuni pliidinupu keeramiseni ja õige temperatuurini ootamiseni. Kui alustasin programmeerimist (ja tuvastasin esimesel suvel triipkoode), ei kasutanud ma vabalt saadavaid programmijuppe, mis abstraheerivad kõik rasked osad ära, ja alustasin ise oma metallimaagi kaevandamisest ja panni valmistamisest, kuigi eesmärgiks oli muna praadida. Programmeerimise võim seisneb selles, et metafoorilise panni hind on 0 eurot: kui kvaliteetne kood on valmis kirjutatud, siis võime seda tasuta lõpmatult kopeerida ja taaskasutada.3

Tundub, et liigume aina abstraktsemate programmerimiskeelte poole. Näiteks Python on (teadlikult disainitud) selline, et koodi on võimalik lugeda peaaegu nagu inglisekeelset teksti. Siin on näide triviaalsest programmijupist, mis võtab sisendiks arvu x ja sõltuvalt selle väärtusest ütleb (“prindib”), kas arv on positiivne või mitte:

*

Mis tunne on programmeerida?

Lühike tagasisidetsükkel teeb programmeerimise peaaegu sõltuvusttekitavaks. Kui koolis kodutööd esitades saab tulemuse teada siis, kui õppejõud on töö üle vaadanud, siis koodi saab igaüks jooksutada oma arvutis. Nii saab sekundite jooksul pärast ülesande lahenduse kirjapanemist teada, kas see on õige; muudatuste tegemise järel programmi uuesti testimine võtab jälle vaid ühe nupuvajutuse ja paar sekundit. Eriti tugevalt mõjub see visuaalsete ülesannete lahendamisel: näiteks veebilehte programmeerides on mul peas ettekujutus, mida tahan, ning kui kood ei anna soovitud tulemust, näen seda otsekohe. Tagasiside on igas ülesandes oluline saamaks aru, kui hästi parasjagu läheb, ja arvuti pakub seda rikkalikult.

Programmeerimine distsiplineerib. Kuna arvuti ei tee mitte seda, mida sa tahad, vaid seda, mida käsid tal teha, oled sunnitud lahenduse sammud selgelt ja ühetimõistetavalt kirja panema. Üks raskemaid asju programmeerimise juures ongi leida viis ülesanne väiksemateks sammudeks jaotada; iga sammu on siis kas võimalik mõne standardmeetodiga lahendada või tuleb see omakorda tükkideks jagada. Oskus ja mõtteharjumus lõhkuda suur ülesanne pisemateks üldistub hästi ka muudele aladele ürituste korraldamisest maja ehitamiseni.

Programmeerimine on frustreeriv. Kui oled enda arvates kõik õigesti teinud ja tulemus on vale, võib mõnikord minna mitu tundi mõistmaks, mis valesti läks — tihti jäi kuskil sisse näpuviga või tegid vale eelduse. Samas kui saan pärast pikka silumist4 oma veast aru, on mõistmishetkel mu sees intensiivne tunnete segu: pahameel, et nii rumala vea tegin; võidukus, et arvutist jagu sain; rõõm uue asja õppimisest; pingelangus, sest programm jälle töötab.

Programmeerimine nõuab pidevat õppimist. Uusi programmeerimiskeeli tuleb kogu aeg välja; mõned neist saavad kiiresti edukaks. Isegi ühe keele sees muutuvad parimad disainimustrid paari aastaga. Näiteks muutuvad Javascriptiga veebiarenduse tööriistad nii tihti, et selle üle tehakse juba nalja. Ühest küljest on see raske, sest pidevalt tuleb juurde õppida, aga teisest küljest põnev, sest igapäevased tööriistad muutuvad iga 3-10 aasta tagant peaaegu tundmatuseni. Sama kehtib ettevõtete ja valdkondade vahel: töökoha vahetamine tähendab hulga uute tehnoloogiate äraõppimist. Pidev õppimine võib tunduda raske, aga minu jaoks on pigem pooltargument.

*

Programmeerimine on raske, aga mitte nii, nagu enamik mitteprogrammeerijaid arvavad. Arvuti kontrollimine ei nõua doktorikraadi võlukunstis ega supermatemaatilist mõtlemist; raskus seisneb mitte allaandmises, kui oled sama probleemiga juba 4 tundi maadelnud. Samas on tasu vääriline: parimatel hetkedel annab see võimaluse olla tsoonis keeruliste probleemide elegantselt lahendamisest ja samal ajal luua asju, mis võivad elu paremaks teha potentsiaalselt miljonitel inimestel.

 

Aitäh Heikile sisuliste kommentaaride eest.

Seotud:

Jaga:

FacebooktwitterlinkedintumblrmailFacebooktwitterlinkedintumblrmail

Märkused

  1. IT on tegelikult infotehnoloogia, mis pole päris sama asi kui arvutiteadus/informaatika (mis on omavahel sünonüümid), aga enamik inimesi ei tee vahet.
  2. Võimalik, et õppekvaliteet mängis siin rolli.
  3. Tasuta juhul, kui tegu on vabavaraga, aga väga paljud programmeerijad jagavad enda kvaliteetset loomingut täiesti tasuta; tihti teevad terved programeerijate tiimid tasuta tööd, et kvaliteetne tarkvara <probleemi X> lahendamiseks oleks kõigile vabalt kättesaadav.
  4. “siluma” (ingl k debug) on eestikeelne termin vigade ülesotsimise ja eemaldamise kohta

Lisa kommentaar

Comment

  1. Noo jah, nii palju kui on tarkvara-arendajaid, nii palju on ka erinevaid vaatenurki ja nägemusi.

    Esimene Taivo Pungas’e mõte, millele ma kohe kaika kodaratesse loobin, on see väide, et “kõik on teiste poolt tehtud ja olemas”. Oi, kuidas ma KOGU SÜDAMEST VIHKAN SEDA VÄIDET JA SUHTUMIST!!! Eriti kui seda räägib mõni inimene, kes on kuidagi, mingit pidi, kliendi rollis või mõne sellise kolleegi rollis, kes pole ise täpselt sama ülesannet täpselt samade nõuete komplekti korral lahendanud. Oma vastuväitele suudan pakkuda vaid empiirilist argumentatsiooni: kes on piisavalt hoolas ja töökas ja hoolib piisaval määral sellest, et ta tarkvara toimib kiirelt, korrektselt, skaleeruvalt, muus osas (näiteks turvateemad) töökindlalt, see mõistab ise aastate jooksul, praktilise töö käigus, miks ma väidet, et “kõik on olemas ja toimib ja teiste poolt juba tehtud” kogu südamest vihkan. Vihjeks saan öelda, et üks asi on kliendi poolt üle antavad kasutusjuhtude nõuded ja teine asi on arendaja enda poolt sinna lisatavad lisanõuded, mis tuleb samuti ära täita selleks, et klient tarnitavat üldse kasutada saaks.

    Näited “süütutest” lisanõuetest, mida ükski klient ega tarkvara-analüütik ei kirjuta: andmed ei korrupeeru kui serveril “õigel ajal” vool ära läheb, serveri taaskäivitumisel veebirakendus toimib ilma, et oleks tarvis selle loojaid avarii-parandus-töödele kutsuda.

    Aga, üldiselt, mu enda nägemus, et milliseid sõltuvusi mina oma enda projektidele valin, ja miks, on kirjeldatud minu ajaveebis:

    (“My Technology Stack in 2016_07 and How I Prefer to Choose it”)
    https://martin.softf1.com/g/yellow_soap_opera_blog/my-technology-stack-in-2016_07-and-how-i-prefer-to-choose-it

    Veelkord, rõhutan, et minu nägemus on VAID MINU NÄGEMUS, mis ERINEB enamuse TEISTE INIMESTE NÄGEMUSEST väga suurel määral.

    Tänan lugemast.