Ohjelmoijan onni on elää komentorivillä. Tehokkaiden käyttöliittymien rustaaminen on varsin nopeata, kunhan luottaa siihen, että suurta suosiota tuotokset eivät tule nauttimaan. Olen saattanut tarinoida samasta aiheesta aiemminkin, mutta kertaus tekee hyvää.

Lyhyet ohjelmat komentoriviargumentein

Komentoriviargumentit rokkaavat. Valmiita kirjastoja ja ohjelmia on tarvittava määrä kullekin kielelle, joten käytettävyyden kanssa ei tarvitse kärvistellä. Pythonille on vaka vanha argparse ja C:lle ja bashille löytyy aina tarvittaessa esiinkaivettava getopt-kirjasto.

Komentoriviargumentit ja eräajoluonteinen suoritus on Unix-filosofian kulmakiviä. Jokaisesta ohjelmasta tulisi löytyä tärkeimmät ohjattavat asiat komentorivilippujen kautta, ja itseään kunnioittavista projekteista kaikkea tulisi voida ohjata komentoriviltä. Yhdisteltävyyden ja uudelleenkäytettävyyden kunniaksi!

Lisätehoa saa helposti, kun miettii hyvät oletukset komentoriviohjelmille. Esimerkiksi mitä laitetaan tapahtumaan, jos ohjelmaa kutsutaan argumenteitta. Säästyneiden näppäilyjen lukumäärä on suoraan verrannollinen ohjelman tarjoamaan tyydytykseen: enemmän vähemmällä. Jos sovellus sisältää interaktiivisen osion, se yleensä paiskataan tulille siinä vaiheessa. Jotain nondesktrutiivista kuitenkin on hyvä olla. Omassa moary -projektissani painin hieman argparsen kanssa saadakseni jotain fiksua oletusta ruutuun. Alikomennot eivät vain tue mokomat vielä oletuksia.

Viimeisen silauksen komentoriviasetukset saavat, kun näkisi vaivaa opiskellakseen bashin ja zsh:n täydennysfunktioiden kirjoittamista. Mikäs sen mukavampaa kuin saada alikomennot tabitäydennyksellä ruudulle.

Interaktiivisuus editorin voimin

Kun sovellus syystä tai toisesta edellyttää interaktiivisuutta, ei ensimmäisenä todellakaan kannata rynnätä ncursesin tai, pahempaa, graafisten käyttöliittymäkirjastojen pariin. Jos homman ideana on vaikka tallennella tekstimuotoista dataa tai käsitellä sellaista, kannattaa tutkia vakavasti editorien voimaa. Jos tekstiä pitää vähänkin editoida, on pyörää turha keksiä uudelleen. Laitetaan oikeat editorit vuosikymmenien kokemuksella asialle.

Kuvassa blog-skriptini, joka kutsuu $editoria (eli vimiä tapauksessani) viestin kirjoittamiseksi. Tällä kaavalla olen tehnyt useita tyydyttävästi toimivia ohjelmia:

1. Kysy mahdolliset alkujutut komentoriviargumenteilla
2. Luo tyhjä temppitiedosto
3. Kirjoita sinne jonkinlainen alkupohja
4. Avaa $EDITOR siihen tiedostoon ja odota sen sulkemista
5. Parsi temppitiedoston data ja järsi siitä eteenpäin

Tämä pohja tuli tutuksi alkuaikoina esimerkiksi svn:n ja git:n commit-rutiineista. Toiminnan filosofia on ymmärtääkseni Emacs-skriptien perinteisessä tavassa toteuttaa toimintoja. Esimerkiksi emacsin email-toiminto avaa uuden bufferin To- ja Subject-kentillä, sekä erottimen jälkeen kirjoitettavalla viestillä. Viesti kirjoitetaan käyttäen tavallisia tekstityökaluja ja sitten annetaan skriptin jauhaa. Tässä ideassa on paljon potentiaalia.

Kokoruudun editoreissa on sitä tarvittavaa interaktiota pieniin tarpeisiin, ja joskus suuriinkin. Näihin kahteen pääeditoriin on helppoa kirjoitella omia näppäinkomentoja ja skriptejä tehostamaan aihepiirin käsittelyä. Teemaan liittyvät sanatäydennykset, tarvittaessa sopiva syntaksivärjäys automaattisesti päälle. Editori tekee pienellä vaivalla aika suuren osan. Komentorivihakkerin editorit ovat muutenkin selkäytimessä, joten on aika selvää opittavuudenkin suhteen valita tämä lähestymistapa.

Joskus kannattaa mennä niin pitkälle, että ottaa kokonaan alustakseen editorin, eli tavallaan komentorivitön ohjelma. Olen kirjoittanut Summerin, joka käytännössä “tähtää” Vimin päälle. Enkä tekisi sitä millään muulla tavalla. Laiskuudesta johtuen se sattuu toimimaan myös komentorivillä tietovirtojen saattelemana.

Graafiset ohjelmat

No. Olen aina hokenut, että komentoriviargumenttien käsittely on rutkasti helpompaa kuin vastaavan, yhtä viimeistellyn näköisen graafisen softan vääntäminen. Toki, jos vääntö tehdään tekstieditorilla alusta alkaen. Maailmalla on kuitenkin työkaluja, joilla graafisen rungon saa aikaiseksi varsin nopsaan, ja valmiit koodipohjat (vaikkapa) Pythonille tulostuvat napin painalluksella.

WxGlade on yksi työkalu, jolla olen jopa kirjoittanut nopean klikkailuhässäkän. Sopivien näppäinyhdistelmien kytkeminen valikkotoimintoihin on sen verran nopeaa, että puhtaassa nopeudessa varmasti ollaan lähellä esimerkiksi argparsen kirjainflagien täyttämistä. Yhdistettynä siihen, että graafiset työkalut pohjaavat callback-kutsuihin tai muihin reaktiivisiin menetelmiin, voisi sanoa, että tilanne on yllättävän tasoissa.

Silti pitää sanoa, että vaikka graafiset käyttöliittymät syntyvätkin vaivatta, niin tehokkaat graafiset käyttöliittymät vaativat hieman enemmän. Ja niihin ei voi kytkeä $EDITOR:ia aivan noin vain. Qt-ohjelmiin saa Katen monipuolisen tekstieditorikomponentin, mutta se siitä.

Ja siihen graafiseen käyttöliittymään pitää silti kirjoitella se komentorivipuoli, jos yhtään haluaa esiintyä vakavana Nix-koodaajana.