Setä ranttaa matikasta: miksi eksponenttifunktio ja Neperin luku?

Vesa Linja-Ahon seinällä tuli puhetta eksponenttifunktiosta, ja lupasin selittää mikä siinä on niin ihmeellistä. Eritoten, mikä on niin ihmeellistä juuri e-kantaisissa eksponenteissa ja logaritmeissa. Kun rupesin kirjoittamaan, homma paisui kuin pullataikina, kunnes lopulta totesin että parempi aloittaa alusta. Eli, yritetääs sittenkin sanoa tämä jotenkin vähän yksinkertaisemmin.

Algebrallisesti eksponenttifunktio on syntynyt alunperin samanlaisena lyhennyksenä kertolaskusta kuin kertolasku yhteenlaskusta. x*y tarkoittaa samaa kuin x+x+x+...+x jossa x:iä on y kappaletta, ja aivan vastaavasti x^y tarkoittaa x*x*x*...*x, jossa x:iä taas y kappaletta. Kaikkien kolmen operaation kohdalla on myös aikanaan tullut tarve tehdä homma käänteiseen suuntaan, mistä on saatu vähennyslaskun ja jakolaskun käsitteet. Nuo käsitteet sitten ovat herättäneet lisäkysymyksen: olisikohan ne mahdollista ilmaista erillisen operaation asemesta saman alkuperäisen operaation kautta liittämällä itse lukujoukkoon käänteis- tai vasta-alkioita.

Yhteenlaskussa vastaus on ehdoton kyllä, ja siitä lähti alunperin niin nollan kuin negatiivisten lukujenkin ajatus. Nuo lähtivät ensin käytännön kirjanpitotarpeista, ja sitten johdonmukaisesta yleistyksestä kun huomattiin että lukujanalla voi liikkua vasemmalle ihan samojen sääntöjen mukaan kuin yhteenlaskussa oikealle, ja sitä kautta ratkaista lineaarisia yhtälöitä koneellisesti/algebrallisesti. Kertolaskussa vastaus on miltei sama, eli huomataan tutun ykkösen käyttäytyvän kuin nolla yhteenlaskussa käyttäytyy, ja käänteislukujen käyttäytyvän aivan kuten vastaluvut yhteenlaskussa; nykytermein sanotaan että murto- ja reaaliluvut muodostavat molemmat ryhmän niin kerto- kuin yhteenlaskunkin suhteen, erikseen.

Ainoa poikkeus on luku nolla: sillä ei voi jakaa. Tämä ei johdu laskutoimitusten rakenteesta sinänsä, vaan kertolaskun historiasta moninkertaisena yhteenlaskuna. Se koodataan nykyään distributiivisuussääntöinä jotka kytkevät nuo kaksi eri tapaa käsitellä reaalilukuja toisiinsa, ja jotka modernein termein tekevät niin murto- kuin reaaliluvuistakin kunnan. Jos ja kun ne halutaan pitää voimassa, voidaan todistaa että noiden kahden laskutoimituksen identiteettialkioiden pitää olla erillisiä, tai sitten kunta lakoaa mielenkiinnottomaksi triviaalitapaukseksi.

Eksponenttifunktio toki oli tunnettu jo aiemmin koronlaskun matematiikan tähden, mutta sen käänteisoperaatio eli logaritmi tuli mukaan kuvaan mutkan kautta, ja vasta 1600-luvulla, koska sillä ei aiemmin ollut merkittäviä sovelluksia arkimatematiikassa. Logaritmia käytettiin alunperin kertolaskun helpottamiseen. Tässä olennaisessa osassa on tuo jo mainittu kertolaskun ja yhteenlaskun historiallinen yhteys: ensimmäinen on toistettu versio jälkimmäisestä, joka oli nyt vihdoin ilmaistu täysin yleistettynä versiona ja oli kirjoitettavissa yhtenä operaationa suuremmassa lukujoukossa. Nimittäin, aivan vastaava yhteys on sitten kertolaskun ja eksponenttienkin välillä, sekin voidaan yleistää suurempaan joukkoon, ja kaikki tuo onnistuu niin että laskusäännöt säilyvät. Nykytermein sanotaan, että eksponenttifunktio on isomorfismi reaalilukujen additiiviselta ryhmältä niiden multiplikatiiviselle ryhmälle. Vaikka laskutoimitukset ovat erilliset, ne ovat sillä tavalla samanrakenteiset, että kun vain osaat hyppiä noiden kahden esityksen välillä, operaatiot toisessa ryhmässä voi yhtä hyvin toimittaa toisessa, ja sitten vain muuntaa takaisin. Tulos ei muutu.

Logaritmi keksittiin alunperin tuohon tarkoitukseen: yhteenlasku käsin on tavattoman paljon helpompaa kuin kertolasku, varsinkin hankalilla murtoluvuilla, eli kunhan kerran taulukoit tuon isomorfismin (logaritmi), voit hypätä kertolaskuongelmasta yhteenlaskuongelmaan, ynnätä, ja pompata käänteisisomorfismin (eksponentti) kautta takaisin, ja ongelma ratkesi tavattoman paljon helpommin. Mm. laskutikku toimii tuolla periaatteella: sen asteikot ovat reaalilukujen isomorfismeja, suoritettava operaatio on kahden janan summa, ja sitten viimeinen hyppy liukuvasta asteikosta kiinteään toteuttaa käänteisisomorfismin. Voila: toimiva puolisilmämääräinen kertolasku. (Leveämmissä ns. "insinööritikuissa" joukko muitakin samankaltaisia homomorfismilaskuja, ja laskupyörissä sama homma lisäksi topologisesti ympyrän näköisille ryhmille, sekä Riemann-lehdistön tapaisten käsitteiden kautta moniarvoiset käänteis"funktiot" niiltä.)

Voidaan myös näyttää, että tämä selittää eksponentti–logaritmi-parin erityisyyden täysin. Ei ole mitään muuta kaikki halutut säännöt säilyttävää isomorfismia reaalisten yhteenlasku- ja kertolaskuryhmien välillä. Mutta yksi ikävä liikkumavara vielä on: miksi ne eksponentit tehdään mieluiten Neper-kantaan, kun kyllähän tuo logaritmijippo kertolaskussa toimii muillakin—ensimmäiset logaritmitaulukot esim. olivat kymmenkantaisia—eikä kertolaskussa tai yhteenlaskussa toki ole tuollaista ihme-erityis-lukua. (Identiteettialkiot on, mutta niin se on ykkönen eksponentillekin, eli tuo e on ylimääräinen erikoisluku verrattuna siihen.)

Neperin luvun erityisyyden voi selittää hyvin monella eri tavalla riippuen siitä minkä matematiikan erityisalueen näkökulmasta katsot asiaa. Tuo moninaisuus itsessään on taas sitten selitettävissä ainakin parilla eri tavalla, joista annan vain kaksi. Ensimmäinen intuitiivinen juju on se, että joka kerta kun työnnämme rekursiivisesti johonkin tavalliseen loogiseen systeemiin lisäaksioomia, joko se jossain vaiheessa stabilisoituu niin että rekursio tuottaa vain lisää samaa (parempi lopettaa), tai lisäehdot supistavat sallitut toteutukset (mallit) loogisesta rakenteesta äärelliseen kokonaismäärään (kiva tietää, ja sitten peli loppui) tai monimutkaisuus kertautuu (ehkä kiva tietää, joskin useimmiten tosin vain tylsä, säännöllinen, kombinatorinen räjähdys jossa kaikki käy; todellakin parempi lopettaa jos haluaa säilyttää mielenterveytensä).

Eksponenttifunktio kantaan e on monessakin suhteessa juuri tuolla rajalla: sen tavallinen derivaatta (ja siis antiderivaatta) ovat esimerkiksi tismalleen se itse, jolloin se on helpoimmin hallittava ja parhaiten tunnettu perustapaus johon kaikki muut tuollaiset itsensäkaltaisiksi skaalautuvat ilmiöt redusoidaan. Tämä esimerkiksi on se syy miksi e pulpahtaa aina pintaan fraktaalien, kenttäteorioiden, ja vaikkapa jatkuvan muuttujan pitkällemenevien tilastollisten riippumattomuusoletusten kanssa: jos x mittakaavasta/-tikusta (siis kertolaskun valitusta "erityiskannasta"; mittauksen "perusyksiköstä") riippumatta näyttää ihan samalta, x on oikeastaan matikan haarasta riippumatta väkisin jotenkin sidoksissa e-kantaiseen eksponenttiin. Kaikki skaalariippumattomuuden ajatukseen liittyvä reduktiopäättely lähes vääjäämättä laskeutuu jotakin tai useampaa morfismien ketjua pitkin kohti tuota simppeleintä ja tunnetuinta ja suljetussa muodossa näteimmin käyttäytyvää perusesimerkkiä.

Tuon kummallisuuden tajuaa ehkä parhaiten, kun vertaa sitä toiseen esimerkkiin ilmiöstä: pi:hin. Se ilmaantuu aivan samalla klassisen tragedian vääjäämättömyydellä kaikkiin laskuihin joilla on jotain tekemistä periodisuuden/syklisyyden/toistavuuden kanssa. Nimittäin toistavasta rakenteestahan perusesimerkki ja parhaiten tunnettu ja suljetussa muodossa nätein on tietenkin ympyrä, jonka symmetriaan pi sitten olennaisesti liittyy.

Molemmista noista vakioista voi sitten myös toisaalta sanoa, että ne ovat paitsi loogisen mahdottomuuden ja mielivaltaisuuden rajalla ja siksi erityisiä, myös luonnollisten yleistystensä kautta osa monta niin jäykkää rakennetta, että ne rakenteet itsessään, yksikäsitteisyydessään, levittävät jäykkyyttä joka paikkaan mihin koskevat. Mikään ei ole tästä parempi esimerkki kuin kompleksilukujen kunta, ja se kuinka pi ja e kohtaavat siinä Eulerin yhtälön kautta.

Kompleksiluvut nimittäin ovat (taas todistetusti) ainoa tapa säilyttää reaalilukujen (tärkeitä koska kaikki arkimittaaminen ja kirjanpito perustuu niihin) tavalliset ominaisuudet (poislukien lineaarinen järjestys), ja silti lisätä niihin se ominaisuus että äärellisestä yhteen- ja kertolaskusta lähtevät (polynomi)yhtälöt ovat aina ratkaistavissa. (Se että järjestys ei voi säilyä on helppo nähdä jälkikäteen yksikköympyrän olemassaolosta: kaikki sen pisteet toteuttavat yhtälön x^2+y^2=1, eikä topologista ympyrää voi järjestää lineaarisesti. Jossain täytyy tehdä valinta, ja ympyrät sekä suorat on paljon kiintoisampi juttu kuin vain suorat. Silloin järjestys rajoitetaan reaalilukujen osajoukkoon ja annetaan ympyröiden kukkia kompleksitasossa; tuo myös riittää samalla kaikkeen muuhunkin polynomikamaan, eli me hymyillään leveästi.)

Lukujärjestelmänä kompleksiluvut ovat sitten myös niin äärimmäisen jäykkä systeemi, ettei niitä kertakaikkisesti voi tehdä mitenkään muuten; ne on jo tuon algebrallisen ja topologisenkin täydellisyytensä takia ympätty niin täyteen rakennetta ja symmetriaa, että juuri mitään ei voi muuttaa ilman että kaikki lakoaa suuntaan tai toiseen käsistä. Niiden joka nurkasta irvistää, kaikista mahdollisista näkökulmista, yksikäsitteisyyttä, isomorfiaa, yhtä kertolaskun ominaisuutta, toista yhteenlaskun ominaisuutta, ja kaikkea sitä millä tuollaisia käsitteitä nyt ylipäänsä kuvataan. Eli siis kertolaskun ykköstä, yhteenlaskun nollaa, toistetun kertolaskun e:tä, yksikköympyrän koodaaman syklisyyden pi:tä, ja sitten kun noin iso pirulainen ei enää sopinut dimensioon yksi (järjestysrikko), sen ylimääräisen dimension tuomaa miinusmerkkiä/imaginaariyksikköä/konjugaatiota.

Kun kaikissa ryhmissä alkiot joko palautuvat eri operaatioissa samaan tai eivät, ainakin se palautuminen on käsitteenä palautettavissa usein johonkin morfismiin johonkin kompleksisen yksikköympyrän diskreettiin aliryhmään, tai niiltä, tai sitten monimutkaisemmat jutut johonkin rakenteeseen jonkin kompleksitason polynomikäyrän sisällä, tai... Kun kaikessa rajalaskussa puhutaan pienistä muutoksista jonkin jutun ympärillä ja niiden seuraamukset tuppaavat olemaan palautettavissa lineaarikuvausten teoriaan, jälkimmäinen teoria sitten palaa perusesimerkkeinään siihen miten siirrot (yhteenlasku), skaalaukset (kertolasku) tai kierrot (unitaaritransformaatiot, joista simppelein on joko kompleksisen yksikköympyrän käytös) tai hyperboliset kierrot (pahuutta reaalisen ykkösen lähimaastossa) käyttäytyvät...

Niinkin perverssejä kavereita on että tarvitsevat jotain ilkeämpää kohdetta reduktiolleen kuin kompleksilukuja, mutta he ovat harvassa, he ovat tosi perverssejä, eivätkä he enää työskentele edes niin arkisten, elämänläheisten ja simppeleiden juttujen kanssa kuin...koko nykyfysiikka seuraamuksineen.

Tuosta näkökulmasta siis voidaan sanoa, että e ei itse asiassa olekaan erityisen merkittävä ihan vain yksin, vaan että se on osa sitä suurempaa ja monipuolisempaa pakkopaitaa jota kutsutaan kompleksiluvujen kunnaksi. Se tulee samassa paketissa kaikkien sen muidenkin erityisvakioiden kanssa, kuten pi:n. Nuo erityisvakiot joukkona ja kompleksiluvut kokonaisuutena sitten ovat niin olennaisia siksi, että ne ovat yleisin, hyödyllisin, ylivoimaisesti jäykin/yksikäsitteisin, ja sitä kautta asenteesta riippuen joko kaunein/elegantein tai tyrannisin/pahantahtoisin/maagisin matemaattinen konstruktio johon terveet ihmiset joutuvat koskaan törmäämään. Nuo yksiköt nyt vain ovat se luonnollisin ja simppelein tapa kuvata kyseinen monalisa/belzebub; se joukko invariantteja joiden termein on vähiten kivuliasta ilmaista kaikki tuohon monumentaaliseen enkeliin–paholaiseen liittyvät käytännön laskut–reduktiot. Todistettavasti ainoa tapa myös, koska ne eivät ole ihan vain symboleja tai kivoja lukuarvoja, vaan puhtaita numeroita jotka olisivat kaikissa vastaavaa yleisroolia toimittavissa vaihtoehtoisissa loogisissa järjestelmissä välttämättä olennaiselta sisällöltään samoja.

Kun sitten viimein tuntuu olevan niin että jokseenkin kaikki kiva–kiintoisa–hyödyllinen inhimillisesti–ymmärrettävä matemaattisesti redusoituu noihin pyörimisiin, siirtoihin, summiin, tuloihin ja niille tai niistä lähteviin analogiapäättelyihin/morfismeihin, ei se suurikaan ihme ole että taikauskoisempi matemaatikkokin katsoo e:n olevan yksi osa Kirjaa. Siis suoranaisesti Jumalan itseilmaisua, ateistin päässä Luonnon itsensä invariantti substantiivi, tai paatuneen relativistiskeptikonkin kuten itseni päässä "se helpoin tapa inhimillisesti puhua tietyistä kokemusmaailmamme äärimmäisen yleisistä, matemaattisiksi nimitetyistä lainalaisuuksista, tai niiden järkeenkäyvistä johdannaisista".

The duplicate state fallacy

Suppose you just started coding against a rich user interface framework. It keeps all sorts of state to itself, and notifies about changes by whatever mechanism. As the simplest example, it does have to know what to render in a menu when the user scrolls it down, so it keep the whole list to itself. Or perhaps it contracts your code to refresh the screen whenever something interesting happens.

Be as it may, it's always about who owns the state. It's always about either the shortcomings of the graphics framework, or about the shortcomings of your code. In particular it's never fast enough because it's just too damn hard to coordinate two separate processes handling common state unless they've been designed as one from the beginning.

And, hence, even the monolithic, gargantuan, Linux kernel. What state management problems you had with the screen are amplified roughly three decades by working with an all-knowing OS kernel, coded by performance minded nerds. In C.

In actual fact the trouble could be avoided. What fucks you up here is the shared state between processes, and the fact that it can be assigned to in a non-atomic, autonomous way. If there was proper state management and a shared atomic semantics, either process could assign whatever it wanted to the state without wreaking havoc. And if it was necessary to notify somebody else upon an assignment, well they'd be notified automatically, they'd be structured to handle the lightweight message, and they'd just be happy without much further effort. For instance, you could just say that part of the menu text changed and then the next time the UI framework needed to paint that region over, it'd just render your shared text from where you put it.

You can actually do this in languages like Common LISP, and their frameworks. That's because the program semantics do not assign into any state per se, but relegate that sort of thing to a carefully controlled, low level, optimization layer, with its own separate operations and their interaction semantics. The overall, surface level, mostly-used semantics of the language just encode your state evolution, and that of your abstract interfaces. With any decently coded UI framework they externalize the low level, performance tweaking to a shallow abstraction layer.

Not only because they should, but because they also can: the nastiest problem with commonly used procedural languages is that they indeed cannot, because their semantics do not really force the coder to enunciate, precisely, what the state evolution rules ought to be in the first place. They simply do not force the programmer to give enough data to the compiler, so that it can do its job properly.

I'm not saying the functional programming paradigm is the be all and end all of programming, especially as it now stands. Far from it; I for instance hate lists and trees as the only data structures out there in the functional universe. But you do gotta give the framework even this highly practical benefit of a doubt: it does force you code in a style which lets the compiler/interpreter know how your state is supposed to evolve. Even your shared states. As such, it can give you no hassles, zero-copy, UI framework integration. C, Ruby, whathaveyou, can't, because in them you're lured into not telling the interfaces or even your own compiler what they most need to know.

If you can't evolve the state of a shared element directly, there is something wrong with your language. And since there's something wrong with just about any procedural language by that token, well, I for one am once again looking pretty seriously into functional programming and its current, attendant frameworks.

Tägäyksen tasoista

Vähän aika sitten IETF julkaisi Standards Track RFC:nä jälleen yhden TLV-tyylin metaformaatin, tällä kertaa nimeltään CBOR. Tuo tuli vähän yllättäen, kun konsensus on ollut ettei mun-omia-formaatteja enää suosittaisi, ja lähestymistapa iskee niinkin lähelle ASN.1:tä. Mutta onhan tuo kaunis formaatti ja varsinkin helppo koodata. Ehkäpä sillä todella on valoisa tulevaisuus varsinkin sulautetulla puolella.

Oli miten oli, CBOR palautti minut vanhoihin mietteisiini tiedostoformaateista, ja tulipa sitten luettua jopa ASN.1-speksit pitkästä aikaa läpi. Suureksi yllätyksekseni tajusin BER:in implisiittisistä tageista ensimmäistä kertaa mistä niissä itse asiassa on kysymys. Kun tuo hämmennys on kypsynyt nyt pari viikkoa, tekee mieli sanoa muutama sana self-describing -metaformaateista ylipäänsä. Eli lähdetäänpä liikkeelle vaikkapa siitä mitä niillä oikeastaan tavoitellaan ja mitkä niiden vaihtoehdot tavallisesti ovat. Yleisesti listattuja hyötyjä ovat ainakin:

• laajennettavuus ja laajennosten yhteensopivuus
• geneeristen kirjastojen, parserityökalujen ja vastaavien mahdollisuus
• standardoinnin ja kontrolloitujen sanastojen yhteensopivuushyödyt kun laajennoksia kuitenkin tehdään
• hallitun redundanssin tuoma vikasietoisuus
• pointteriformaattien ja skippaamisen tehokkuusedut

Muuten hyvä, mutta kaikki nuo hyödyt joko ovat hieman kyseenalaisia, tai ne voisi toteuttaa helpomminkin, tai ne ovat puolitotuuksia. Ongelma näkyy parhaiten kun ajattelee yhtä kolmesta asiasta: sitä mitä parseri tarvitsee ymmärtääkseen formaatin ja mitä ei, sitä mitä kaikkea ainakin joissain tämän sortin standardeissa on voitu jättää pois ilman että ne lakkaavat palvelemasta tarkoitustaan, ja sitä mikä mahtaisi olla se sovellus jota varten tietty ominaisuus on rakennettu formaattiin sisään. Järjestyksessä, nuo syyt ovat hataria koska:

• Laajennettavuus hoituisi ihan vain versioimalla formaatti. Yhteensopivuus onnistuisi jo sillä että jokainen laajennos vain tulisi tiettyyn tunnettuun paikkaan edellisiin nähden, eli siis luultavimmin tietorakenteen perään. Niin kauan kun yksikään palasista ei luottaisi siihen että jokin tietorakenteen osa rajautuu tiedoston loppuun, parseri kyllä tietäisi mistä seuraava pala alkaa.
• Geneerisyydessä on kyllä hyötynsä eritoten debuggauksessa, mutta siihen se miltei sitten jääkin. Kirjastotasolla itse asiassa olisi usein helpompaa vain standardoida käytetyt datatyypit mutta jättää TLV-kolmikosta tyyppi ja pituus implisiittisiksi. Meinaten jos parseri on osa ohjelmaa joka tekee datalla jotain hyödyllistäkin, sen pitää joka tapauksessa ymmärtää geneerisen formaatin lisäksi myös tiedon semantiikka jota geneerisellä parserilla ei voi olla täysin hallussaan olematta jo yhdenlainen erikoistunut sovellus. Poikkeuksena tähän juuri ja juuri voisivat olla erilliset skeemakielet kuten XSchema, DFDL ja vastaavat, mutta niidenkään ontologinen anti ei ulotu yleensä läheskään riittävän syvälle että geneerinen parseri voisi kertoa paljon enemmän kuin lisätä tietorakenteeseen kentännimet ja kommentteja. Nuo hyödyt sitten toteutuvat jo sinällään esim. tekstipohjaisissa formaateissa, ja olisivat toteutettavissa täysin niinkin että geneerinen parseri lukee geneeristä kielioppia joka ei tiedä yhtikäs mitään TLV-rakenteista; vrt. ohjelmointikielten kieliopit ja parserigeneraattorit, kun eihän esim. C-sorsassa mitään TLV-rakennetta ole.
• Yhteensopivuushyödyt taas menisivät standardoimalla tyypit ja rakenteet, koodaamatta niitä itse tietomuotoonkin. Itse asiassa jos teet molemmat, yleensä tulee jossain se kulmatapaus vastaan että joudut kuitenkin laajentamaan tyyppivalikoimaa, niitä varten sisällytät koodaukseen catch-22 -palikan joka on ihan vain tyypitön tavujono, ja yhtäkkiä oikeastaan kaikki voitaisiin yhtä hyvin hoitaa ihan vain tuota kaikenkattavaa poikkeusta hyödyntäen. Tuolla argumentilla esim. ei ole mitään järkeä tyypittää mitään muuta kuin ASN.1 BER:in ylin taso, ja mennä siitä alaspäin implisiittisillä tageilla; hyvässä tyylissä ei edes niillä koska jos (miltei) kaikki on kuitenkin vain tavujonoja, (miltei jokainen) tyyppikenttä tulee hyödyttömäksi, kuten suurin osa pituuksistakin.
• Vikasietoisuuden voi toteuttaa paljon säännöllisemminkin ja tehokkaamminkin, yhdistellen virheenkorjaavia koodeja ja synkronisaatiolippuja järkevällä tavalla. TLV-rakenteet kun sinällään ovat varsin herkkiä virhebiteille, eritoten pituuskentissä.
• Datan valikoivassa lukemisessa on tietty pointtinsa, mutta itse asiassa paras tapa toteuttaa sen edut ei suinkaan ole mahdollistaa skippaus seriaalisessa datavirrassa, vaan keskitetty hakemisto josta näkyy suoraan minne pitää seekata myöhempienkin datalohkojen kohdalla. Skippauksen kuluhan kuitenkin varsinkin isoissa tiedostoissa on seek-latenssia, ei bandwidth-limittiä, jolloin hajautettujen pointteriketjujen (mitä TLV-rakenteen pituuskentät ovat; ne ovat pohjimmiltaan epätasainen skip-lista) seuraaminen aiheuttaa hakemistoon/indeksiin nähden vältettävissä olevia viiveitä.
• Jotta datan koodaukset jotka eivät ole suorastaan monimerkityksisiä, mutta näyttävät alkuun—siis vilkuilematta pidemmälle tietojonossa—siltä, voitaisiin saattaa helposti parsittaviksi, usein tekee mieli laittaa ennakoiva merkki jonoon joka vähentää lookaheadin tarvetta. Vaan todellisuudessa kaikki moiset tietomuodot voidaan myös koodata niin että tällaista tilannetta ei tule eteen, ihan vain muuttamalla tietomuodon kuvausta ja siihen liittyvän parserin rakennetta.

Todellisia argumentteja siis oikeastaan ovat vain:

• Kompositionaalisuuden edut eritoten rikkaan sisällön kanssa. Joo-o, on se parempi että softan voi jakaa pieniin erikoistuneisiin palikoihin ja geneeriseen multiplekseriin joka yhdistää ne, jotta kaiken softan ei tarvitse ymmärtää kaikkea samaan aikaan, ja palikoista voi kasata näppärästi domain-spesifisiä kokonaisuuksia. Mutkunmutkun, ne OpenDocit, COM/OLE:t ja muut eivät kyllä nekään koskaan sillä softapuolella ottaneet riittävästi tulta, eikä tuon sortin tagaus missään yleisesti käytössä olevassa container-formaatissa edellytä kuin yhden ainoan tason, syvien TLV-rakenteiden asemesta...
• Se että sattumalta käteenosuvasta esimerkistä voi oppia ilman dokumentaatiota ja sen sisäistämistä, kun osa skeemasta on työnnetty siihen väkisin sisään. Tämä on todellinen hyöty kuten HTML:n historiasta tiedetään, mutta samalla aika kova hinta siitä että pahimmillaan kymmeniä prosentteja kokonaistilasta menee toistuvasti saman rakenneinformaation kantamiseen...
• Sekä se että tietyissä rajatuissa tapauksissa tyyppipolymorfismi edellyttää valintojen eksplisiittistä tagausta. Tämä on haudanvakava juttu, mutta yllättävänkin harvinainen. Joo-o, niitä esimerkkejä on joissa vaikkapa ASN.1:n CHOICE-rakenne on välttämätön ja se pitää väkisin kääntää tägätyksi unioniksi koodauksessa. Mutta moniko oikeasti vapaaehtoisesti työntää formaattinsa yhdenkään tällaisen rakenteen, pakonkaan edessä mielellään alistaisi koko formaattinsa koneiston sille, tai törmää siihen edes 1/20 ajasta?

Eli siis oikeastaan voitaisiin ehkä jopa väittää, että kaikki ne normaalit syyt mennä TLV-formaatteihin ovat jälkikäteisoikeutusta, ja todellinen syy on ihan vain abstraktissa kauneudessa tai standardoijan hybriksessä. No kidding, ja sanon näin tyyppinä joka kärsii siitä kaikkein yleisimmästä ja hirveimmästä formaattisuunnittelupakkomielteestä.

Kun nyt sitten kuitenkin kärsin tuosta taudista, mikähän tästä kamaluudesta olisi ehkä sittenkin pelastettavissa, missä tilanteessa, ja miksi? Onko sittenkin jokin sovellus, syy tai arkkitehtuuri jossa jonkinlainen TLV-ajattelu on aidosti oikeutettua? Jos on, minkälainen muoto sen pitäisi ottaa selvitäkseen ylläolevasta kritiikistä? Vihjaako tuo jotain laajempaakin sellaisen formaatin vaatimista asioista, eli siis lisäyksiä koodausmalliin?

Muutamia ennakkoehtoja nähtävästi ainakin olisivat:

• Koodatun tiedon pitää palvella useita eri tarkoituksia samaan aikaan. Jos näin ei ole, kiinteä parseri ratkaisisi jo ongelman täysin. Container-formaatit ovat tästä yksi esimerkki, kun niidenhän on tarkoitus ratkaista se yleisempi ongelma joka liittyy synkronisoituun multimediaan yli tietyn yksittäisen sovelluksen. Ne ratkaisevat pohjimmiltaan arvaamattomien tietojen multipleksauksen yhteen datavirtaan, ajassa.

  Tämä kohta myös vihjailisi, että formaatin pitäisi kenties ratkaista hieman yleisempiäkin ongelmia kuin vain tuo aika, jos se ei halua keksiä container-pyörää uusiksi.

• Sovelluksen pitää olla sellainen että tieto voitaisiin järjestää eri tavalla tai sen tarkka alajoukko valita toisin hyvästä syystä ja riippumattomasti alkuperäisestä sovelluskehittäjästä. Tästä ehkä parhaana esimerkkinä ovat relaatiotietokantojen käyttämät levyformaatit: kyseisen mallin pyrkimys loogisen ja fyysisen datamallin eroon vaatii, että data on uudelleenjärjestettävissä ilman että se menettää merkitystään, jolloin käytännössä kaikesta mitä levyllä näkyy tulee unioneita, ja rakenteet on pakko tagata eksplisiittisesti jotta tiedettäisiin missä järjestyksessä-muodossa ne kulloinkin ovat.

  Tämä kohta kuitenkin viittaa myös, että moni tuon looginen–fyysinen -eron ongelmista pitäisi ratkaista koodauksen sisällä, ja sitähän ei tee kunnolla edes itse relaatiomalli. Se vihjaa myös sellaisia paljon vaikeampia kysymyksiä kuin että kuinka pitkälle koodausmetologian oikeastaan pitäisi sanella yksittäistä koodausta, mitkä ne mahdolliset ratkaistavat ongelmat kokonaisuudessaan olisivat, miten tuoda framework-kehitys mukaan tietomalliin esim. käyttötapauksina, missä menevät ennustettavan rajat vaikkapa tiedon- vs. tietämyksen esityksessä, kuinka vahvoja parserimalleja yleensä voidaan käyttää (Turing-täydellisyyshän ainakin tarkoittaisi että ympätään sovellus mukaan dataan...), jne, ad nauseam...

• Jos halutaan aina väkisin opettaa esimerkistä, miksei sitten mennä tekstipohjaisella formaatilla ja kompressiolla? Tai ainakin jos mennään formaalimmalla skeemalla, halutaanko se nyt kuitenkaan ympätä datan sekaan vai olisiko parempi erottaa se? Ja jos se erotetaan, no eikö sitten pitäisi katsoa onko niin tehty jo vaikka RDF:ssä, ProtocolBuffereissa, DFDL:ssä ja muissa paremmin? Mitä lisäarvoa me nyt oikein haetaan tällä kaikella?

Niinpä olen itse vähitellen taipunut siihen suuntaan, että mennääs takaisin fundamentteihin ja yritetään ratkaista se kaikkein isoin ja yleisin ongelma kerralla, joskin tietty pala palalta. Hyvä lähtökohta tuolle nähdäkseni olisi relaatiomalli, johon sitten yhdistettynä ainakin huolella harkittu loogis-semanttinen tietomalli à la RM/T ja RDF, erotetut skeemat jotka kulkevat datan mukana, tai siis itse asiassa voidaan korvata myös yksikäsitteisillä viitteillä online-skeemoihin, nimiavaruushallinta osana tuota, kohtuullisen laaja kirjo perusdatamalleja ja käyttötapauksia joita koodaus tukee—esim. mikään geneerinen koodaushan ei nyt tue kunnolla yleisiä graafeja—järkevät tyyppi- ja koodausontologiat niin että automaattinen prosessointi tulee mahdolliseksi ylätyyppien tasolla vaarantamatta ilmaisutarkkuutta, ja niin edelleen, virheenkorjaukset, hakemistomekanismit, deltakoodaukset ja vastaavat toteutettuna yleistasolla, ja niin edelleen. Kuitenkin muodossa joka sallii aina lyhentämisen ja pakkauksen myös.

Toisin sanoen, tehdään se kerralla kunnolla ja koodataan se myös niin ettei kenelläkään taatusti ole valittamista tietomalli- kuin ohjelmistotuestakaan, toisin kuin nyt. Tuollainen geneerinen dataformaatti olisi hyvin eri näköinen kokonaisuudessaan kuin nykyiset yritelmät, ja aivan saatanallisen paljon laajempi kokonaisuus kuin mikään mitä edes mikkihiireläiset ovat koskaan yrittäneet. Tuntuvasti häijympi kokonaissysteemi valmistuttuaan kuin edes CORBA Persistence.

Mutta mikään mahdottomuus se ei olisi, jos hommaa vain jaksaa ajatella tarpeeksi pitkään—sen parikytävuotta ainakin mitä minä jo, tai ehkä tuplasti sen. Tai ainakin jaksan edelleen uskoa niin.