Nors iki kva­nti­nių kom­piu­te­rių ir jų ke­lia­mos grės­mės mū­sų ci­vi­li­za­ci­jai dar (ti­kė­ki­mės) to­lo­ka, bet ir įpras­tų kom­piu­te­rių pro­gra­mos jau yra už žmo­giš­ko­jo su­pra­ti­mo ri­bų. Tai la­bai pa­vo­jin­ga ir ne atei­ty­je, o da­bar.

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.

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.

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ė spageti 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. 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.

Programų kūrimo būdas nebeatitinka realijų

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 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.

Naujiems programavimo būdams kyla įvaizdžio problemų

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“.

I. Solomonova
World Press skyriaus redaktorė
republic.ru

Komentarai (20)