Програмирање је више од кодирања

Ово је превод чланка Станфорд Семинар. Али пре тога следи кратак увод. Како се формирају зомбији? Свако се нашао у ситуацији да жели пријатеља или колегу да подигне на њихов ниво, али то не иде. Штавише, „не иде“ не толико за вас, колико за њега: на једној страни скале је нормална плата, задаци и тако даље, а на другој је потреба за размишљањем. Размишљање је непријатно и болно. Брзо одустаје и наставља да пише код, а да уопште не користи свој мозак. Схватате колико је труда потребно да бисте превазишли баријеру научене беспомоћности, а једноставно то не радите. Тако настају зомбији, које се чини да је могуће излечити, али изгледа да то нико неће учинити.

Кад сам то видео Леслие Лампорт (да, тај исти друг из уџбеника) долази у Русију и не даје извештај, већ сесију питања и одговора, био сам мало опрезан. За сваки случај, Лесли је научник светског гласа, аутор суштинских радова у дистрибуираном рачунарству, а можда га познајете и по словима Ла у ЛаТеКс-у – „Лампорт ТеКс“. Други алармантни фактор је његов захтев: свако ко дође мора (потпуно бесплатно) да преслуша пар његових извештаја унапред, постави бар једно питање о њима, па тек онда дође. Одлучио сам да видим шта је Лампорт тамо емитовао - и то је сјајно! То је управо та ствар, магична веза-пилула за лечење зомбија. Упозоравам вас: текст може озбиљно да опече оне који воле супер-агилне методологије и који не воле да тестирају оно што су написали.

Након хаброката, заправо почиње превод семинара. Уживај у читању!

Који год задатак да преузмете, увек морате да прођете кроз три корака:

• одлучите који циљ желите да постигнете;
• одлучите како ћете тачно постићи свој циљ;
• достићи свој циљ.

Ово важи и за програмирање. Када пишемо код, потребно нам је:

• одлучити шта тачно програм треба да ради;
• тачно одреди како треба да изврши свој задатак;
• напишите одговарајући код.

Последњи корак је, наравно, веома важан, али нећу о томе данас. Уместо тога, разговараћемо о прва два. Сваки програмер их изводи пре него што почне да ради. Не седите да пишете осим ако нисте одлучили шта пишете: претраживач или базу података. Одређена идеја о циљу мора бити присутна. И свакако размислите о томе шта ће тачно програм радити, и немојте га писати насумично у нади да ће се сам код некако претворити у претраживач.

Како се тачно дешава ово претходно размишљање о коду? Колико труда треба да уложимо у ово? Све зависи од тога колико сложен проблем решавамо. Рецимо да желимо да напишемо дистрибуирани систем отпоран на грешке. У овом случају, требало би да пажљиво размислимо о стварима пре него што седнемо да кодирамо. Шта ако само треба да повећамо целобројну променљиву за 1? Овде је на први поглед све тривијално и није потребно размишљање, али онда се сетимо да може доћи до преливања. Стога, чак и да бисте разумели да ли је проблем једноставан или сложен, прво морате размислити.

Ако унапред размислите о могућим решењима проблема, можете избећи грешке. Али ово захтева да ваше размишљање буде јасно. Да бисте то постигли, морате записати своје мисли. Волим цитат Дика Гиндона: „Када пишеш, природа ти показује колико је твоје размишљање аљкаво. Ако не пишете, само мислите да мислите. И треба да запишете своје мисли у облику спецификација.

Спецификације служе многим функцијама, посебно у великим пројектима. Али говорићу само о једном од њих: они нам помажу да јасно размишљамо. Размишљање јасно је веома важно и прилично тешко, тако да нам је потребна било каква помоћ. На ком језику треба да пишемо спецификације? Генерално, ово је увек прво питање за програмере: на ком језику ћемо писати? Не постоји један тачан одговор: проблеми које решавамо су превише разноврсни. За неке људе, ТЛА+ је језик спецификације који сам ја развио. За друге је згодније користити кинески. Све зависи од ситуације.

Важније питање је: како можемо постићи јасније размишљање? Одговор: Морамо размишљати као научници. Ово је начин размишљања који је добро функционисао у последњих 500 година. У науци градимо математичке моделе стварности. Астрономија је можда била прва наука у строгом смислу те речи. У математичком моделу који се користи у астрономији, небеска тела се појављују као тачке са масом, положајем и импулсом, иако су у стварности изузетно сложени објекти са планинама и океанима, осекама и токовима. Овај модел, као и сваки други, створен је да реши одређене проблеме. Одличан је за одређивање где да усмерите телескоп ако желите да пронађете планету. Али ако желите да предвидите време на овој планети, овај модел неће радити.

Математика нам омогућава да одредимо својства модела. И наука показује како се ова својства односе на стварност. Хајде да причамо о нашој науци, информатици. Реалност са којом радимо су рачунарски системи много различитих типова: процесори, конзоле за игре, рачунари који покрећу програме итд. Говорићу о извршавању програма на рачунару, али, углавном, сви ови закључци важе за сваки рачунарски систем. У нашој науци користимо много различитих модела: Тјурингову машину, делимично уређене скупове догађаја и многе друге.

Шта је програм? Ово је сваки код који се може разматрати самостално. Рецимо да треба да напишемо претраживач. Изводимо три задатка: дизајнирамо корисничку презентацију програма, затим пишемо дијаграм високог нивоа програма и на крају пишемо код. Док пишемо код, схватамо да треба да напишемо форматер текста. Овде поново треба да решимо три проблема: одредимо који текст ће ова алатка вратити; изаберите алгоритам за форматирање; написати код. Овај задатак има свој подзадатак: правилно уметање цртица у речи. И овај подзадатак решавамо у три корака – као што видимо, они се понављају на више нивоа.

Хајде да ближе погледамо први корак: који проблем решава програм. Овде најчешће моделујемо програм као функцију која узима неки улаз и даје неки излаз. У математици, функција се обично описује као уређени скуп парова. На пример, функција квадрирања природних бројева је описана као скуп {<0,0>, <1,1>, <2,4>, <3,9>, …}. Област дефинисања такве функције је скуп првих елемената сваког пара, односно природних бројева. Да бисмо дефинисали функцију, потребно је да наведемо њен домен и формулу.

Али функције у математици нису исто што и функције у програмским језицима. Математика је много једноставнија. Пошто немам времена за сложене примере, хајде да размотримо један једноставан: функцију у Ц-у или статичку методу у Јави која враћа највећи заједнички делилац два цела броја. У спецификацији ове методе написаћемо: израчунава GCD(M,N) за аргументе M и NГде GCD(M,N) - функција чији је домен скуп парова целих бројева, а повратна вредност је највећи цео број који је подељен са M и N. Каква је стварност у поређењу са овим моделом? Модел ради са целим бројевима, а у Ц или Јави имамо 32-битни int. Овај модел нам омогућава да одлучимо да ли је алгоритам исправан GCD, али то неће спречити грешке преливања. То би захтевало сложенији модел, за који нема времена.

Хајде да разговарамо о ограничењима функције као модела. Неки програми (као што су оперативни системи) не враћају само одређену вредност за одређене аргументе; они могу да раде непрекидно. Поред тога, функција као модел није погодна за други корак: планирање како да се реши проблем. Куицксорт и буббле сорт израчунавају исту функцију, али су потпуно различити алгоритми. Стога, да бих описао начин постизања циља програма, користим други модел, назовимо га стандардни модел понашања. Програм је у њему представљен као скуп свих важећих понашања, од којих је свако, заузврат, низ стања, а стање је додељивање вредности променљивим.

Хајде да видимо како би изгледао други корак за Еуклидски алгоритам. Морамо да израчунамо GCD(M, N). Иницијализујемо M као xИ N као y, затим више пута одузимајте мању од ових променљивих од веће док не буду једнаке. На пример, ако M = 12И N = 18, можемо описати следеће понашање:

[x = 12, y = 18] → [x = 12, y = 6] → [x = 6, y = 6]

И ако M = 0 и N = 0? Нула је дељива свим бројевима, тако да у овом случају нема највећег делиоца. У овој ситуацији, морамо се вратити на први корак и питати: да ли заиста треба да израчунамо ГЦД за непозитивне бројеве? Ако то није потребно, само треба да промените спецификацију.

Овде је на реду кратка дигресија о продуктивности. Често се мери бројем редова кода написаних дневно. Али ваш рад је много кориснији ако се ослободите одређеног броја линија, јер имате мање простора за грешке. А најлакши начин да се решите кода је у првом кораку. Могуће је да вам једноставно нису потребна сва звона и звиждаљке које покушавате да примените. Најбржи начин да поједноставите програм и уштедите време је да не радите ствари које не би требало да се раде. Други корак има други највећи потенцијал за уштеду времена. Ако мерите продуктивност у смислу написаних редова, онда ће вас натерати размишљање о томе како да завршите задатак мање продуктиван, јер исти проблем можете решити са мање кода. Овде не могу да дам тачну статистику, јер немам начина да избројим редове које нисам написао због времена које сам потрошио на спецификацију, односно на први и други корак. А ни овде не можемо да радимо експеримент, јер у експерименту немамо право да завршимо први корак, задатак је унапред одређен.

Лако је превидети многе потешкоће у неформалним спецификацијама. Нема ништа тешко у писању строгих спецификација за функције; о томе нећу расправљати. Уместо тога, разговараћемо о писању јаких спецификација за стандардна понашања. Постоји теорема која каже да се било који скуп понашања може описати коришћењем својства сигурности (безбедност) и својства преживљавања (живост). Сигурност значи да се ништа лоше неће догодити, програм неће дати погрешан одговор. Преживљавање значи да ће се пре или касније нешто добро десити, односно програм ће пре или касније дати тачан одговор. Сигурност је по правилу важнији показатељ, ту се најчешће јављају грешке. Због тога, да уштедим време, нећу говорити о преживљавању, иако је то, наравно, такође важно.

Сигурност постижемо тако што прво специфицирамо скуп могућих почетних стања. И друго, односи са свим могућим следећим државама за сваку државу. Хајде да се понашамо као научници и да математички дефинишемо стања. Скуп почетних стања је описан формулом, на пример, у случају Еуклидовог алгоритма: (x = M) ∧ (y = N). За одређене вредности M и N постоји само једно почетно стање. Однос са следећим стањем описује се формулом у којој се променљиве следећег стања записују са простим, а променљиве тренутног стања без простог броја. У случају Еуклидовог алгоритма, бавићемо се дисјункцијом две формуле, у једној од којих x је највећа вредност, ау другом - y:

У првом случају, нова вредност и једнака је претходној вредности и, а нову вредност к добијамо одузимањем мање променљиве од веће. У другом случају радимо супротно.

Вратимо се еуклидском алгоритму. Претпоставимо опет то M = 12, N = 18. Ово дефинише једно почетно стање, (x = 12) ∧ (y = 18). Затим стављамо ове вредности у горњу формулу и добијамо:

Ево јединог могућег решења: x' = 18 - 12 ∧ y' = 12, и добијамо понашање: [x = 12, y = 18]. На исти начин можемо описати сва стања у нашем понашању: [x = 12, y = 18] → [x = 12, y = 6] → [x = 6, y = 6].

У последњем стању [x = 6, y = 6] оба дела израза ће бити нетачна, стога он нема следеће стање. Дакле, имамо потпуну спецификацију другог корака - као што видимо, ово је сасвим обична математика, попут оне инжењера и научника, а не чудна, као у рачунарству.

Ове две формуле могу се комбиновати у једну формулу временске логике. Елегантно је и лако објаснити, али за то сада нема времена. Временска логика нам је можда потребна само за својство живости; за сигурност није потребна. Не волим временску логику као такву, није баш обична математика, али у случају живости јесте нужно зло.

У Еуклидском алгоритму за сваку вредност x и y постоје јединствене вредности x' и y', што чини релацију са следећим стањем истинитим. Другим речима, Еуклидски алгоритам је детерминистички. Да би се моделирао недетерминистички алгоритам, тренутно стање мора да има више могућих будућих стања, а свака вредност непримиране променљиве мора имати вишеструке вредности првобитне променљиве тако да је однос према следећем стању тачан. Ово није тешко урадити, али нећу сада давати примере.

Да бисте направили радни алат, потребна вам је формална математика. Како формално направити спецификацију? Да бисмо то урадили биће нам потребан формални језик, нпр. ТЛА+. Спецификација Еуклидовог алгоритма на овом језику ће изгледати овако:

Симбол знака једнакости са троуглом значи да је вредност лево од знака одређена као једнака вредности десно од знака. У суштини, спецификација је дефиниција, у нашем случају две дефиниције. Спецификацији у ТЛА+ морате додати декларације и неку синтаксу, као на горњој слици. У АСЦИИ-у би то изгледало овако:

Као што видите, ништа компликовано. Спецификација на ТЛА+ се може проверити, односно могуће је заобићи сва могућа понашања у малом моделу. У нашем случају, овај модел ће бити одређене вредности M и N. Ово је веома ефикасан и једноставан метод верификације који је потпуно аутоматски. Поред тога, могуће је написати формалне доказе истине и механички их проверити, али то захтева доста времена, тако да то скоро нико не ради.

Главни недостатак ТЛА+ је то што је математика, а програмери и информатичари се боје математике. На први поглед ово звучи као шала, али, нажалост, ово говорим потпуно озбиљно. Један мој колега ми је управо причао како је покушао да објасни ТЛА+ неколико програмера. Чим су се формуле појавиле на екрану, очи су им одмах постале стаклене. Дакле, ако је ТЛА+ застрашујући, можете га користити ПлусЦал, је врста програмског језика играчака. Израз у ПлусЦал-у може бити било који ТЛА+ израз, односно у основи било који математички израз. Поред тога, ПлусЦал има синтаксу за недетерминистичке алгоритме. Пошто ПлусЦал може да напише било који ТЛА+ израз, он је знатно изражајнији од било ког правог програмског језика. Затим се ПлусЦал компајлира у лако читљиву ТЛА+ спецификацију. То, наравно, не значи да ће се сложена ПлусЦал спецификација претворити у једноставну на ТЛА+ – само да је кореспонденција између њих очигледна, неће се појавити додатна сложеност. Коначно, ова спецификација се може проверити помоћу ТЛА+ алата. Генерално, ПлусЦал може помоћи у превазилажењу фобије од математике; лако га разумеју чак и програмери и компјутерски научници. Објављивао сам алгоритме на њему неко време (око 10 година) у прошлости.

Можда ће неко замерити да су ТЛА+ и ПлусЦал математика, а математика ради само са измишљеним примерима. У пракси вам је потребан прави језик са типовима, процедурама, објектима и тако даље. Ово није у реду. Ево шта пише Цхрис Невцомб, који је радио у Амазону: „Користили смо ТЛА+ на десет великих пројеката, и у сваком случају његова употреба је направила значајну разлику у развоју јер смо били у могућности да ухватимо опасне грешке пре него што дођу у производњу, и зато што нам је дао увид и самопоуздање који су нам били потребни да постанемо агресивни. оптимизације перформанси без утицаја на истинитост програма". Често можете чути да коришћењем формалних метода добијамо неефикасан код – у пракси је све управо супротно. Поред тога, постоји перцепција да менаџери не могу бити убеђени у потребу за формалним методама, чак и ако су програмери уверени у њихову корисност. И Њукомб пише: „Менаџери се сада на све могуће начине залажу за писање спецификација у ТЛА+, и посебно издвајају време за то“. Дакле, када менаџери виде да ТЛА+ функционише, они то прихватају. Цхрис Невцомб је ово написао пре отприлике шест месеци (октобар 2014), али сада, колико ја знам, ТЛА+ се користи у 14 пројеката, а не у 10. Други пример се односи на дизајн КСБок 360. Стажиста је дошла код Чарлса Такера и написао спецификацију за меморијски систем. Захваљујући овој спецификацији, пронађена је грешка која би иначе била неоткривена и изазвала би пад сваког КСБок 360 након четири сата коришћења. Инжењери из ИБМ-а потврдили су да њихови тестови не би открили ову грешку.

Више о ТЛА+ можете прочитати на Интернету, али сада хајде да причамо о неформалним спецификацијама. Ретко морамо да пишемо програме који израчунавају најмањи заједнички делилац и слично. Много чешће пишемо програме попут алата за лепе штампаче који сам написао за ТЛА+. Након најједноставније обраде, ТЛА+ код би изгледао овако:

Али у горњем примеру, корисник је највероватније желео да се коњункција и знак једнакости поравнају. Дакле, исправно форматирање би изгледало више овако:

Размотримо још један пример:

Овде је, напротив, поравнање предзнака једнакости, сабирања и множења у извору било насумично, па је најједноставнија обрада сасвим довољна. Генерално, не постоји тачна математичка дефиниција исправног форматирања, јер „тачно“ у овом случају значи „оно што корисник жели“, а то се не може математички одредити.

Чини се да ако немамо дефиницију истине, онда је спецификација бескорисна. Али то није истина. Само зато што не знамо шта програм треба да ради не значи да не треба да размишљамо о томе како би требало да функционише – напротив, требало би да уложимо још више труда на то. Овде је посебно важна спецификација. Немогуће је одредити оптималан програм за структурирано штампање, али то не значи да га уопште не треба предузимати, а писање кода као тока свести није случај. На крају сам написао спецификацију шест правила са дефиницијама у виду коментара у Јава датотеци. Ево примера једног од правила: a left-comment token is LeftComment aligned with its covering token. Ово правило је написано на, рецимо, математичком енглеском: LeftComment aligned, left-comment и covering token — појмови са дефиницијама. Овако математичари описују математику: пишу дефиниције појмова и на основу њих креирају правила. Предност ове спецификације је што је шест правила много лакше разумети и отклонити грешке од 850 линија кода. Морам рећи да писање ових правила није било лако; требало је доста времена да се отклоне грешке. Написао сам код посебно за ову сврху који ми је рекао које правило се користи. Пошто сам тестирао ових шест правила са неколико примера, нисам морао да отклањам грешке у 850 линија кода, а грешке је било прилично лако пронаћи. Јава има одличне алате за ово. Да сам само написао код, требало би ми много дуже и форматирање би било лошијег квалитета.

Зашто се не би могла користити формална спецификација? С једне стране, исправно извођење овде није превише важно. Структурирани отисак ће некима бити незадовољавајући, тако да нисам морао да га натерам да ради исправно у свим необичним ситуацијама. Још важнија је чињеница да нисам имао адекватан алат. Провера модела ТЛА+ је бескорисна овде, па бих морао да пишем примере руком.

Дата спецификација има карактеристике заједничке свим спецификацијама. То је виши ниво од кода. Може се имплементирати на било ком језику. Не постоје алати или методе за писање. Ниједан курс програмирања вам неће помоћи да напишете ову спецификацију. И не постоје алати који би ову спецификацију могли учинити непотребном, осим ако, наравно, не пишете језик посебно за писање структурираних програма за штампање у ТЛА+. Коначно, ова спецификација не говори ништа о томе како ћемо тачно написати код, већ само наводи шта код ради. Пишемо спецификацију која ће нам помоћи да размислимо о проблему пре него што почнемо да размишљамо о коду.

Али ова спецификација такође има карактеристике које је разликују од других спецификација. 95% осталих спецификација је много краће и једноставније:

Даље, ова спецификација је скуп правила. Ово је обично знак лоше спецификације. Разумевање последица скупа правила је прилично тешко, због чега сам морао да потрошим много времена на њихово отклањање грешака. Међутим, у овом случају нисам могао пронаћи бољи начин.

Вреди рећи неколико речи о програмима који раде континуирано. Обично раде паралелно, као што су оперативни системи или дистрибуирани системи. Врло мало људи их може разумјети у мислима или на папиру, а ја нисам један од њих, иако сам то некада могао. Због тога су нам потребни алати који ће проверити наш рад - на пример, ТЛА+ или ПлусЦал.

Зашто сам морао да напишем спецификацију ако сам већ знао шта код треба да ради? У ствари, само сам мислио да знам. Поред тога, са постављеном спецификацијом, аутсајдер више не мора да гледа у код да би разумео шта тачно ради. Имам правило: не би требало да постоје општа правила. Постоји изузетак од овог правила, наравно, ово је једино опште правило које следим: спецификација онога што код ради треба да каже људима све што треба да знају када користе тај код.

Дакле, шта тачно програмери треба да знају о размишљању? За почетак, исто као и за све: ако не пишеш, онда ти се само чини да размишљаш. Такође, морате размишљати пре него што кодирате, што значи да морате писати пре него што кодирате. Спецификација је оно што напишемо пре него што почнемо да кодирамо. Спецификација је потребна за сваки код који свако може да користи или мења. А овај „неко“ може да се испостави да је аутор кода месец дана након што је написан. Спецификација је потребна за велике програме и системе, за класе, за методе, а понекад чак и за сложене делове једне методе. Шта тачно треба да напишете о коду? Морате описати шта ради, односно нешто што може бити корисно свакоме ко користи овај код. Понекад ће такође бити потребно навести како тачно код постиже свој циљ. Ако смо прошли кроз овај метод у курсу алгоритама, онда га називамо алгоритамом. Ако је то нешто специјализованије и ново, онда то називамо дизајном високог нивоа. Овде нема формалне разлике: оба су апстрактни модели програма.

Како тачно треба да напишете спецификацију кода? Главна ствар: требало би да буде један ниво више од самог кода. Мора да описује стања и понашања. Требало би да буде строго онолико колико задатак захтева. Ако пишете спецификацију како да имплементирате задатак, онда то може бити написано у псеудокоду или користећи ПлусЦал. Морате научити да пишете спецификације користећи формалне спецификације. Ово ће вам дати неопходне вештине које ће такође помоћи у неформалним. Како можете научити да пишете формалне спецификације? Када смо научили да програмирамо, написали смо програме и потом их отклонили. Иста ствар овде: треба да напишете спецификацију, проверите је помоћу провере модела и исправите грешке. ТЛА+ можда није најбољи језик за формалну спецификацију, а други језик би вероватно био боље прилагођен вашим специфичним потребама. Одлична ствар код ТЛА+ је то што одлично ради у подучавању математичког размишљања.

Како повезати спецификацију и код? Коришћење коментара који повезују математичке концепте и њихову имплементацију. Ако радите са графовима, онда ћете на нивоу програма имати низове чворова и низове веза. Дакле, треба да напишете како се тачно граф имплементира овим програмским структурама.

Треба напоменути да се ништа од наведеног не односи на сам процес писања кода. Када пишете код, односно изводите трећи корак, такође треба да размишљате и промишљате кроз програм. Ако се подзадатак покаже сложеним или неочигледним, потребно је да за њега напишете спецификацију. Али овде не говорим о самом коду. Можете користити било који програмски језик, било коју методологију, не ради се о њима. Такође, ништа од горе наведеног не елиминише потребу за тестирањем и отклањањем грешака у вашем коду. Чак и ако је апстрактни модел исправно написан, може постојати грешке у његовој имплементацији.

Писање спецификација је додатни корак у процесу кодирања. Захваљујући њему, многе грешке се могу ухватити уз мање напора - то знамо из искуства програмера из Амазона. Са спецификацијама, квалитет програма постаје већи. Па зашто онда тако често идемо без њих? Зато што је писање тешко. Али писање је тешко, јер за ово треба размишљати, а размишљање је такође тешко. Увек је лакше претварати се да размишљаш. Овде се може повући аналогија са трчањем – што мање трчиш, трчиш спорије. Морате да тренирате мишиће и вежбате писање. Потребна је пракса.

Спецификација може бити нетачна. Можда сте негде погрешили, или су се захтеви променили, или је можда потребно побољшати. Сваки код који неко користи мора да се промени, тако да пре или касније спецификација више неће одговарати програму. У идеалном случају, у овом случају, морате написати нову спецификацију и потпуно преписати код. Знамо добро да то нико не ради. У пракси, закрпимо код и можда ажурирамо спецификацију. Ако ће се ово догодити пре или касније, зашто онда уопште писати спецификације? Прво, за особу која ће уређивати ваш код, свака додатна реч у спецификацији ће бити злата вредна, а та особа можете бити ви. Често се зезам што нисам довољно прецизан када уређујем свој код. И пишем више спецификација него кода. Стога, када уређујете код, спецификацију увек треба ажурирати. Друго, са сваком изменом код постаје гори, постаје све тежи за читање и одржавање. Ово је повећање ентропије. Али ако не почнете са спецификацијом, онда ће сваки ред који напишете бити измена, а код ће бити гломазан и тешко читљив од самог почетка.

Као што је речено Еисенховер, ниједна битка није добијена по плану и ниједна битка није добијена без плана. И знао је нешто о биткама. Постоји мишљење да је писање спецификација губљење времена. Понекад је то тачно, а задатак је толико једноставан да нема смисла размишљати о њему. Али увек треба да запамтите да када вам се саветује да не пишете спецификације, то значи да вам се саветује да не размишљате. И о овоме треба размишљати сваки пут. Размишљање о задатку не гарантује да нећете погрешити. Као што знамо, нико није измислио магични штапић, а програмирање је тежак задатак. Али ако не размислите о задатку, гарантовано ћете погрешити.

Више о ТЛА+ и ПлусЦал-у можете прочитати на посебном сајту, тамо можете отићи са моје почетне странице по ссылке. То је све за мене, хвала на пажњи.

Запамтите да је ово превод. Када пишете коментаре, запамтите да их аутор неће читати. Ако заиста желите да ћаскате са аутором, он ће бити на конференцији Хидра 2019, која ће се одржати од 11. до 12. јула 2019. у Санкт Петербургу. Улазнице се могу купити на званичној веб страници.

Извор: ввв.хабр.цом