Staattisesta tyypityksestä luopuminen on vähän samanlainen juttu, kuin C++:n const-avainsanasta luopuminen oli aikoinaan 1990-luvulla. Itse koin tuolloin hirveää tuskaa opiskellessani Javaa, kun muuttujia ja metodien parametrejä ei voinutkaan enää määritellä const-tyyppisiksi.
C++:n const-avainsanan tarkoitushan on antaa suunnittelijalle täsmällinen kontrolli siihen, mitkä metodit voivat muuttaa olioiden sisältöä ja mitkä eivät. Jos joku muuttuja on määritelty constiksi, sen kautta voidaan kutsua ainoastaan const-metodeita, jotta voidaan olla varmoja, ettei muuttujan sisältö muutu.
Tämä kaikki oli tosi hienoa, mutta aiheutti aivan mielettömän overheadin C++-ohjelmiin, kun ohjelmoijan piti jokaisessa mahdollisessa käänteessä huolehtia siitä, että const-määreet menivät oikein. Monet ohjelmoijat jättivät constin kokonaan pois ohjelmistaan, jolloin constiton ja constillinen ohjelmakoodi eivät voineet kunnolla kutsua toisiaan. Väliin tarvittiin tukuttain rumia typecastauksia, jotka mitätöivät koko constin idean.
Staattisista tyypityksistä luopuminen on hyvin samankaltainen muutos. Ymmärrän hyvin, että monet suunnittelijat eivät haluaisi luopua tästä kontrollista. On niin turvallinen olo, kun koko ohjelmakoodi on tarkkaan määritelty toimimaan juuri tietyllä tavalla, ja "rikkomukset" jäävät kiinni heti käännösvaiheessa.
Viime kädessä täytyy kuitenkin asettaa vastakkain staattisen tyypityksen hyödyt ja haitat. Constin tapauksessa Javan suunnittelijat totesivat aikoinaan, että siitä koituu niin paljon ylimääräistä, pakollista työtä, ettei se ole vaivan arvoinen. Itse olen sitä mieltä, että ainakin dynaamisen webbiohjelmoinnin tapauksessa sama pätee staattiseen tyypitykseen. Saavutettu turvallisuus ei ole kaiken ylimääräisen vaivan arvoista.
Jos katsotaan vielä vähän kauemmas historiaan, niin staattisen tyypityksen idea periytyy oikeastaan C:stä, joka käsittelee RAM-muistia paljaaltaan. C-ohjelmissa on erittäin tärkeää, että määritelty struct-rakenne vastaa täsmälleen RAM-muistista allokoitua N tavun blokkia, tai että parametrinä annettua 32-bittistä integeriä ei käsitellä vahingossa 16-bittisenä. Tämä on tärkeää siksi, että välissä ei ole mitään virtuaalikonetta, joka huomaisi väärän tyypin ja heittäisi exceptionin. Muisti vain korruptoituu saman tien ja sovellus sekoaa tyystin.
Pythonin kaltaisessa kielessä ollaan kuitenkin tultu valovuosien päähän raa'asta RAM-muistin käsittelystä. Nyt välissä on se virtuaalikone, joka tarkastaa tyypit ja heittää turvallisen exceptionin virheen sattuessa. Sovelluksen toiminta on virheen jälkeenkin determinististä, eikä se esimerkiksi satunnaisesti korruptoi RAM-muistia tai tiedostoja.
Pidän siis kiinni väitteestä, että nykyaikaisissa virtuaalikoneissa pyörivissä kielissä staattista tyypitystä ei tarvita. Se voidaan korvata sopivalla unit-testauksella, joka on vapaaehtoista. Itse ohjelmointi muuttuu merkittävästi helpommaksi ja tuottavammaksi.