keskiviikko 18. maaliskuuta 2009

Yhteenveto

Kävin blogin postaukset läpi aina 15. luentoon asti ja kommentoin niitä aina tarpeen mukaan. Tuota uudempiin oli hankalampaa keksiä kommentoitavaa. Joissain tapauksissa opittu asia oli tuonut hieman toisenlaista näkökulmaa kirjoituksiin, joten tässä mielessä kommentoinnista oli mielestäni hyötyä.

Kurssin tavoitteiksi on määritelty seuraavat:
  1. Nostaa opiskelijoiden ohjelmointikielikäsityksen abstraktiotasoa.
  2. Valmentaa opiskelijat arvioimaan ohjelmointikieliä eri kriteereillä
  3. Antaa opiskelijoille riittävät teoreettiset työkalut ohjelmointikielten tutkimuksen seuraamiseen.
Mielestäni olen ainakin jossain määrin pystynyt saavuttamaan näitä tavoitteita. Kurssi nitoi mukavasti yhteen muutaman viime vuoden aikana oppimaani. Toisaalta se tarjosi myös uutta suuntaa opittavien asioiden suhteen. Lisäksi sain virikkeitä omiin projekteihini.

On selvää, että jossain vaiheessa (ehkä viikonloppuprojektina?) voisi vilkaista ainakin Haskelia ja LISPiä. Funktio- ja logiikkaohjelmointitaidot saattaisivat olla hyödyllisiä jo ainakin sen vuoksi, että oppii näkemään nykyistä osaamistaan hieman eri valossa. Logiikkaohjelmointia olisi hyvä opetella jo sen vuoksi, että pääsisi kiinni paremmin tekoälyasioihin.

Kurssin suurin anti oli kenties se, että nyt käyttämiään ohjelmointikieliä osaa tarkastella hieman toisin. Tarvittaessa osaan toteuttaa kieliin tarvitsemiani konstruktioita (esim. piirteet!). Jossain määrin kielen suunnittelu kytkeytyy laajemmin ohjelmistosuunnitteluun. Jos kieli laajennettuna on tarpeeksi ilmaisuvoimainen, auttaa se myös ohjelmistojen toteuttamisessa. Uskoakseni ilmaisuvoimaisuudesta seuraa tiettyä selkeyttä, joka edesauttaa koodin tarkoituksen kommunikointia. Tähän juuri DSL:t (Domain Specific Language) juuri pyrkivätkin.

Oppimispäiväkirja osoittautui oppimismuotona varsin päteväksi. Mielestäni ei haittaisi vaikka useammatkin kurssit hyödyntäisivät sitä. Ennemmin kirjoitan ja pohdin kuin pänttään tenttiin. Etuna on myös se, että samalla tulee dokumentoitua ja pohdittua oppimaansa. Lisäksi joskus myöhemmin voi sitten naureskella kirjoittelulleen, kun tietää asiat paremmin.

tiistai 17. maaliskuuta 2009

Demo 9 - kommentit

Yhdeksännen ja viimeisen demokerran tehtävät löytyvät osoitteesta http://users.jyu.fi/~antkaij/opetus/okp/2009/demot/9.html. Tällä kertaa demoihin osallistui lisäkseni yksi opiskelija, ohjaaja sekä luennoitsija. Tehtäviä teimme kumulatiivisesti laskien kolme kappaletta, joista itse tein yhden. Demokerta kesti 15 minuuttia, mikä oli ainakin osaltani jonkin sortin ennätys.

Tehtävät eivät olleet vaikeita, joten vähäinen osallistujien määrä oli jossain määrin yllätyksellistä. Ensimmäisessä tehtävässä (tein tämän) käsiteltiin Links-kieltä, joka on suunniteltu erityisesti www-käyttöä varten. Ajatuksen tasolla Links on loistava.

Käytännössä www-kehitys on edelleen useimmiten sitä, että kehittäjä joutuu kirjoittamaan koodia tavallisesti ainakin kolmella eri kielellä (PHP/Python/Ruby/..., JavaScript sekä (X)HTML tms. + CSS (tyyli)). Links pureutuu nimenomaan tähän ongelmaan ja pyrkii luomaan ratkaisun, joka nitoo nämä erilliset osat yhteen. Mielestäni Links onnistuukin tässä jossain määrin. Kuitenkin HTML-pohjainen koodi näkyy pahasti läpi.

Uskonkin, että tämä osa tulisi abstrahoida niin pitkälle kuin mahdollista. Kehittäjän ei tulisi välittää HTML-koodista vaan pikemminkin abstraktista rakenteesta, joka asemoidaan kohdalleen (käyttöliittymän suunnittelijan tehtävä). Tässä tapauksessa sovelluskehittäjän pääasiallinen tehtävä olisi logiikan suunnittelu. Mielestäni esim. Weblocks ja Seaside onnistuvat tässä suhteessa paremmin.

Oma www-kokemukseni rajoittuu lähinnä PHP:lla pelailuun sekä Djangoon, jota käytin ollessani mukana sovellusprojekti-kurssilla. Django osoittautui yllättävän hyväksi. Tosin erityisesti AJAX-toiminnallisuuden toteuttaminen jätti tuolloin vielä toivomisen varaa. AJAX ikäänkuin liimattiin kokonaisuuden päälle, mikä ei ollut varsin mukavaa. Myös HTML näkyi hieman turhan paljon läpi. Onneksi Djangon template-pohjainen ratkaisu auttoi tässä paljon. template-perinnän avulla suurin osa pakollisesta rojusta (headerit, navigaatio ym.) jäi hierarkian vanhimpiin luokkiin.

maanantai 16. maaliskuuta 2009

Luento 18 - Oliokielten erityiskysymyksiä II

Tällä kertaa pidettiin kurssin viimeinen luento. Luennolla palattiin oliokielten pariin. Erityisesti moniperintä sai huomiota. Lisäksi luennon lopuksi kurssilla käsitellyt asiat koottiin yhteen.

Moniperintä on varsin hyödyllinen ominaisuus. Mielestäni moniperinnän suurin hyöty saadaan käytettäessä mixinejä. Luennolla esiteltiinkin C++ toteutus mixinien ja malline (template) -luokkien käytöstä.

Moniperinnän ongelmallisuus tulee ilmi, kun perintähierarkia sisältää timantin eli ts. jos A on ylin luokka, B ja C perii A:n, D perii B:n ja C:n. Tässä tapauksessa ei ole selvää kuinka D tulisi koostaa, koska se perii A:n kahta kautta. Mielestäni tässä tapauksessa on hyödyllistä sisällyttää ohjelmointikieleen päättelylogiikka, jonka perusteella asia ratkaistaan. Voidaan esimerkiksi päättää, että viimeksi perityt ominaisuudet ovat vahvimpia, jolloin ne jäävät voimaan.

Luennolla esitellyssä esimerkissä moniperinnän avulla syöte/tulostevirran käsittelijää laajennettiin synkronointia varten lisätyllä lukolla. Tässä tapauksessa moniperintää olisi voinut kiertää komposition avulla siten, että lukko olisi sisällytetty synkronoituun luokkaan. Toisaalta tämä ratkaisu menee nopeasti sotkuiseksi, koska luokkien synkronoidut toteutukset joutuvat hyödyntämään esim. template method -mallia seuraavasti:


...
def read(self):
return self.lock.synchronize(super(SynchronizedReadStream, self).read)
...


Toteutusta saa siistimmäksi dekoraattorin avulla:


...
@synchronized
def read(self):
return super(SynchronizedReadStream, self).read()
...


Dekoraattorin toteutus huolehtii lukon asettamisesta ja vapauttamisesta. Toisaalta dekoroinnin voisi tehdä myös metodin kutsuvaiheessa.

Ducasse ym. ovat kehittäneet ongelmaan hieman erilaisen ratkaisun, piirteet (traits). Pohjimmiltaan kyse on koostamisesta. Piirteet kuitenkin onnistuvat kiertämään moniperinnän ongelmia siten, että luokan käyttämien piirteiden sisältämän koodin voidaan ajatella kopioituvan luokkaan itseensä dynaamisesti.

Luennolla mainittiin myös binäärimetodeihin liittyvästä ongelmallisuudesta. Binäärimetodissa ajatuksena on, että metodille annettujen parametrien (binääri -> 2 kpl parametreja!) luokat vaikuttavat tulokseen. Luokat siis vaikuttavat suoraan tulkintatapaan. Ongelmaa voi kiertää joko multimetodien tai This-avainsanan (tyyppitason vastine this-avainsanalle) avulla.

Multimetodien käyttö muistuttaa esim. konstruktorien ylikirjoitusta(?) (overloading), jossa käytetty konstruktori määräytyy kutsun perusteella. Tässä tapauksessa kutsun luokat pitää kuitenkin ottaa dynaamisesti huomioon toisin kuin edellä!

Multimetodien toteutusta voidaan ajatella sääntöpohjaisesti (tyypit sidotaan säännön avulla haluttuun metodiin) tai dekoraattorien avulla. Näistä dekoraattoritoteutus tuntuu varsin näppärältä.

This-avainsana vaikuttaa ideana varsin elegantilta. Käytännössä sen käyttö mahdollistaa sen, että tyyppi propagoituu luokan aliluokkiin automaattisesti eikä erillisiä tyyppitarkistuksia tarvita kuten ennen. Luennolla mainittiin, että tämä tapa toimisi vain staattisesti tyypitetyissä järjestelmissä. Aivan tarkkaa syytä siihen, miksi näin on, en saanut selville.

Intuitiivisesti tuntuu, että This-avainsanaa voisi matkia dekoraattorin avulla. This-avainsanan voisi mallintaa näennäisluokan (dummy) avulla. Tämän voisi sitten välittää dekoraattorille (@method_types(This) (voisi olla geneerinen jolloin voisi mallintaa myös oikeita tyyppejä (Int, Str jne.))), joka osaisi tehdä tulkinnan (This viittaa dekoroidun metodin luokkaan!).

En ole varma olisiko This-avainsanasta dynaamisesti tyypitetyssä kielessä mitään käytännön hyötyä. Ainakin tyypit voisivat olla vapaaehtoisina päteviä. Olen joskus toteuttanutkin omia tyyppejä (esim. Color ja ConstrainedValue). Omien tyyppien toteuttaminen on arkkitehtuurin selkeyden kannalta varsin hyvä asia. Esim. ConstrainedValuen tapauksessa pystyin kapseloimaan rajoituspiirteen tyyppiin itseensä. Tämä tarkoittaa sitä, että muun koodin ei tarvitse välittää rajoituksien tarkastamisesta, koska tyyppi itse osaa huolehtia siitä.

Luennon lopun yhteenvedossa lähinnä kerrattiin kurssin tavoitteet ja oleellisimmat läpi käydyt asiat. Käyn kaikki postaukseni vielä erikseen läpi ja kirjoitan kommentoin niitä. En aio ruveta sensuroimaan itseäni vaan pidän kommentit erillisinä. Samalla tulee nähtyä kuinka asioita on tullut opittua. Lisäksi kirjoitan erillisen postauksen, jossa tarkastelen oppimaani suhteessa tavoitteisiin ja käyn läpi oleellisimpia kommentoidessani tekemiäni huomioita.

keskiviikko 11. maaliskuuta 2009

Demo 8 - kommentit

Kahdeksannen demokerran tehtävät löytyvät täältä. Tehtävät olivat aikaisempaa helpompia, mutta silti sopivan työläitä. Erityisesti viimeiset bonustehtävät (2-6) veivät aikaa. Tällä kertaa panostin demoihin tavallista enemmän tehden perustehtävien lisäksi juurikin mainitut tehtävät.

Perustehtävistä antoisin oli kenties tehtävä 4, jossa pyydettiin katsomaan video ja vastaamaan annettuihin kysymyksiin. Videossa oli pohjimmiltaan kyse kielen kasvattamisesta. Oleellista onkin kuinka kielen tulisi voida kasvaa. Aina ei ole selvää, että kieltä voidaan laajentaa. Kuitenkin käyttäjän kannalta laajennusmahdollisuudet ovat suotavia.

Lisäksi kielen tulee olla kasvatettavuuden lisäksi tarpeeksi ilmaisuvoimainen. Mielestäni on myös oleellista, että oikeaa kieltä käytetään oikeassa paikassa. On jossain määrin mahdotonta suunnitella kieltä, joka olisi parhaimmillaan kaikissa eri tarkoituksissa sellaisenaan. Kielen kasvattaminen auttaa tässä jossain määrin. Kuitenkin on kenties kannattavampaa käyttää käyttötarkoitusta varten jo lähtökohtaisesti suunniteltua kieltä.

Yllä mainittujen seikkojen lisäksi mielestäni on oleellista pitää mielessä, että aina ei ole mielekästä rajoittua vain yhden kielen käyttämiseen. Esimerkiksi Pythonia voidaan pitää ns. liimakielenä. Tämä tarkoittaa sitä, että sen avulla voidaan paketoida suorituskyvyltään nopeita C-moduuleja kokonaisuudeksi. Tässä tapauksessa C:n avulla huolehditaan suorituskykyvaatimuksesta ja Pythonin avulla toteutetaan muu toiminnallisuus. Onhan sitä useimmiten nopeampaa ja mukavampaa kehittää.

Bonustehtävänä sain suunnitella aivan oman, pienen oliokielen. Pyrin pienuuteen yhdistämällä aliohjelmien, metodien, luokkien ym. käsitteen yhteen. Tästä seurauksena loin entiteetin-käsitteen. Lisäksi kieli sisältää staattiset tyypit, jotka tosin varmaan jossain määrin heitän menemään, mikäli jonain päivänä innostun kehittämään kieltä edelleen. Tarkempi kuvaus, esimerkkejä sekä alkeellinen toteutus löytyvät täältä. Testit on toteutettu py.test -työkalua käyttäen. Hyvä kuvaus työkalusta löytyy osoitteesta http://codespeak.net/svn/py/extradoc/talk/pycon-uk-2008/pytest.pdf.

Tiedän ettei kieli ole missään mielessä täydellinen. Erityisesti this-semantiikka kaipaisi virkistystä. Mikäli lähtisin kehittämään kieltä edelleen suuntaisin sen Pythonin laajennuskieleksi. Tässä tapauksessa kielestä voisi käyttää suoraan Pythonin moduuleita, mikä olisi varsin mukavaa.

Luento 17 - Viestinvälityssamanaikaisuus

Viestinvälityssamanaikaisuudessa on kysymys samanaikaisuuden toisesta osajoukosta. Edellisessä postauksessa käsittelin tämän asian rinnakkaista käsitettä, yhteismuistisamanaikaisuutta.

Tätä blogia voidaan pitää viestinvälityksen mediumina. Minä kirjoittajana olen viestin lähettäjä. Lukijoita voidaan pitää vastaanottajina. Toisaalta kommentin jättävä lukija on puolestaan lähettäjä ja minä sekä muut lukijat vastaanottajia. Viestinvälityksessä on siis kolme oleellista komponenttia: lähettäjä, medium (median yksikkö) sekä vastaanottaja.

Viestinvälitystä voidaan varioida monin eri tavoin. Tämä näkyy muun muassa käytetyistä standardeista (TCP/IP, UDP/IP ym.), jotka kukin tarjoavat oman tapansa toimittaa viestejä perille. Riippuen käytetystä menetelmästä voidaan esimerkiksi taata, että viestit saapuvat perille lähetysjärjestyksessä. Menetelmä voi ottaa kantaa myös viestinvälityksen luotettavuuteen.

Mielenkiintoinen variantti on tapaus, jossa lähettäjä ei voi lähettää viestiä ennen kuin vastaanottaja on valmiina vastaanottamaan sen. Tällöin puhutaan kohtaamisesta tai tunnetummin ns. rendezvous-menetelmästä.

Olin kuullut kohtaamisesta aiemmin Adan yhteydessä. Luento kuitenkin selkeytti käsitettä hieman. Kenties hieman yllätyksellisesti kohtaamista voidaan pitää muiden menetelmien prototyyppinä, jonka avulla haluttua menetelmää voidaan matkia. Tuntuukin luontevalta, että klassinen tuottaja-kuluttaja -ongelma ratkeaisi sitä käyttäen mallikkaasti.

Kohtaamiseen pohjautuen on mallinnettu erityisiä viestikieliä. Näistä luennolla esiteltiin Hoaren CSP (Communicating Sequential Processes) sekä piilaskento. CSP:tä voidaan pitää vähemmän matemaattisesti orientoituneen kannalta helpompana.

CSP on imperatiivisen kieleen lisättävä laajennus, joka mahdollistaa erityisten kanavien (vrt. medium) käyttämisen. Oleellisesti kanavien kautta voidaan huolehtia viestinnästä edellä esitellyn kohtaamisen tavoin.

CSP vaikuttaa varsin mielenkiintoiselta, koska se näyttää tuovan luontevan ratkaisun moniin samanaikaisuuden ongelmiin. Käytännössä en ole joutunut kiinnittämään huomiota samanaikaisuuteen. Kuitenkin on selvää, että laskentatehon, erityisesti rinnakkaisen, lisääntyessä niiltä, jotka rohkenevat kutsua itseään ohjelmoijiksi, vaaditaan myös samanaikaisuuden hallinnan taitoja.

Löysin sattumalta Hoaren Communicating Sequential Processes -kirjan. Samalla löytyi myös toinen varsin mielenkiintoinen paikka. En ole mikään CSP-guru, mutta näin nopealla tutustumisella asiaan se vaikuttaa opettelemisen arvoiselta tekniikalta. Sattumalta löysin myös Pythonille toteutetun CSP-laajennoksen. Se näkyy olevan saataville myös useille muille kielille.

Tässä yhteydessä en osaa sanoa sen syvällisempää CSP:stä. Kuitenkin luento osoitti minut tässä suhteessa oikeaan suuntaan. Luennon toista pääasiaa, piilaskentoa tuskin tulen käyttämään yhtä paljon. Konstruktiona piilaskento on kuitenkin aika jännä.

Piilaskento, kuten CSP:kin, lähtee liikkeelle kanavan käsitteestä. Itse asiassa kaikki ajatellaan piilaskennossa kanavan käsitteen kautta. Se pyrkiikin olemaan samanaikaisuudelle sama asia, kuin lambdalaskento on ei-samanaikaisille (sekventiaalisille?) kielille.

Luennon suurin anti oli kenties sen antama näköala eri mahdollisuuksiin huolehtia viestinvälityksestä. Sinällään aihe on kannaltani varsin oleellinen. Olen joutunut miettimään viestinvälitystä useaan otteeseen omassa pienessä käyttöliittymäkirjastoprojektissani. CSP:n kaltainen ratkaisu voisi olla kenties tässä suhteessa potentiaalinen. Pitääkin selvittää jossain vaiheessa, miten samanaikaisuutta voi/kannattaa/pitää ottaa huomioon tämän tyylisessä projektissa.

Samanaikaisuuteen tulen törmäämään myös kuvankäsittelyssä. Kuvankäsittelyn tapauksessa tietyntyyppisiä operaatioita voidaan suorittaa hyvin tehokkaasti rinnakkain. Toisaalta tietyntyyppiset operaatiot (esim. kerneliin pohjautuvat operaatiot, kuten sumennus) ovat ongelmallisia ja tarvitsevatkin hieman toisenlaista tapaa ajatella. Onkin kyseenalaista kannattaako näitä operaatioita suorittaa rinnakkain ja jos kannattaa niin miten se on edullisinta.

Luento 16 - Yhteismuistisamanaikaisuus

Luennon aluksi eroteltiin samanaikaisuuden (concurrent) ja rinnakkaisuuden (parallel) käsitteet. Rinnakkaisesti etenevät tapahtumat ovat toisistaan riippumattomia. Samanaikaisuuden tapauksessa näin ei ole.

Tätä eroa voi kenties havainnollistaa pienellä esimerkillä. Olkoon Aaro ja Eero, jotka rakentavat kumpikin omaa majaansa. Kuopan kaivaminen on rinnakkaista, jos kummallakin on omat työvälineensä ja he rakentavat majaansa omassa paikassaan. Mikäli he joutuvat jakamaan työvälineitään edes jossain määrin, muuttuu tapahtuma käsittääkseni samanaikaiseksi juuri tämän riippuvuuden vuoksi. Voi olla, että Eero joutuu lainaamaan Aaron kirvestä, joka on hänellä käytössä. Tässä tapauksessa lienee luontevaa odottaa, ellei jotain muuta järkevää ole tehtävissä.

Olen taipuvainen näkemään rinnakkaisuuden käsitteen alisteisena samanaikaisuuden käsitteelle. Tuntuu järkevältä, että samanaikaisessa tapahtumassa osia voidaan suorittaa rinnakkain. Samanaikaisuus asettaa tosin yllä esitetyn esimerkin tapaisia rajoitteita, joita puhtaassa rinnakkaisuudessa ei ole.

Luennolla samanaikaisuus jaettiin kahteen ohjelmointikielten näkökulmasta kahteen lohkoon: yhteismuisti- ja viestinvälityssamanaikaisuuteen. Näistä ensimmäinen oli tämän luennon aiheena. Jälkimmäistä käsiteltiin seuraavalla luennolla. On huomattava, että molemmat tavat ovat yleisesti käytössä.

Mistä yhteismuistisamanaikaisuudessa on kysymys? Tässä tapauksessa samanaikaisesti suoritettavat tapahtumat jakavat osan yhteistä muistia, johon kumpikin pääsee käsiksi. Esimerkiksi yllä yhteismuistiin voitaisiin tallentaa Aaron ja Eeron käytettävissä olevat työkalut ja niiden tila (onko käytössä, kuka käyttää).

Yhteismuistin tapauksessa ongelmaksi muodostuu, kuinka hallita tätä yhteistä muistia. Toisaalta kunkin samanaikaisesti suoritettavan tapahtuman tulisi olla synkronoitu keskenään siten, että ne eivät voi olla keskenään virheellisessä tilassa. Toisin sanoen, jos Aarolla ja Eerolla on käytössään vain yksi kirves, ei heidän kummankin tulisi olla mahdollista käyttää samaa kirvestä eri paikoissa samanaikaisesti.

Eräs varsin käytetty ratkaisu on lukkojen käyttö. Tässä tapauksessa haluttu resurssi lukitaan siten, että sitä voi käyttää vain yksi käyttäjä kerrallaan. Toisaalta lukkojen suhteen lienee mahdollista tehdä eri kokoisia rajauksia. Voisikin kuvitella, että ääritapauksessa koko yhteismuistialueen voisi lukita. Tässä mielessä lukot muistuttavatkin tietokantoja ja niiden synkronointia. Pohjimmiltaan kyse onkin samasta ongelmasta.

Mitä yllä mainittu tarkoittaa ohjelmointikielten kannalta? Ohjelmointikieli voi ottaa selvästi kantaa samanaikaisuuteen tai se voi jättää samanaikaisuuden hallinnan kirjastojen vastuulle. Näkisin kirjastototeutuksen (esim. C ja POSIX) joustavampana. Toisaalta luennolla mainittiin, että kielissä, joissa samanaikaisuus on jätetty vähemmälle huomiolle, ei kirjastojen toteuttaminen ole välttämättä aivan yksioikoista. Kielen tulisikin olla määritelty tietyllä tavalla, jotta kirjastoja voisi toteuttaa täsmällisellä tavalla.

Luennolla mainittiin myös kriittisten lohkojen käsitteestä. Kriittiset lohkot suoritetaan siten, että kaikki muut tehtävät on pysäytetty. Lisäksi niiden sisällä olevaa toiminnallisuutta on rajoitettu. Tästä esitettiin myös kehittyneempi ehdollinen versio.

Aaron ja Eeron tapauksessa tämä lienee tarkoittaisi siteä, että lohkon avulla voisi samanaikaisuutta rajoittaa tapahtumien tasolla. Voisi esimerkiksi asettaa rajoitteen, jonka mukaan vain yksi henkilö kerrallaan saa maalata seiniä. Toisaalta tämänkin tulisi olla mahdollista vain, jos maalia on jäljellä ja ulkona on vielä valoisaa.

Luennon loppupuolella esitettiin abstraktimpi ratkaisu, monitori. Monitori kapseloi jaetut muuttujat operaatioiden avulla. Toisaalta vain yksi tehtävä voi käyttää operaatioita kerrallaan. Muut tehtävät asetetaan jonotuslistaan, kuten pankissa ikään. Tämän lisäksi monitori sisältää ehdollisia jonoja. Ehdollinen jono voitaisiin kenties toteuttaa siten, että ehdollisessa jonossa oleva tehtävä siirretään oikean jonotuslistan eteen ehdon toteutuessa. Tässä tapauksessa se suoritettaisiin heti monitorin suorituksen vapauduttua (olettaen, että suoritettavat tehtävät poimitaan jonosta järjestyksessä).

Aivan lopuksi esitettiin transaktion käsite. Transaktioiden käsite on lainattu suoraan tietokantojen puolelta. Oleellisesti transaktio olettaa, että jo toteutettu tapahtuma voidaan perua. Tämä asettaa joitain rajoitteita sille, mitä voidaan tehdä, mutta toiminee mukavasti, kunhan peruminen on mahdollista. Toisaalta on selvää, ettei kaikkea voi perua. Tässä tapauksessa joutunee käyttämään jotain muuta tekniikkaa. Voisi ajatella esimerkiksi käyttävänsä transaktioiden lisäksi ehdollisia kriittisiä lohkoja tai jotain muuta täydentävää tapaa.

tiistai 3. maaliskuuta 2009

Demo 7 - kommentit

Seitsemännen demokerran tehtävät löytyvät osoitteesta http://users.jyu.fi/~antkaij/opetus/okp/2009/demot/7.html . Tällä kertaa tehtävät olivat vaikeustasoltaan varsin kohtuullisia. Perustehtävistä tein muut paitsi tehtävän 2. Bonustehtäviä en tehnyt tällä kertaa.

2. tehtävä osoitti pätevästi kuinka kompaktisti binääripuita voidaan käsitellä lambda-laskennon avulla. Oma esim. C:llä tai Pythonilla tehty toteutus venyisi varmasti huomattavasti pidemmäksi. Tässä mielessä tehtävä oli hyvä muistutus siitä, että asioita voi tehdä toisinkin varsin kompaktisti.