Ohjelmointikielistä

Kuulen käytävältä kiroilua. Ohjelma ei käänny. Hetki kuluu ja virheen syy selviää. Osoitin on osoittanut jo vapautettuun objektiin. Naapurini tekevät C++ -kielellä virtuaalimaailmaa, jossa ihminen voi vuorovaikuttaa maailman hahmojen kanssa. Naapurini törmäävät usein vaikeasti selviäviin ongelmiin. He saavat kääntäjältä kummallisia virheilmoituksia. Valitettavasti naapurieni ongelmat ovat osittain itse aiheutettuja. He käyttävät väärää ohjelmointikieltä. Vaikka C++ on suosittu kieli, ei se kuitenkaan ole hyvä oliokieli. Jopa alan teollisuus on luopunut C++:n käytöstä lähes kaikkialla missä mahdollista. Nykyisin jo pelitkin käyttävät sisäisesti skripti- ja kuvauskieliä maailmojen ja maailmojen objektien välisten interaktioiden kuvaamiseen. Vain kaikkein suorituskykykriittiset osat kannattaa koodata C++:lla tai C:llä. Naapurini aikovat ilmeisesti koodata koko projektin C++:lla vaikka tiukkoja suorituskykyvaatimuksia ei olekkaan.

Mielestäni tärkein yksittäinen tekiä, millä ohjelmistotyön tuottavuuteen voidaan vaikuttaa on käytetyt ohjelmointikielet. Menetelmillä ja käytetyillä työkaluilla kuten kääntäjillä, debuggereilla, profiloijilla, IDE:llä ja editoreilla on kaikilla tietenkin asiaan vaikutusta. Tuottavuuden kannalta kielen valinta on tärkein tekijä. Kielellä on keskeisin merkitys, koska ohjelmoija kuvaa sillä ongelman ratkaisun (tai ongelman).


Hyvin laadittu kieli on ongelmakentällään ilmaisuvoimaisin tapa kuvata ratkaisu tai ongelma. Tämän vuoksi en ole kovinkaan innokas kun näen työkaluja joissa voi ohjelmoida graafisesti. Yleensä graafisella työkalululla ohjelmointi on merkittävästi hitaampaa kuin saman asian sanominen ilmaisuvoimaisella kielellä. Tästä minulla on omakohtaistakin kokemusta. Kun olin vielä teollisuudessa ja teimme yksinkertaista logiikkaa graafisella työkalulla televerkon hallintaan, oli graafinen työkalu jopa niin hidas, että kokeneet logiikan luojat loivat mielummin saman logiikan suoraan kyseisen työkalun XML-pohjaisella kielellä, vaikka kieli ei oltu suunniteltu käsin ohjelmoitavaksi. Jollain tavallisella kielellä kuten Java saman logiikan olisi tehnyt murto-osassa siitä ajasta, mitä "helpolla" graafisella työkalulla kulutimme asiaan aikaa. Suunnittelutyötä UML-kaaviot helpottavat, koska ne piirretään abstraktimmiksi kuin syntyvä ohjelma. Jos kaaviot piirrettäisiin samalla abstraktiotasolla kuin itse ohjelma, kaavion tekemisessä olisi enempi vaivaa kuin saman asian tekeminen ohjelmointikielellä.

Kun kieli ei osaa jotain hyödyllistä asiaa päädyytään helposti huonoihin ratkaisuihin. Tarvitaan joko ylimääräistä työkalutukea, generoitua koodia, kirjastoja tai kieltä käytetään jonkin konvention mukaan. Nämä ratkaisut saattavat johtaa vaikeasti hallittavaan yhdistelmään koodia, kuvaksia ja riippuvuuksia. Ratkaisut lisäävät virhealttiutta erityisesti ohjelman kehittyessä. Hajautetussa ohjelmistokehityksessä ongelmat vielä korostuvat. Corbaa, RMI:tä, tai jotain muuta middlewarea käyttäneet ymmärtänevät mitä tarkoitan. Middleware-arkkitehtuureista saadaan vasta sitten helppokäyttöisiä ja vähemmän virhealttiita kun kielet tukevat niitä.

Teollisuudessa usein unohdetaan käytetyn kielen merkitys ja päädytään käyttämään sitä kieltä, jota on ennenkin käytetty. Kieltä vaihdetaan vasta kun on pakko. Akateemisessa maailmassa taas historiallisesti on jokaista vastaan tulevaa ongelmaa pyritty ratkaisemaan uudella kielellä. Kieli kun on mukava väitöskirjan aihe. Akateemisessakin maailmassa ollaan hieman päästy kielivillityksestä eteenpäin ja välillä tuntuu, että ohjelmointikielen merkitystä on vähän jopa unohdettu.

Eli seuraavan kerran kun aloitatte uutta projektia, miettikää millä kielellä se oikeasti olisi järkevintä toteuttaa! Ja pitäkää silmänne auki, aina silloin tällöin keksitään hyvä uusi kieli! (Uusista kielistä yksi suosikeistani on D, mutta siitä lisää jokin toinen kerta)