KESKUSTELU

Urf... BlockRead Mieleen alkaa kumpuamaan jotain hyvin ikäviä muistoja...



Niin... minä olen päässyt keplottelemaan asemaan, jossa hommat koostuvat mm. protokollien ja algoritmien kehityksestä ja työnantajaa ei voisi vähempää kiinnostaa millä kielellä koodaan omat ideoiden testaukseen käyttämäni työkalut - kunhan vaan lopputulemana on riittävän hyvä speksi.



Mitä? Ei moniperintää? Blah... eihän sellainen kiinnosta.

Itseasiassa ajattelin seuraavaksi opetella Erlangin, koska siinä on rinnakkaistus ja hajautus suoraan sisään rakennettuna.

Saapas nyt sitten kuitenkin nähdä - vuosien saatossa kun on pitänyt opetella kaikkea muutakin heti, kun kerkiää...

Minä aikanani rakentelin sellaista käyttöliittymä-runtime -kirjastoa, jossa kaikki asiat tehtiin moniperinnällä pienistä paloista. Yksi moniperittävä luokka oli ikään kuin "DNA:ta", ja pienistä paloista koostettiin isompia kokonaisuuksia.

Meni sen homman kanssa lopulta hermot, kun projektin kanssa olin ihan solmussa, että mitähän attribuuttia oliot nyt oikein käsittelee tai mitä metodia kutsuu, kun saman nimisiä tuli hierarkian ylemmiltä palikoilta moneen kertaan eri kautta

...Toinen "kuningasidea" oli se, että tein kirjastoa, jossa kaikki ikkunan komponentit olivat omia rinnakkaisia prosessejaan. No, olihan siinä hyvätkin puolensa, mutta oli se aika hirveän raskas ja X-serveri oli aina välistä vähän ihmeissään siitä, että kukas täällä nyt käskee tehdä ja mitä Tosin tämä projekti oli työn alla joskus viime vuosituhannella.

Erlangia on kyllä paljon kehuttu - tai sanottu, että se voi olla vaikea aloittaa, mutta mukava sitten, kun sitä osaa - mutten ole itse vielä saanut kipinää sen opettelemiseksi.

C++ yksinään voi olla hieman karu, jos on tottunut Pythonin, Javan tai C#:n vakioherkkuihin.

C++:sta kiinnostuneille olenkin yleensä suositellut kunnon työkalupakkia onnistumisprosentin maksimoimiseksi. Qt esimerkiksi on loistava. Ei häpeä näppäryydessä Pythonille juuri lainkaan mutta natiivibinäärien vauhti ja suorituskyky onkin sitten omaa luokkaansa.

En varmaankaan osaa selittää tätä kovinkaan hyvin, mutta koittakaa pysyä perässä...

Ensinnäkin sanottakoon, että C++ lemmikkiprojektini on tapahtumapohjainen simulaattori, jossa tapahtumien välitys on abstrahoitu siten, että simulaattorikirjastoa käyttävän ohjelmoijan ei tarvitse tietää onko simulointi yksisäikeinen, monisäikeinen vaiko kokonaan hajautettu. Tämä projekti on tosin ollut syvässä unessa jo vuosikaudet...

Se mitä tarkoitan "eleganttiudella" tulee toisaalta osittain tuosta karuudesta, mutta myös ilmaisuvoimasta, joka liittyy moniperintään, templateihin, operaattoreiden ylikuormaukseen jne. Ehkä toisella tavalla sanottuna juuri niihin C++:n ominaisuuksiin, joilla aloittelija kaikkein helpoiten ampuu itseään jalkaan.

Jotenkin siis se, että pystyy sanomaan mahdollisimman paljon äärimmäisen vähällä määrällä koodia, on mielestäni jotekin kaunista - vaikka se monasti merkitseekin sitä, ettei kukaan muu ihan pienellä pohtimisella hoksaa mitä koodi oikeastaan tekee. Uudelleenkäytettävyyden kannalta tietysti hieman huono juttu, mutta ainakin minä saan aikamoiset fibat, kun yhtäkkiä kokee "valaistumisen" ja tajuaa miten kymmenien rivien sillisalaatin pystyy korvaamaan parin rivin nerokkaalla "loitsulla".

Ok, käsittääkseni ymmärsin nyt, mitä tarkoitit.

Tuossa edellä lähinnä halusin antaa vinkin mahdolliselle C++ -aloittelijalle. Kannattaa samantien tutustua tehokkaisiin työkalupakkeihin, niin voipi jossain vaiheessa saada jotain aikaiseksikin

C++:n työkalupakeista edellä mainitsemani Qt mielletään yleensä graafisten käyttöliittymien kirjastoksi. Tätä se tietenkin on mitä suurimmassa määrin, mutta myös paljon muuta. Esim. säikeystys on äärimmäisen kätevää ja suoraviivaista Qt:n ytimellä, hommaa ei juurikaan näppärämmin voisi hoitaa.

Toki myös muut paketit, kuten boost, tarjoavat paljon mukavaa C++-ohjelmoijan elämää helpottavaa pikkukivaa, Qt ei missään nimessä ole ainoa kirjasto. Qt:n käyttö on kuitenkin hyvin maanläheistä ja pragmaattista ja koodista tulee mielestäni varsin siistin näköistä ja luettavaa.

Ja kun lukee saman pätkän muutaman vuoden päästä, ei sitä tajua enää itsekään.

Loogisesti yksinkertainen ratkaisu on tietenkin aina kaunis. Se on lähempänä ongelman ydintä, ja siksi sellaisen löytämiseen liittyy aina jonkinlainen valaistumistuntemus.

Tyylikkäitä ratkaisuja ei kuitenkaan tarvitse esittää mitenkään korostetun tiiviisti. Ei sen koodin kauneus minusta vähene, vaikka sitä jäsentelee, laventaa ja höystää kommenteilla sen verran, että sen ymmärtäminen ei enää ole mitään salapoliisitouhua. Huoliteltu muotoilu, selkeys ja helppolukuisuus on myös kaunista, ja sellaista kauneutta arvostaa sitä enemmän, mitä enemmän joutuu lukemaan koodia, jota ei ole viitsitty mitenkään jäsennellä ja selventää.

Joskus tiiviys ja selkeys kuitenkin leikkaavat.

Quicksort (Haskell -- geneerinen):


Quicksort (C, C++, Java, melkein C# -- vain int-taulukoille):

Olekin koittanut pitää "taideohjelmoinnin" erossa oikeasta työnteosta, mutta täytyy kyllä tunnustaa, että n. viikko sitten tuli ihmeteltyä omaa python-koodia - ensiksi luulin, että oli tehnyt jonkun typerän virheen ja että koodi tekisi jotain ihan muuta kuin sen piti - seuraavaksi, kun koodia olisi pitänyt korjata, en ymmärtänytkään yhtään mitä se teki - kunnes puolen päivän pohdinnan jälkeen hoksasin, että koodihan teki juuri sitä mitä sen pitikin

...ja olin kirjoittanut kyseisen pätkän pari viikkoa aiemmin...

No - muutujien epäselvä nimeäminen ja ylimalkaiset kommentit yhdistettynä näppärään kikkaan on monasti aika huono yhdistelmä.

Joo...