Mitä Paul Graham voi kertoa meille web-standardeista

Toisinaan on tullut mietittyä minkä takia web-standardien omaksuminen tuntuu tekevän niin tiukkaa joillekin ihmisille. Pari päivää sitten tuli mieleeni, että tällä voi olla jotain tekemistä Blub-paradoksin kanssa.

Kirjoituksessaan Beating the Averages, entinen ohjelmoija ja nykyinen sovelluskehittäjä Paul Graham perustelee sitä että Lispiä harvemmin käytetään, vaikka se tunnetaan erittäin ilmaisuvoimaisena ohjelmointikielenä. Graham itse on Lisp-guru ja hän pystytti sitä käyttäen Viawebin, maailman ensimmäisen verkkokauppoja palveluna tarjonneen yrityksen.

Grahamin Blub-paradoksin voisi ehkä muotoilla toisin sanoin seuraavasti: Oletetaan ohjelmointikieli nimeltä Blub, joka ei ole maailman tehokkain kieli muttei myöskään maailman tehottominkaan kieli. Blubia osaava ohjelmoija ei voisi kuvitellakaan käyttävän vähemmän tehokasta kieltä, sillä niistä puuttuu ominaisuus X (missä X kuvaa jotain Blubin ominaisuutta jota kyseinen ohjelmoija käyttää päivittäin). Toisaalta vain Blubin hyvin tunteva ohjelmoija ei myöskään liiemmin välitä tehokkaammista kielistä, ne näyttävät hänestä lähinnä siltä kuin Blubiin olisi lisätty jotain turhuuksia. Riippumatta siitä mihin kohtaan ohjelmointikielten tehokkuuden jatkumoa Blub kiinnitetään (ääripäitä lukuunottamatta), ohjelmoija jonka tiedot pääasiassa rajoittuvat Blubiin harvemmin tuntee tarvetta opetella tehokkaampia kieliä.

Tämä tuo minulle mieleen web-standardien tilanteen: CSS-taiton hyötyjä näyttäisi olevan vaikea selittää taulukkotaittoon tottuneille ihmisille erityisesti siksi, että vaikka hyötyjä yritettäisiinkin listata heille, heidän taustatiedoistaan on enemmän apua haittojen kuin hyötyjen ymmärtämiseen ja he pitävät siksi koko juttua jonkinlaisena akateemisena säätämisenä.

Otetaan esimerkiksi selainyhteensopivuusongelmat. Taulukkotaittaja miettii miten jotkut jaksavat puurtaa CSS-tiedoston parissa. CSS-taittaja puolestaan ihmettelee miten jotkut jaksavat sisäkkäisten taulukkojen tuoman tagisekamelskan kanssa, erityisesti jos sivua pitää manipuloida JavaScriptillä.

Tai validointi. Validaattoria harvemmin käyttävä henkilö miettii miksi ihmeessä joistain "virheistä" pitäisi välittää kun sivu kerran toimii selaimessa. Validoinnin suurin hyöty on kuitenkin siinä että se tekee sivun käyttäytymisestä helpommin ennakoitavaa ja karsii omituisia ongelmia.

Oletetaan että Graham on oikeassa Lispin ja Blubin suhteen ja sama tilanne toistuu web-kehityksen yhteydessä. Mitä hyötyä tästä on? Aika vähän sellaisenaan, ilman että tiedetään mitkä puuttuvat taustatiedot ovat (tai millä muulla tavalla tietämysrakenteet eroavat toisistaan).

Ainakin jos mietin omia toimintatapojani, suurin ero "ennen web-standardeja" ja "web-standardien jälkeen" on siirtyminen arvauksista ja säätämisestä suunnitteluun ja säätämiseen. Ilman standardeja ja ilman CSS:ää lähdin liikkeelle kokeilemalla erilaisia erilaisia sopivantuntuisia tageja (elementeistä en tietenkään silloin ollut kuullutkaan) sopivantuntuisiin kohtiin kunnes saavutin halutun tuloksin. Nykyisin sen sijaan suunnittelen rakenteen lähes kokonaan päässäni, kirjoitan sen kerralla ja teen lopuksi korjauksia ainoastaan jos rakenteessa on jonkinlainen virhe tai selainbugeja tulee vastaan.

Onko tämä tavallista? Onko tämä merkitsevin ero? Vai onko kyse vain yksittäisestä tapauksesta? En tiedä.