Nors iki kvantinių kompiuterių ir jų keliamos grėsmės mūsų civilizacijai dar (tikėkimės) toloka, bet ir įprastų kompiuterių programos jau yra už žmogiškojo supratimo ribų. Tai labai pavojinga ir ne ateityje, o dabar.
Nors iki kvantinių kompiuterių ir jų keliamos grėsmės mūsų civilizacijai dar (tikėkimės) toloka, bet ir įprastų kompiuterių programos jau yra už žmogiškojo supratimo ribų. Tai labai pavojinga ir ne ateityje, o dabar.
Vienoje „Kieto riešutėlio“ dalyje įvyksta skaitmeninė apokalipsė. Hakeriai užvaldo viską, ką vyriausybė valdo kompiuteriais, – šviesoforus, vaizdo stebėjimo, elektros tiekimo sistemas, socialinio draudimo sąskaitas ir taip toliau; kyla daug aukų pareikalaujantis chaosas. Šis scenarijus ne taip toli nuo tikrovės, kaip norėtųsi: rugsėjo 28 dieną „techninis sutrikimas“ sulaikė reisus vien metu visame pasaulyje – Australijoje, Japonijoje, Europoje, JAV. To priežastis – elektroninės sistemos, kuria naudojasi aviacijos kompanijos ir oro uostai keleivių ir bagažo registravimui, sutrikimas. Laimei, gedimas buvo greitai pašalintas, tačiau jo pasekmės galėjo būti tragiškos.
2014 metais, naktį iš birželio 10-os į 11-tą, visa JAV šiaurės vakaruose esanti Vašingtono valstija 6 valandoms liko be gelbėjimo tarnybos 911. Visi skambinusieji ragelyje girdėjo trumpus signalus. Viena moteris, norėjusi iškviesti policiją, nes į jos namus įsibrovė plėšikas, tarnybos telefono numerį rinko 37 kartus ir, nesulaukusi atsakymo, griebėsi peilio savigynai; plėšikas pabėgo. Kaip vėliau paaiškėjo, sutrikimas įvyko, nes vienas iš serverių, per kurį priimami skambučiai, buvo užprogramuotas taip, kad nepriimtų daugiau nei kelių milijonų skambučių. Kai ši riba buvo viršyta, skambučiai tiesiog buvo nebepriimami. Tik ryte programuotojai perprato problemą ir kad jos pašalinimui tereikėjo pakeisti vieną skaičių.
Dar neseniai kritiškai svarbios sistemos būdavo kontroliuojamos mechaniškai, arba dalyvaujant žmogui ir nuolat buvo tikrinamos, kad būtų išsiaiškinti nesklandumai. Dabar jos priklauso nuo kompiuterių, o šie – nuo konkretiems tikslams parašytos programos. Jei elektromechaninio įrenginio aprašymas užėmė kelis puslapius, tai su programomis taip paprastai išsisukti nepavyks: kodas gali užimti dešimtis ir šimtus milijonų eilučių. Pakeitimas programoje daryti nesudėtinga ir nebrangu, todėl jos nuolat keičiamos – pridedamos naujos eilutės, naujos funkcijos, naujos galimybės. Toks lankstumas ne tik palaima, bet ir prakeiksmas, rašo žurnalistas ir programuotojas Jamesas Somersas straipsnyje „Atlantic“. Kai kurių specialistų nuomone, mums būtina pakeisti programavimą – ir atlikti tai kuo greičiau, kol neištiko katastrofa.
Žmogaus sukurtų sistemų sudėtingumas viršijo jo valdymo galimybes ir nemaloniausia, kad programinė įranga nelūžta – ji veikia būtent taip, kaip jai nurodoma. Problemos kyla, kai įsakymas neteisingas. Kitaip tariant, programos klaidos yra žmogaus supratimo ar vaizduotės klaidos, tikina Somersas.
Programinis kodas pernelyg sudėtingas, kad jį būtų galima įsivaizduoti, pernelyg „svetimas“ žmogaus supratimui. Anksčiau galėjome matyti, kaip aplink mus keičiasi pasaulis, – kaip keliai pasidengia asfaltu, kaip stiebiasi daugiaaukščiai namai. Dabar, kai kas nors keičiasi, mes to nebepastebime, – pokyčiai randasi, į programinį kodą pridedant eilutes. Spaudžiame automobilio akceleratoriaus pedalą ir jis greitėja, tačiau tarp šių dviejų įvykių nėra tiesioginio mechaninio ryšio – viskas vyksta, tarpininkaujant kompiuteriui, kuris nusprendžia, kiek oro paduoti varikliui. Ir tai jau gali būti išties pavojinga.
2007 metų rugsėjį amerikietė Jean Bookout važiavo greitkeliu savo „Toyota Camry“, kai greičio ir stabdžių pedalai nustojo reaguoti į jos veiksmus. Automobiliui važiuojant 80 km/h greičiu, moteris pabandė įjungti rankinį stabdį, tačiau tai nepadėjo ir automobilis, palikęs kelių dešimtis metrų slydimo žymę, rėžėsi į šalikelėje supiltą sankasą. Keleivis žuvo, pati Bookout mėnesį pragulėjo ligoninėje be sąmonės. Dešimt mėnesių trukęs NASA IT specialistų tyrimas gedimo priežasčių neišaiškino, ir tik dar po pusantrų metų kita ekspertų komanda mašinos kompiuteryje atkapstė kodą, kuris buvo toks supainiotas, kad dėl menkiausio atminties sutrikimo automobilis galėjo tapti nevaldomas. Praėjus šešiems metams po avarijos, „Toyota“ buvo pripažinta kalta, ir teismas įpareigojo korporaciją nukentėjusiai moteriai išmokėti 3 mln. dolerių. Vėliau gamintojas turėjo atšaukti 9 mln. automobilių.
Tai tik vienas iš sutrikimų pavyzdžių, o sudėtingėjant programoms, jų vis daugės, perspėja Somersas. Šiuolaikiniuose automobiliuose yra 100 mln. kodo eilučių ir jeigu nesugalvosime, kaip tai supaprastinti, gero nelauk.
Programuotojo darbas nuo praėjusio amžiaus devintojo dešimtmečio menkai pasikeitė: norint kurti programą ar ją pakeisti, reikia rašyti tekstą. Dabar daugelis kalba, kad toks status quo nebeatitinka realijų. Kompiuterių galingumas štai ja 40 metų auga geometrine progresija. Kodėl programavimas turėtų likti toks pats?
Vienas iš bandančių sugalvoti, kaip „išgydyti“ programavimą, – IT tyrinėtojas Bret Victor. 2007–2011 metais jis buvo vartotojo sąsajos programuotojas „Apple“ kompanijoje, o dabar vadovauja „Human Advancement Research Community“ (HARC) organizacijos laboratorijai, tyrinėjаnčiai programavimo ateitį. Viktoras plačiai pagarsėjo siauruose sluoksniuose 2012 metais, po pranešimo studentams programuotojams viename Monrealio viešbutyje. Toje lekcijoje jis papasakojo apie savo suvoktą principą: „Ką nors kuriantis privalo būti tiesiogiai susijęs su tuo, ką jis kuria“. Programavimas akivaizdžiai šį principą pažeidžia, paskelbė Viktoras: programuotojas, įsipainiojęs į kodo eilutes, yra atplėštas nuo realaus savo darbo rezultato. Kuriantis, tarkime, skirtingus stilius teksto redaktoriui, neišvys, ką jis sukūrė, kol nepamatys spausdintuvu atspausdinto teksto. Negalėdamas numatyti, koks bus tekstas, programuotojui tenka įsivaizduoti, kaip jo kodą supras kompiuteris, tai yra, pačiam mintyse būti kompiuteriu.
Siekiant išspręsti šią problemą, buvo sukurtos WYSIWYG (angl. What You See Is What You Get – „Ką matai, tą ir gausi“) technologijos, kurios esamuoju laiku rodo programuotojui, kaip galiausiai atrodys jo pastangų vaisius. Taip galima buvo vos metus žvilgsnį, suprasti, ar kur nepadaryta klaida, – ir tai galėjo atlikti visi. Viktoro nuomone, panašiai turėtų veikti visas programavimas: automobilių autopilotus ar ligų diagnozavimo programas kuriantys žmonės neturėtų priešais save regėti vien begalinių teksto eilučių.
2012-ųjų sausį Viktoras kreipėsi į savo ginklo brolius. Jis sukūrė kelias demonstracines versijas, parodančias, kokiais primityviais būdais dabar sprendžiamos įvairios užduotys (klaidų paieška algoritmuose, kompiuterinė animacija) ir kaip jos galėtų būti sprendžiamos.
Be viso kito, jis sukūrė visiems gerai žinomo žaidimo „Mario“ vizualizaciją, kur vienoje ekrano pusėje buvo žaidimo vaizdas, o kitoje – kodo redaktorius. Prie įprastinių žaidimo kintamųjų, kuriuos programuotojas gali keisti (Mario judėjimo greitis, jo šuolių aukštis, kitų personažų judėjimas), Viktoras pridūrė laiko skalę. Ja bet kuriuo momentu buvo galima pažiūrėti, kaip Mario judės, esant duotiems parametrams: jeigu jis pašoks į tam tikrą aukštį, kur atsidurs po sekundės, dviejų, trijų. Įprastai, programuotojas, norėdamas išvysti, kas, pakeitus parametrus, nutiks su personažu, turėdavo paleisti žaidimą; jei reikėdavo ką nors pakeisti, procesą reikėjo kartoti: pakeisti kintamąjį kode, paleisti žaidimą, žiūrėti, kaip pavyko, vėl keisti, vėl paleisti, vėl žiūrėti. Dabar taisymų rezultatą buvo galima matyti tiesiogiai. Nepaisant tokio, regis akivaizdaus, sprendimo, auditorija aiktelėjo.
Viktoro būdas įkvėpė jo kolegas, rašo „Atlantic“. Panašią vizualizaciją – vienoje ekrano pusėje kodas, kitoje – galutinis rezultatas – savo reikmėms pradėjo kurti programuotojai. Vienas toks projektas „Light Table“ 2012 metų balandį sutelktinio finansavimo platformoje „Kickstarter“ surinko daugiau nei 200 000 dolerių ir tapo sensacija tarp inžinierių. Idėja „matyti rezultatus realiuoju laiku“ ėmė plisti ir netrukus buvo panaudota „Apple“ ir „Google“ produktuose.
Tačiau pats Viktoras vis labiau nusivylė: jį suprato neteisingai. Programuotojai gavo įrankį darbo su kodu supaprastinimui, tačiau niekas neprakalbo, kad gal kodo iš viso neturėtų būti. Iš tiesų, Viktoro nuomone, jo srityje reikėtų maksimaliai sumažinti kodo naudojimą dabar sprendžiamų užduočių sprendimui. Dabar, kai, pavyzdžiui, automobilių niekas nesigamina patys, programavimas iš esmės lieka rankų darbu. Tai nėra itin didelė problema, kai kodą sudaro 10 tūkstančių eilučių, bet kai jų atsiranda 30 mln., kaip „Airbus“ lėktuvuose, ar 100 mln., kaip „Tesla“ automobiliuose, reikalai pasidaro gerokai sudėtingesni.
Prancūzijos kompanija „Esterel Technologies“ (priklauso JAV programinės įrangos gamintojai ANSYS ) – vienas iš naujo programavimo būdo pionierių. Dar praėjusio amžiaus devintajame dešimtmetyje „Esterel“ dirbo energetikos ir aviakosminėje sferoje, kurios suprato, kad neįtikėtinai išsipūtusiame kode vis sunkiau surasti klaidas, kurių, tuo tarpu buvo vis daugiau. Pamažu kompanija suprato, kad tradicinės programavimo kalbos tinka paprastų, nuspėjamų operacijų aprašymui (tarkime, kasos čekio spausdinimui), tačiau sistemose, kur reikia reaguoti į daug įvykių, neišvengiamai kyla painiava. O energetikoje ir aviacijoje (kaip ir galybėje kitų sričių) painiava kelia grėsmę gyvybei.
„Esterel“ būdas, kurio kūrimas truko ilgiau nei 10 metų, remiasi vadinamuoju į modelį orientuotu dizainu (model-based design). Čia nėra tiesioginio kodo rašymo – vietoje to programuotojas sukuria būsimos programos veikimo taisyklių „modelį“, o šias taisykles atitinkančio kodo generavimu užsiima kompiuteris. Toks modelis kokybiškai skiriasi nuo tradicinio programavimo, kai jūsų užduotis – imti sudėtingas taisykles ir paversti jas kodu; didžioji dalis energijos būtent ir sunaudojama tokiam vertimui, o ne pačių taisyklių apmąstymui. Į modelį orientuotame dizaine telikusios taisyklės, todėl jums belieka galvoti būtent apie jas, paaiškina „Atlantic“. Todėl programos autorius labiau susitelkia į sprendžiamą problemą. Dabar pagal šį principą sukurti programiniai produktai, naudojami kodų generavimui aviacijos ir kosmoso pramonėje, karyboje, sunkiojoje pramonėje, atominėse elektrinėse, medicinoje ir kitose srityse, kur klaidos gali brangiai kainuoti.
Dar viena programavimo kalba, primenanti modelių programavimą, – TLA⁺. Joje sistema taip pat gauna „reikalavimus“ – specifikacijas, – paaiškinančias, ką ji turo nuveikti, tačiau nenurodančias, kaip tai įgyvendinti. TLA⁺ žavi tuo, kad galima atlikti nuodugnų testavimą ir aptikti visas klaidas, kurios gali įsibrauto į tradicinį kodą. Šia TLA⁺ sistemų savybe naudojasi „Microsoft“, „Intel“, ESA (Europos kosmoso agentūra) ir kitos organizacijos, kuriančios itin sudėtingus programinius produktus.
Nepaisant šių būdų privalumų, didžioji dalis programinės įrangos naudoja ankstesnius būdus, konstatuoja Somersas: inžinieriai aprašo programuotojams savo reikalavimus produktui, programuotojai rašo kodą, kad sistema šiuos reikalavimus išpildytų. Ir į modelį orientuotas projektavimas, ir TLA⁺ vis dar naudojami gan retai – kaip pažymi Viktoras, iš dalies dėl to, kad daugumai programuotojų patinka senas geras kodas – jie prie jo pripratę, jį supranta. Modeliu pagrįsto programavimo šalininkai nurodo iš to kylančią paradoksalią situacija: žinome, kad sudėtingėjant kodui, jame atsiranda daug klaidų, ir žinome, kaip sudėtingas programas padaryti patikimomis. Bet dėl kažkokios priežasties nusprendžiame nieko nekeisti. Kodėl?
L. Lamporto nuomone, dauguma programuotojų (ir programavimo dėstytojų) ne itin gerai supranta tuos matematikos skyrius, kurie reikalingi, dirbant su TLA⁺, – matematikos logika ir aibių teorija. „Jie mano, kad tereikia mokėti rašyti kodą, – sako mokslininkas. – Idėja, kad egzistuoja kažkoks aukštesnis lygis, kuriame būtinas tikslus mąstymas ir kuris įmanomas, naudojant matematiką, jiems atrodo visiškai nesuprantama. Jie niekada to nesimokė. XV amžiuje žmonės statė šventyklas, nesinaudodami skaičiavimais, – tęsia Lamportas. – Dabar nemanau, kad leistumėte užsiimti statybomis kam nors, kas tokių žinių neturi. Tikiuosi, laikui bėgant, nesuprantantiems šių paprastų dalykų, programų rašyti nebebus leidžiama.“
Yra ir kitas požiūris – kad programuotojai tiesiog nežino, kad matematika gali padėti jiems sutramdyti sudėtingą kodą. Jie nesimoko TLA⁺, nes mano, kad tai bus tuščiai praleistas laikas, ir nemato, kaip jis padėtų jiems spręsti kasdienes užduotis. Kitaip tariant, naujus programavimo būdus kamuoja įvaizdžio problemos; jų sprendimui veikiausiai reikės laiko, rašo „Atlantic“.
2015 metais du saugumo specialistai kuo akivaizdžiausiai pademonstravo pasauliui automobilio kompiuterinės sistemos pažeidžiamumą: nuotoliniu būdu perėmė greitkeliu važiuojančio „Jeep Cherokee“ kontrolę, – vairuotojas negalėjo nei pasukti vairo, nei stabdyti. Pasak vieno iš programišių, Chriso Valaseko, šis epizodas įrodo, kad metas kodą vertinti kitaip. Šiuolaikinės kompiuterių sistemos tapo pernelyg sudėtingos, kad jų kūrėjai galėtų patikrinti ir užkirsti kelią viskam, kas tik gali nutikti.
Nors daugelis to automobilio sistemų buvo sugalvotos, siekiant, kad jis taptų saugesnis, jos suteikia galimybę tokioms klaidoms, kurių žmonės iš anksto negalėjo įsivaizduoti ir apskaičiuoti. Gali būti, kad tai, apie ką kalba Bretas Viktoras, – regimas ryšys tarp programos kodo ir rezultato, – galėtų padėti ir šioje situacijoje. „Programavimas nematomas, tai yra fundamentali jo savybė, – sako Gerard Berry, Prancūzijos informatikos tyrimų instituto INRIA specialistas. – Jeigu jums nuleidžia padangą, galite pažvelgti į ją ir pamatyt, kad ji subliuškusi. Kai kyla problema programoje, žiūrite į programą ir nieko nematote“.
