Александър Иванов

Когато нещата не вървят

Кой е този интерпретатор?

Аха, разбирам. Имаш предвид интерпретатора на пайтън, който от време на време споменавам. Ще ти обясня, ама отговорът не е много кратък, та бъди така добър да го дочетеш.

Най-големите писатели на нашето време са програмистите — те нищо друго не правят, освен да пишат текстове (и да се учат да пишат текстове). При това създават текстове по 100 хиляди реда, че дори и по-големи.

Да ти кажа само за сравнение — Илиадата е с по-малко от 16 хиляди стиха, а цялата Библия съдържа малко под 37 хиляди стиха.

Програмистите, разбира се, пишат програми. А в програмите има само един вид изрази — повелителни, просто команди, които компютърът трябва да изпълни. Програмистът пише, например, такава команда:

print("Здрасти!")

Тя означава ’печатай на конзолата текста Здрасти!’. И нищо повече. И няма никаква модалност, няма изрази като „Би ли бил така добър да отпечаташ…“, „Ако не те затруднява, можеш ли да отпечаташ…“, „Ах! Исках да те помоля да отпечаташ…“.

Не забравяй — компютърът е само машина, много изпълнителна, много чевръста, но само машина. Ако понякога ти се струва, че компютърът се държи „човекоподобно“, да знаеш — програмистът на тази програма се е опитал да предвиди твоите „потребителски реакции“ (кога — успешно, кога — не толкова). Тоест, програмистът се държи с тебе човешки, не машината. Тя е само посредник между вас.

Както личи дори само от примерчето по-горе, в програмните езици се употребяват „думи“ от „естествените езици“. Обикновено от английски. При това не много — в питона, например, са малко повече от 30. Използват се и небуквени символи. И всичко това се подчинява на прости синтактични правила, които — о, чудо! — нямат изключения за зазубряне.

Така че за филолога да се научи да програмира, тоест да си обработва данните, е елементарно, толкова елементарно, че чак е обидно. Стига да прескочи предубеждението си, че за да се научиш да програмираш, трябва да си най-малко професор по математика.

Всъщност, точно професорите по теоретична математика, „цветът“ на математиците, не само че не знаят да програмират, но нямат и желание да се учат. Щото не им трябва. Безполезно им е.

Та така. Програмистът си е написал текста на програмата. Това е най-обикновен текстов файл, гол текст. (Ако не си наясно какво е гол текст, погледни Текстов файл, бинарен файл.)

Сега трябва този програмен текст, написан на повече или по-малко „човешки“ програмен език, да бъде преведен на единствения език, който разбира процесорът на компютъра — машинния език.

И, да, общото наименование за програмите, които извършват тоя превод, е точно „преводач“ (translator).

Машинният език на процесора представлява трудно разбираема за човека поредица от байтове, която почти не може да се редактира.

Откакто се е появила компютърната техника, информатиците се опитват да облекчат живота на човека — първо своя живот, после и нашия.

Първоначално са използвали електро-механични устройства с клавиатура, за да перфорират ленти и перфокарти. Всяка дупчица (или липсата й) върху лентата или перфокартата отговаря точно на един бит информация. Ама цялата поредица от битове я перфорираш все пак с натискането на един клавиш, нали!? Превод значи…

После с четящо устройство тази информация се вкарва в оперативната памет на компютъра.

Това е било облекчение, ама не кой знае колко. Говорил съм с хора, които са работели по този начин — нямат мили спомени.

Затова скоро се появяват първите програмни езици — асемблерите. При тях вече е реализирана идеята програмистът да си пише и да си редактира програмата като текст в текстовия редактор, а програма преводач (точно нея наричат асемблер) да превръща текстовия програмен файл в бинарен файл, съдържащ команди към процесора.

Само че при асемблерните езици една команда в програмата горе-долу отговаря на една команда към процесора. Най-често командата в асемблера представлява мнемоника от няколко букви, мнемоника за команда към процесора, както е описана в документацията му. Тоест, с асемблерните езици се работи много близко до хардуера, изискват се известни инженерни познания за процесора и за цялата компютърна система. Затова определят асемблерните езици като езици на ниско равнище.

Впрочем, съвременните асемблери имат много удобства, силно се приближават, например, до програмния език C, и е чак странно да четеш по форумите колко студентите по информатика се страхуват от асемблера.

Но за филолога, за да си обработва текстовете и речниците, асемблерът е съвсем неподходящ език за програмиране. Впрочем, езикът C, който студентите по информатика задължително изучават — също. Та не се хващай на кандърми на разни хора (обикновено инженери или информатици), които нищо не отбират от твоята работа.

Идеята за програма-преводач се оказва изключително плодотворна. Програмният език може да бъде направен по-удобен за човека, за програмиращия, а цялата хамалогия по превода към машинен език да се възложи на програмата. Така възникват езиците за програмиране на високо равнище. При тях командата или командната конструкция има по-човешки вид, а програмата-преводач я превръща в много, понякога цяла каскада от елементарни машинни команди.

Така програмирането се интензифицира, става възможно съществуването на този огромен набор от софтуер, с който разполагаме днес.

От друга страна програмирането се демократизира — днес програмират или могат да се научат да програмират хора с най-различно образование и на всякаква възраст. Изглежда, че първите информатици, които се досещат колко важно е това за бъдещето, са Джон Кемени и Томас Курц, създателите на програмния език Basic (в 1964 г.).

Но всичко това има и обратна страна — специалистите по информатика наплодиха и продължават да плодят огромно количество програмни езици. При това съвсем не винаги главната цел е да са удобни за човека. Изобилстват примери на програмни езици, които са създадени, за да „пасват на концепцията“. За филолога това е познато, нали?

Когато работеше върху книгата си „Електрониката в помощ на учителя филолог“ [djvu] [един файл], М. Янакиев се опита да даде някаква оценка за количеството на програмните езици, но се отказа, след като се убеди, че още тогава програмните езици бяха повече от естествените.

Програмите преводачи (транслаторите) работят по два различни начина.

Единият тип транслатори са интерпретаторите (interpreters). Те превеждат на машинен език първата команда, подават я на системата за изпълнение и изчакват да се изпълни. Едва след това превежда втората команда, пак изчакват изпълнението й — и така до края на програмата. Работата много прилича на консекутивния превод. А програмките за интерпретаторите наричат на английски scripts (сценарии) — и наистина, интерпретаторът „играе“ по сценария при всяко стартиране на програмата. Тоест, превежда я отново и отново при всяко изпълнение.

Другият тип транслатори, компилаторите (compilers), работят горе-долу като преводача на книга — те превеждат целия текст на програмата до машинен език и го записват във файл. Ако всичко е наред, после може да стартираш този файл (през операционната система) и той ще се изпълни. Разбира се, при следващото изпълнение на този бинарен програмен файл, вече няма да се губи време за компилацията му.

Процесът на компилация често е по-сложен, разбива се на отделни част, за да могат да се прилагат разни програмистки хитрини.

Например, програмата се състои от много файлове, всеки един от тях се компилира да „полуфабрикат“, пък след това се сглобява в цяла и красива програма, или действието print() се изтегля от програмна библиотека, където то е вече преведено на машинен език, а се променят само препратките към данните, които ти подаваш в програмата си.

Та затова преводачът се нарича компилатор — сглобява разни парчета „полуфабрикат“. Но с тези тънкости няма да те занимавам сега.

Компилаторните езици като C, C++, Pascal обикновено се използват от професионалните програмисти и задължително в комерсиалния софтуер — нали текста на програмата там не ти дават, крият го даже.

Интерпретаторите най-често работят в конзола. Когато стартираш Command Prompt в Windows, стартираш всъщност командния интерпретатор на DOS. Когато натиснеш Enter, точно той поема реда (командата) и го „интерпретира“, тоест изпълнява го или ти дава някакво съобщение за грешка (ако си объркал нещо). За програмния интерпретатор на DOS, разбира се, можеш да напишеш програмка (сценарий, script) и да го пуснеш да я изпълни. Такива програмки са с разширение .BAT (съкращение от batch).

В конзолата/терминала на линукс обикновено се използва bash, но има и други командни интерпретатори — dash, csh, tcsh, ash, zsh и пр. Често (но не е задължително) файлчетата с програмки (сценарии) за командния интерпретатор на линукс са с разширение .sh (съкращение от shell).

Развитието на интернет силно стимулира и развитието на интерпретаторните езици. На сървъра днес обикновено работят интерпретаторни езици като PHP, Ruby, Python, а от клиентската страна (тоест, в твоя браузър) — JavaScript.

Не бъркай Java с JavaScript — различни езици са!

Големи софтуерни фирми като Google, например, подкрепят развитието на софтуер чрез интерпретаторни езици, най-вече на Python. В твоя телефон или таблет с андроид вероятно много софтуер е написан на Python. Може да си изтеглиш и интерпретатора за Python и да си пишеш разни малки програмки за собствени нужди. Да, да! На телефона. И никак не е лошо.

С развитието на компютърната техника и на програмното осигуряване различията между компилаторните езици и интерпретаторните езици донякъде се заличават.

Технически различието между компилатори и интерпретатори няма как да се заличат. Ама за програмиращия, за човека, нещата започват да става еднакво удобни.

Днес програмиращите с компилаторни езици имат възможност да проследяват изпълнението на програмата си команда по команда, да следят съдържанието на паметите (данните) в програмата — все неща, които в интерпретаторите се правеха лесно от край време.

Интерпретаторните езици пък заеха някои идеи от компилаторите, „компилират“ програмата до някакъв междинен код (често го означават с p-code, съкращение от pseudo code) и я изпълняват много по-чевръсто. Тази техника определяха с малко объркващия термин „интерпретатори от компилаторен тип“.

Хората от моето поколение се срещнаха с този подход някъде след 1985 година във фантастичния интерпретатор за бейсик на Microsof — QuickBasic. А днес май всички интерпретатори го използват.