APL viestimenä

Erkki Juvonen

"Vaikka minä puhuisin ihmisten ja enkelien kielillä, mutta minulta puuttuisi rakkaus, olisin vain kumiseva vaski tai helisevä symbaali." (Kor. 13:1)

Tämän viisauden on lähes 2000 vuotta sitten kirjoittanut Paavali kirjeessään korinttolaisille, kreikan kielellä, ja Raamattu-nimisen kokoomateoksen toimittajat olivat nähneet sen niin hyväksi, että ottivat sen mukaan teokseensa.

Itse asiassa korinttolaiskirjeen 13. luku on eräs parhaimpia viestinnän oppaita, mitä on olemassa, nykyisin kai sanottaisiin "Communication for Dummies". Useimmat meistä tuntevat tämän suositun tekstin, mutta kuinka moni on ajatellut sitä tältä kannalta. On paradoksaalista, että suomentajat, alan parhaat asiantuntijat, jotka ilmeisesti ovat myös käyttäneet parhaita ja täydellisimpiä sanakirjoja, ovat tehneet sen nykypäivän ihmiselle ja viestijälle (mitä me kaikki olemme jokapäiväisessä elämässämme) jotakuinkin käsittämättömäksi käyttämällä sanaa rakkaus, joka ei tyypillisesti kuulu viestinnän sanastoon. Vasket ja symbaalit myöskin lienevät useimmille meistä aika outoja olioita.

Tietokoneen ohjelmointi on viestintää. Jollakulla on ongelma tai tehtävä, jonka suorittamiseen hän pyytää apua asiantuntijalta. Tällä on melkein poikkeuksetta työkalunaan tietokone, jonka hyväksikäyttämiseen tarvitaan ohjelmia. Niiden tekemiseen tarvitaan ohjelmoijaa, olkoon hänen ammattinimikkeensä mikä tahansa. Viesti kulkee ratkaisun kehittäneeltä asiantuntijalta ohjelmoijan tai ohjelmoinnin kautta ratkaisun tai tehtävänsuorituksen tilanneelle henkilölle. Koko viestintätapahtuman onnistumisen mittana on, kuinka hyvin ratkaisu menee perille, kuinka hyvin loppukäyttäjää palvellaan, kuinka helposti ja virheettömästi hän pystyy saamaan vastauksia kysymyksiinsä ja pystyy tehtävänsä suorittamaan. Nämä asiat meidän on koko prosessin ajan pidettävä mielessä, meidän on välitettävä siitä ketjun viimeisestä lenkistä, ihmisestä, tai jos haluatte sanoa rakastettava häntä, niin siitä vaan, se tarkoittaa tässä yhteydessä aivan samaa.

Viestinnän kolme tärkeää peruselementtiä ovat:

• kenelle viestimme, eli kohde tai kohderyhmä,
• mitä viestimme. siis viestin sisältö eli substanssi, ja
• miten viestimme, viestintätapa, tyyli, muoto, kieli.

Tärkeysjärjestys on nimenomaan tämä. Palaan vielä ensimmäiseen kohtaan. Paavali sanoi että ellei meillä ole rakkautta, eli jollemme välitä viestinsaajasta, jollemme pidä häntä koko ajan mielessä, niin tulos on pelkkää sanahelinää, tehtävä ei onnistu. Olkoon meillä miten hienoja ratkaisuideoita tahansa, ja miten tyylikkäästi ja värikkäästi me ne esitämmekin, mutta jos käyttäjä ei tunne saavansa sitä mitä hän tarvitsee, niin tulos on yhtä tyhjän kanssa, paljon porua ja vähän villoja.

Viestintätapahtumaa täydentää parhaassa tapauksessa vielä eräs elementti, nimittäin palaute. Palaute on viestin lähettäjälle hyvin tärkeä ja opettavainen tieto siitä menikö sanoma perille ja menikö se perille oikein, ymmärsikö saaja lähettäjän tarkoituksen. Liian paljon tapahtuu tänäkin päivänä sellaista, että opettaja opettaa ja oppilaat ymmärtävät kaiken aivan väärin, jos ollenkaan, eivätkä uskalla kysyä, tai ohjelmoija vääntää koodia ja käyttäjä tuskailee ongelmien kanssa, kun hän ei saa tarvitsemiaan tuloksia. Yleensä hän syyttää "konetta" : "tälle ei nyt voi mitään, kun tämä on tietokoneella". Seuraavaksi kehittyneempi versio tästä ongelmasta on syyllisyyden- tai alemmuudentunne, ajatus että "en hallitse työtäni". Syy on kuitenkin taitamattomissa ohjelmoijissa, jotka eivät ole kertaakaan ajatelleet asiaa käyttäjän kannalta. Mutta eihän "asiantuntijoissa" voi olla mitään vikaa, hehän parhaiten hallitsevat tehtävän. Eikä heissä välttämättä olekaan muuta vikaa kuin että he puhuvat ja kirjoittavat tietokoneelle, eivät loppukäyttäjälle, ihmiselle. Ero on sama kuin kahdella linja-autonkuljettajalla. Toinen kaasuttelee dieselmoottoria, toinen vie ihmisiä maalle mummolaan.

APL-kieli on viestintämielessä eräs parhaimpia. Sen funktiot ovat makrotasoisia, lähellä inhimillistä ajattelutasoa, joten ajatuksenkulkua ei tarvitse pirstoa aivan biteiksi. Ainakin jos ohjelmat halutaan tehdä helposti ymmärrettäviksi ja dokumentoidaan riittävän hyvin, päästään helposti seurattaviin ajatuskulkuihin. Olen aina opettanut, että ohjelmamodulin, funktion, ei pitäisi koskaan olla pitempi kuin mikä mahtuu kerralla näyttöruudulle, siis alle 25 riviä. Milloin tarvitaan enemmän koodia, pilkotaan se sopivan kokoisiksi aliohjelmiksi. Kun sitten jokaisen funktion alkuun laitetaan pari kommenttiriviä, joissa kerrotaan, mitä modulissa tehdään, pystyy kuka tahansa APL-lukutaidotonkin seuraamaan logiikkaa, kun se hänelle selitetään. On oikeaa psykologiaa, oikeaa välittämistä, kun käyttäjälle (tilaajalle, esimiehelle) selitetään ymmärrettävällä tavalla ratkaisun logiikka ja ohjelman hienoudet. Viesti menee perille, syntyy yhteisymmärrys- ja luottamussuhde ja kaiken lisäksi varsinainen työ sujuu niinkuin sen pitääkin.

APL:n toinen suuri etu on sen interaktiivisuus, myöskin ja erikoisesti henkilötasolla siten, että ohjelmoija voi rakentaa ohjelmaa yhteistoiminnassa käyttäjän kanssa. Käyttäjän palautteeseen ohjelmoija voi reagoida välittömästi ja hioa sovellusta käyttäjän mieleiseksi. APL:n tehokkuus piilee juuri tässä ominaisuudessa. Toimiva ohjelma syntyy ennätysajassa, ja mikä parasta, se on tulevan käyttäjän jo alustavasti testaamaakin.

APL:n pioneeriaikana 70-luvulla meillä oli Suomessa, ainakin IBM:ssä, sellaisia myyntihenkilöitä ja ohjelmoijia, jotka todella osasivat hoitaa asiakassuhteita. He välittivät asiakkaista ja loivat innostuksen ja luottamuksen ilmapiirin. Mieleeni tulee ennen muita Timo Seppälä, jonka jalanjäljissä kasvoi APL-käyttäjiä kuin sieniä sateella. Suomi oli yhteen aikaan APL-levinneisyyden ykkösmaa maailmassa, eniten käyttäjiä asukaslukuun nähden. Aivan sattumalta minäkin jouduin edistämään APL:n leviämistä, vaikka se ei silloin kuulunut toimenkuvaani. Näin se tapahtui.

Vuonna 1976 joulukuun alussa, olin eräänä perjantai-iltana tulossa Kööpenhaminasta. Lentokoneessa viereeni istahti IBM:n henkilöstöosaston tutkija-analyytikko, psykologi Rauno Matikainen. Hän siinä valitteli, että vanha totuus "suutarin lapsilla ei ole kenkiä" pätee yhä: tietokonefirmassa ollaan, mutta ei niistä koneista ole henkilöstöhallinnossa mitään hyötyä. Toki ohjelmia voidaan teettää ja niitä ajaa, mutta tuloslistat ovat lähinnä jotain tilastoja, nekin puoli vuotta myöhässä. Silloin kun operatiivista tai suunnittelutietoa tarvitaan, se on kerättävä kovalla työllä ja laskettava pöytälaskimella. Sanoin hänelle: teillä on väärät välineet, kyllä esimerkiksi APL:llä voisitte itse saada juuri sellaista tietoa kuin tarvitsette. Minäpä näytän, mitä sillä on saatavissa aikaan.

Maanantaipäivän käytin esimerkkihenkilörekisterin luomiseen. Yhtiön sisäisestä puhelinluettelosta otin 600 nimeä, sekoitin etu- ja sukunimet, annoin henkilöille kaikenlaisia ominaisuuksia, sukupuoli, ikä, palvelukseen tuloaika, keksitty osastokoodi, tehtävä, koulutus ja kielitaito, perhesuhteet, palkkakehitys muutamalta vuodelta. Kaikki tiedot järjestin taulukon muotoon ja talletin sarakkeittain AFILEen. Tein parikymmentä yksirivistä funktiota, joilla voitiin poimia tietoja ja suorittaa yksinkertaisia laskutehtäviä, kuten taulukkolaskimissa. Tiistaiaamuna kutsuin Raunon demoon. Yhdessä muotoilimme selvällä suomenkielellä kysymyksiä kuten:

• MONELLAKO TEKN_OS HENKILOLLA ON S360 JA RUOTSI > 2
• KAIKKI TIEDOT EDELLISISTA
• KESKIARVO PALKAT OSASTOITTAIN
• PLOT PALKAT VS PALVELUSAIKA
• (KESKIARVO MIESTEN PALKAT) - KESKIARVO NAISTEN PALKAT

Kolleega oli aivan innoissaan: voiko tämä olla näin helppoa ! Eihän tässä tarvita muuta kuin todellista dataa. Pari viikkoa tarvittiin, että henkilörekisterin oleellisista tiedoista saatiin lupa tehdä kryptattu AFILE kopio. Kaikkiin tiedoston luku- ja kirjoitusfunktioihin tehtiin salakirjoitus tullen mennen. Sitten jouluaaton aattona kutsuttiin demoon kaikki ne henkilöstöosaston henkilöt, jotka näitä tietoja joutuvat käsittelemään. Innostus ja ihastus oli suuri. Eräs heistä pyysi tekemään vähän tavallista konstikkamman kyselyn. Kun vastaus tuli "alta aikayksikön", hän oli suorastaan vihainen sanoen: "Oikein! - ja minä kun jouduin tekemään töitä melkein kaksi yötä saadakseni nuo tulokset. Miksi meille ei ole kerrottu tästä aikaisemmin ?". Se oli heidän paras joululahjansa.

Tieto tästä välineestä levisi aika nopeasti toisten firmojen henkilöstöosastoille. Jouduin esittämään demoani eri tilaisuuksissa, ja minua pidettiin suorastaan henkilöstöasioiden guruna. Varmuudella toistakymmentä firmaa otti APL:n käyttöön nimenomaan henkilöstöosaston vaatimuksesta.

Aivan samanlaisella sovelluksella saatiin pääkaupunkiseudun kunnallispoliitikot, päätöksentekijät, APL:n ja yleensä tietotekniikan innostuneiksi kannattajiksi, kun he saivat käyttää APL:ää Lauttasaaren kaupunginosan asemakaavasuunnitteluun pelissä, jonka pohjana olivat todelliset kiinteistö- ja asukastiedot. Tämä tilaisuus oli järjestetty PTK:n (nykyisen KT-Tietokeskuksen) seminaarin yhteyteen Lidingön koulutuskeskuksessa Ruotsissa. Arvon herroja ja naisia ei saatu päätteiden äärestä pois ennenkuin aamun sarastaessa. PTK:n omat asiantuntijat opettelivat parissa päivässä tämän sovelluksen kehittelyä varten tarvittavan APL-taidon.

Otin tähän esitykseen nämä esimerkit, jotka mielestäni selvästi havainnollistavat APL:n ainutlaatuisuutta usealta eri kannalta. Erittäin notkea, ylivoimaisen nopea ja tehokas sovellus, olkoonkin että vain demo, tehtiin päivän-parin toimitusajalla. Sovellus käytti vain yhtä ainoaa tietokoneohjelmaa, APL-tulkkia. Ohjelmakoodia, sataprosenttisen puhdasta APL:ää tarvittiin vähemmän kuin sata riviä. Nuo selväkieliset kyselyt olivat aivan puhtaita APL-lauseita, jotka rakentuivat APL-funktionimistä ja tietomuuttujien nimistä. Käyttäjät, jotka eivät tunteneet mitään muuta ohjelmointikieltä, ymmärsivät niiden merkityksen ja käytön oitis. He eivät tunteneet teknostressiä tai tietokonepaniikkia, vaikka olivat ensimmäistä kertaa päätteen ääressä. Jokainen huomasi: minähän osaan käyttää tietokonetta omiin tehtäviini. He olivat spontaanisti sitä mieltä, että tietokone on hyödyllinen väline. He tunsivat, että heistä välitettiin, että tämä oli tehty juuri heitä varten.

Noista ajoista on kulunut parikymmentä vuotta. Kun nyt katselen "APL-uutisten" juttuja ja seminaariohjelmia, joudun kysymään, mihin APL on piilotettu. APL-ohjelmoijan pitää osata Windowsia, olio-ohjelmointia, grafiikkaa, tietokantaohjelmointia, taulukkolaskentaa. Monet muka APL-ohjelmat sisältävät sivukaupalla kutsuja näihin palveluihin. APL on lähinnä vain kehikko, johon nuo kutsut sijoitetaan, ja ohjelma toimii alijärjestelmiensä ehdoilla. Vai onko APL-ohjelma ollenkaan pääohjelma ? Tuleeko ohjelmista parempia, selkeämpiä, helpommin hallittavia, käyttäjäystävällisempiä ? En sano tehokkaampia, sillä se ei käsittääkseni ole maailman tärkein asia, raakaa tehoa saa halvalla, ohjelmoijan työ ja laatu ovat arvokkaita.

APL-koodia voidaan tehdä monella tavalla, BASIC-kielen syntaksilla, spagettikulhotyylillä, mistä ei hevillä löydy alku- enempää kuin loppukohtaakaan, taikatempunomaisesti ratkaisemalla viisi tehtävää yhdellä rivillä, tai sitten selkeää ja luettavaa. Sanotaan, että kukin taaplaa tyylillään. Ohjelmoija saakoon siitä tyydytyksensä. Joku toinen joutuu sitä koodia joskus ylläpitämään. Jos koodi on tarpeeksi kryptistä, se kenties menee roskikseen, ja tilalle tehdään uusi moduuli uudella tyylillä, mutta karavaani kulkee.

Käsittääkseni APL-koodi on säilynyt varsin hyvin ns. ylöspäin yhteensopivana. 25 vuotta sitten APL\360:lle tehty tähtikarttaohjelma STARMAP latautui vuonna -74 helposti APL/CMS:lle, jolloin se oli konttoritekniikan näyttelyn vetonaulana. Vielä pari vuotta sitten kokeilin sitä APL2/OS2:lla ja sehän toimi. Tulostus vain piti muuttaa pallopääprintteriltä GRAPHPAKille. Ja sitä ennen oli asennettava OS2/Warp ja se taas vaati kasvattamaan mikroni muistikoon kahdeksaan megaan. Alunperin ohjelma oli toiminut 64 k:n muistissa. Silloin tähtikartan tulostaminen kesti viisi minuuttia, nyt se tapahtuu alle sekunnissa, mikä käy jo animaationa. STARMAP on tietenkin vain museotavaraa. Nyt on shareware kirjastoista saatavissa paljon näyttävämpiä, helppokäyttöisempiä ja monipuolisempia tähtikarttaohjelmia. Miten pitkäikäisiä mahtavat olla nämä tänä päivänä tehdyt usean toimittajan lisukkeilla varustetut ohjelmat, kun jokaisen osasen versiot vaihtuvat muutaman kuukauden välein ?

Tässä esityksessä pyrin kertomaan APL:n erinomaisuudesta viestimenä, ideoiden välittäjänä asiantuntijalta käyttäjälle. En halua yrittää opettaa kenellekään joitakin simsalabim-kikkoja. Ohjelmoijat tuntevat niitä tarpeeksi. Silloin kun todella tarvitaan äärimmäisiä virityksiä, niitä löytyy muun muassa idiomiluetteloista. Ilmankin on kyllä tultu hyvin toimeen. Ollessani Pariisissa IBM:n Euroopan pääkonttorin APL-konsulttina ja noin 200 APL-ohjelmoijan, tai ainakin jonkinlaisen APL-ohjelmoijan kouluttajana, sain nähdä noin 200 eri ohjelmointityyliä. Yritin ohjata heitä uusien APL2-ilmaisujen ihmeelliseen maailmaan. Seurauksena oli lähinnä turhautumista. Lopulta kysyin itseltäni: miksi heidän pitäisi muuttaa tyyliään, kun he kerran pystyvät tekemään homman aivan hyvin niinkuin ovat sen siihenkin asti tottuneet tekemään. Olin jo oppinut hiukan heidän ranskalaista elämäntapaansa.

Aivankuin sähköinsinöörille riittää noin 90-prosenttisesti Ohmin laki, riittää APL-ohjelmoijalle pienten moduulien laki: max 25 riviä. If you like bells and whistles, go ahead, eli jos kumiseva vaski ja helisevät symbaalit tuntuvat mukavilta ja edistävät asioita, niin mikä ettei, mutta älkää unohtako pääasiaa, kenelle ohjelmanne on tarkoitettu.

Nuori 17-vuotias lupaava kapellimestari Mikko Franck
"Huomenta Suomi"-lähetyksessä 28.1.1997:
Hyvällä kapellimestarilla täytyy olla tiettyjä psykologisia taitoja,
kykyä käsitellä orkesteria ja hänellä pitää olla vahva sisäinen halu tehdä musiikkia ja tehdä sitä muiden ihmisten kanssa - muille ihmisille.

Vanhan menestyneen APL-ohjelmoijan ja -markkinoijan näkemys:
Hyvällä APL-ohjelmoijalla täytyy olla tiettyjä psykologisia taitoja,
kykyä käsitellä välinettään ja kommunikoida käyttäjän kanssa ja
hänellä pitää olla vahva sisäinen halu tehdä hyviä ohjelmia ja tehdä niitä muiden ihmisten kanssa - muille ihmisille.