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)