Легенда компʼютерної науки Браян Керніган в інтервʼю DOU: про роботу програмістів у 60-ті та безсмертя мов програмування
Підручник з C, «Біблія для UNIX-програмістів», Multics — не вичерпний перелік того, чим відомий Браян Керніган, американський професор канадського походження, який стояв біля джерел компʼютерного програмування.
Науковець впродовж 30 років працював у легендарному Bell Labs — дослідницькому центрі, де розробили C, «плюси», AWK та AMPL (до створення останніх доклав руку сам Керніган), а девʼятеро Нобелівських лауреатів отримали цю нагороду за створені там винаходи.
Зараз
Фото Ben Lowe
Навчання в Університеті Торонто
— При вступі до Університету Торонто 1960 року ви обрали факультет інженерної фізики. Чому ви зупинились саме на цій галузі? Це якось пов’язано з історією вашої сімʼї?
У певному сенсі це відбулось випадково. Мій батько був інженером-хіміком, і він також вчився в Університеті Торонто. Я ж геть не цікавився хімією [сміється].
Втім шкільний вчитель математики звернув увагу на мій інтерес до цього та суміжних предметів. І він якраз пройшов чотирирічний курс з інженерної фізики в Університеті Торонто (1962 року назву програми змінили на «інженерна наука», що більше відповідало тогочасному наповненню курсу), і мене теж зацікавила ця програма.
Хоча це й був курс для інженерів, він мав серйозний ухил в математику, фізику та хімію. Наприклад, під час навчання ми дізнавалися про технологію створення сталевих балок, як правильно ламати бетон тощо. Програма була насиченою і поєднувала різні навчальні теми впродовж курсу.
Це була так звана відсіювальна програма, коли студенти починають здобувати спеціальність і згодом розуміють, що не стягують, і покидають навчання. Приблизно дві третини моїх одногрупників пішли, не завершивши чотирирічну програму.
Але мені все подобалось. Я дізнався багато речей з цілого спектру інженерії. Але було непросто — я ніколи в житті так важко не працював [сміється]. І гадаю, воно того вартувало.
— Як ви можете оцінити якість навчання у 1960-ті? Чи були якісь плюси порівняно з сучасним підходом до навчання інженерії?
Було по-різному. Дехто з викладачів відставав від сучасності, давав застарілий матеріал, і, вірогідно, загалом не встигав розвиватись в обраній сфері. Наприклад, у нас був предмет з вивчення вакуумних трубок — і це в 1963 році, коли транзистори вже існували. Тож деякі викладачі були не на висоті.
Деякі навчальні предмети видавалися другорядними. Втім багато з них містили фундаментальні знання. У нас було багато математики, зокрема прикладної, з ухилом в інженерію. Компʼютерних курсів не проводили, адже в ті часи компʼютерів у сучасному розумінні ще не існувало.
Проте деякі викладачі були дуже потужними. Один з них, професор електротехніки, якого мені довелось знати, став президентом Університету Торонто, це дуже серйозна посада. Тож склад викладачів був різним.
На мою думку, під час навчання у нас було забагато зубріння. Занадто багато професорів просто читали лекції, які студенти нотували й згодом за ними складали екзамени. Для мене було замало практичних завдань, навіть попри більш-менш регулярні лабораторні роботи.
— А яким був розподіл теоретичної та практичної частин навчання в ті роки?
Було потроху і того, і того. Наприклад, я памʼятаю курс з електромоторів, а це не та річ, яку інженери зазвичай вибирають для карʼєри [сміється]. Але ми навчились багатьох речей, повʼязаних з двигунами, а також шанобливого поводження з ними. Ось як виглядала одна з лабораторій цього курсу: на стелі можна було побачити дірки від того, що хтось зняв електропровідний контур двигуна, і той вибухнув.
Старт кар’єри в Bell Labs
— Професоре, ви працювали в Bell Labs, чиї проєкти серйозно вплинули на розвиток всієї сфери програмування. З чого розпочалася ваша робота в цій компанії?
Це була послідовність щасливих випадковостей. В той час я вже був аспірантом у Принстоні, добігав кінця мій другий рік аспірантури. 1966 року я проходив літнє стажування в MIT, яке мені запропонували тому, що за рік до цього аспірант з Принстона теж там стажувався і добре себе зарекомендував.
Під час стажування я перебував у групі розробників CTSS, або Compatible Time-Sharing System, які займалися Multics на дуже ранніх етапах. До прикладу, я опосередковано працював на Фернандо «Корбі» Корбато (відомий американський вчений, професор MIT, один з перших комп’ютерних розробників, який працював над CTSS та Multics — ред.), який 1990 року отримав премію Тюрінга. На жаль, його вже немає в живих.
Моя команда складалась з неймовірних людей, які робили надзвичайно цікаві речі. Тоді мені вперше вдалось попрацювати з Time-Sharing System. Я програмував мовою, що була кращою за всі попередні, які мені доводилось використовувати (CTSS підтримувала мову програмування MAD — ред.). І я розробляв те, що врешті використовували інші: це були утиліти, які допомагали під час роботи з Multics. Це був чудовий досвід.
Мені пощастило, і наступного літа я пройшов на стажування в офіс Bell Labs у Нью-Джерсі (у
Наступного літа 1968 року я повернувся в Bell Labs на інше стажування, під час якого працював з Шен Лінь над комбінаторною оптимізацією. Я, власне, розвʼязував проблему розбиття графів на підграфи, і деякі напрацювання за час роботи з Шен мені вдалося використати в дисертації та як Electrical Engineer вдало закінчити аспірантуру [сміється].
У Bell Labs за часів стажування мені дуже сподобалося, а з
Співробітниця дата-центру Bell Labs в Окленді в
— Можете згадати, яка робоча атмосфера панувала в Bell Labs у ті часи?
Місце чудове. Працювати було дуже весело, колеги були надзвичайно приємними. Це були перші роки комп’ютингу. Але наша компанія займалась не лише цим, в офісі Bell Labs у Мюррей-Гілл (Нью-Джерсі), що був комплексом зʼєднаних будівель, працювали щонайменше 3000 людей. Вони проводили дослідження з фізики, хімії, матеріалів, математики й трохи у сфері комп’ютингу. Середовище — відкрите, ми мали багато ресурсів, не було жодного браку грошей чи простору. Люди були щирі, радо одне одному допомагали. Якщо перед вами поставала проблема, ви могли пройтись коридором, зупинитись біля чийогось офісу (двері точно будуть відчинені) і поставити запитання. Співробітники Bell Labs були закохані у свою роботу і брали цікаві проєкти.
Люди постійно працювали, тому що їм це подобалось. До того ж компанія була частиною AT&T, телеком-корпорації, що на той час покривала більшість території Сполучених Штатів. Тоді AT&T мала надвеликий штат з близько мільйона співробітників. Водночас Bell Labs був R&D-центром, який налічував приблизно 30 тисяч людей. Дослідницька команда теж була доволі великою, від 1500 до 3000 осіб. Втім це була невелика частка від загального складу компанії.
На мою думку, переносити досвід тих днів на сьогодення важко. Нині часто можна почути «ресурсів багато, не хвилюйся», але рідко — «працюй над речами, які вважаєш важливими та цікавими». До того ж зараз побільшало короткострокових завдань, щось на кшталт: «Нам необхідно завершити розробку продукту впродовж кількох місяців, тож ви маєте спрямувати на це всі сили». Рушієм того, над чим люди працюють сьогодні, є радше ринковий тиск, ніж наукова допитливість.
Нині теж є великі технологічні компанії (хоча й не такі великі, яким був AT&T) на кшталт Google чи Microsoft, що мають дослідницькі центри з довгостроковими завданнями, але здебільшого сучасні компанії орієнтуються на короткотривалу перспективу, вони сфокусовані на нагальних речах та орієнтуються на зовнішні чинники, такі як ринок.
Таким я і запам’ятав Bell Labs у
— Тож у Bell Labs в той час фокус був здебільшого на інженерах, ніж на компанії?
Більшість людей працювали над розв’язанням проблем, які вони вважали цікавими, а не тому, що їм дали відповідне завдання. AT&T мала перевагу в тому, що була великою компанією з великою мережею, оскільки обслуговувала всю країну, тож мала постійне джерело прибутку. Коли ви комусь телефонували, то частина грошей йшла в Bell Labs на покращення телефонної мережі.
Втім у компанії ви могли працювати над безліччю речей, до того ж пояснювати необхідність цієї роботи. З-поміж іншого Bell Labs справді заохочувала людей до публікацій. Тож ви не просто займалися власними проєктами, а й могли писати про це статті для видань, книжки тощо. Можливо, це надмірно романтизоване бачення, але я запам’ятав цю компанію як чудове місце з великою кількістю неймовірних людей, які бралися за цікаві завдання.
Співробітники Bell Labs були закохані у свою роботу
— В той час ви також могли обирати проєкти, над якими хотіли працювати?
Так, по суті, ніхто не казав, які завдання виконувати. Очікували, що ви розроблятимете щось потенційно корисне для телеком-компанії, але людина могла працювати над чимось, що не мало очевидної [миттєвої] користі, протягом кількох років. І мені видається, що це було можливо завдяки освіченому з технічного погляду менеджменту. Наші керівники самі проходили весь кар’єрний шлях до менеджерських позицій і розуміли, що таке технології та невизначеність досліджень. Ви не можете сказати наперед, чи спрацює конкретний напрям досліджень, чи виявиться проєкт важливим.
До прикладу, Кен Томпсон серед іншого розробляв операційну систему UNIX, але водночас захоплювався комп’ютерними шахами. Він створив, ймовірно, найпершу робочу версію комп’ютерних шахів, а ще шахову програму, що першою в історії здобула титул майстра.
Якось я сидів у кабінеті з Кеном та його колегами, і повз проходив президент Bell Labs з екзальтованим відвідувачем компанії, який запитав: «Чому ви працюєте над шахами? Це ж геть не стосується телефонії». І тоді президент Bell Labs пояснив, що Кен створював важливі для розвитку індустрії спеціалізовані комп’ютери (Томпсон є розробником програмної частини шахового комп’ютера Belle — ред.), розробляв інструменти та ПЗ для них. Крім того, завдяки його здобуткам компанія була на слуху.
Як розробити власну мову програмування
— Професоре, ви відомі як співавтор AWK, інструмента текстового парсингу для UNIX, а також мови програмування AMPL. Як людям, що бажають створити мову програмування, правильно визначати порядок задач?
Вважаю найкращим способом почати — помислити над створенням спеціалізованої мови програмування. Навряд чи ви створите наступні C, Java або Python, натомість можете розробити спеціалізовану мову програмування з вузькою галуззю застосування; для розв’язання низки проблем, з якими стикаєтесь під час роботи.
Ви згадали AWK, яка є простою мовою для легкої обробки рядків символів і чисел. AMPL призначена для базових оптимізаційних задач, таких як лінійне програмування. Отже, обидві мови є спеціалізованими, вони не схожі на C, Java чи Python, які можна використовувати для будь-яких завдань.
Перевага спеціалізованої мови полягає в тому, що вона буде меншою за обсягом коду. Якщо ви вже взялись за величезний проєкт, подумайте над переформатуванням цього у щось менше. Якщо мова застосовуватиметься у вузькій галузі, ви матимете змогу розробити унікальні механізми її роботи, власний синтаксис тощо.
Беручись за розробку мови, спитайте себе: «Для чого я намагаюсь її розробити? Як люди говорять про розв’язання проблем у цій галузі? Чи використовують вони математичні терміни (що ви робите, наприклад, при описі оптимізаційних задач)? Чи використовують вони текстові шаблони?».
Якби ми з вами розмовляли про щось математичними термінами, то я б використовував фрази на кшталт «xᵧ» або «приплюсуй це до того». І саме це вам треба зробити для створення своєї мови — зрозуміти, як люди комунікують або думають про свою роботу, і зафіксувати це в граматиці, синтаксисі мови. Після цього ви зможете сказати: «Ось які вирази я використовую в межах мови для розв’язання конкретної задачі». 
І ви тестуєте це на стількох прикладах, скільки зможете вигадати, а потім реалізуєте це. Можна використовувати інструменти розробки мови, такі як Yacc (компілятор компіляторів, який дуже давно розробили в Bell Labs), ANTLR (це сучасніший парсер). Ці інструменти допомагають пришвидшити створення мови та простіше вносити зміни, якщо ви передумали — «Це не той синтаксис, я хочу зробити щось інше».
А потім ви просите людей її протестувати й дивитесь на їхню реакцію [сміється]. Вони спробують вашу мову, дадуть зворотний зв’язок, завдяки якому ви зможете щось скоригувати у власній розробці. І згодом, якщо вам пощастить, проєкт «злетить». А якщо ні — це теж нормально.
— Тож суть така: якщо бажаєте створити мову програмування, визначте конкретну проблему, яку ви хочете розв’язати за допомогою неї.
Вам варто подумати про те, в якій сфері використовуватимуть мову. Якось давно я хотів мати спосіб коректно записувати математичні вирази. Подивімось на LaTeX (мова розмітки даних, яка фактично є стандартом для підготовки математичних і технічних текстів до публікації в наукових виданнях — ред.). Як розмовляють математики? Хоча я й не математик, але прослухав багато курсів з цієї науки та спілкувався з експертами. Вони послуговуються такими виразами, як «X поділити на Y». І коли професор стоїть перед аудиторією та пише загадкові речі на дошці або каже «X/Y = π/2» — це і є ваша мова. Вам залишається її формалізувати. І це одна з речей, яку варто добре розуміти.
Але ось що справді є проблемою, це коли ви питаєте себе: якою має бути мова? Наприклад, ви хочете малювати за допомогою неї картинки. А як описати за допомогою коду малюнки, блок-схеми, організаційні діаграми тощо? Тут є сенс просто пробувати та сподіватись, що ви все робите правильно.
З чого народились книги з C та UNIX
— Готуючись до цього інтерв’ю, я поцікавився у своєї подруги-розробниці, яка захоплюється вашими книжками з C та UNIX, що їй в них подобається. Дозвольте процитувати її слова: «Книги дуже зрозуміло і послідовно написані, нічого зайвого, водночас вони цікаві; і всі знання, здобуті завдяки цим книгам, досі зі мною». Чи стояла за цим свідома філософія створення «прикладних» книжок?
Гадаю, я дійшов до цього випадково. Я починав у Bell Labs з написання інструкцій для співробітників, коротких документів з поясненнями, як користуватись тими чи іншими розробками. Наприклад, у нас був текстовий редактор на UNIX, і його використовували люди, які не були дуже технічно підковані, зокрема секретарі. І я написав інструкцію для секретарів, які не є комп’ютерними фахівцями, як користуватися цим текстовим редактором. Щось схоже я зробив і для кількох мов програмування.
Зрештою я написав підручник з мови С, щоб допомогти людям, які не є експертами та не належать до тих, хто використовує С на щоденній основі, але хочуть вміти нею користуватися. Саме такі короткі інструкції, що містили до 20 сторінок, згодом стали основою моїх книжок, зокрема The C Programming Language.
Примірники книги Браяна Кернігана і Денніса Рітчі The C Programming Language
Питання полягає в тому, завдяки яким прикладам людина, яка геть не має знань у цій галузі, зможе почати використовувати мову програмування? Якою є найпростіша послідовність кроків, аби розібратися в новій мові? Я схильний відшукувати послідовність практичних прикладів, які «справжні програмісти», можливо, захочуть відтворити, коли писатимуть програми новою мовою. А потім створити довкола цих прикладів текстове пояснення, що розповість про властивості мови, які допомагають розв’язати конкретну проблему, порушену в прикладі.
Мені здається, більшість книг з програмування були побудовані якраз на релевантних прикладах. І я намагався не вигадувати приклади на кшталт «Ось синтаксис тієї чи іншої комп’ютерної команди», тому що це дуже нудно. Ви не можете собі навіть уявити наскільки [сміється]. Я завжди намагався отримати «живі», робочі взірці. Хоча це і вдається не завжди, інколи ти думаєш: «Ох, це просто жахливо!»
У програмуванні часто є місця, де ви не можете говорити про умовне «Х», перед цим не розібравшись в «Y». Але водночас ви не можете послуговуватись «Y», не розібравшись у «Х». Виникає замкнуте коло, безвихіддя. Тож ви просто обираєте одну з цих послідовностей дій і просите читачів повернутись до іншої частини прикладу пізніше.
Про те, що мови програмування не вмирають
— Нещодавно компанія Google анонсувала нову мову програмування Carbon, яка має стати наступницею мови С++. Чи мали ви нагоду ознайомитися з документацією до нової мови?
У певному сенсі створити нову мову програмування дуже легко (але, звісно, не таку, що замінить С++ — це велика робота). Проблема в тому, що існує надто багато мов, і через деякий час я просто перестав встигати стежити за ними. Я невиразно пам’ятаю назву Carbon, але жодного разу не ознайомлювався з нею.
Гадаю, наївно очікувати, що вона замінить С++. Проблема в тому, що в С++ вже занадто багато коду. Я не знаю точно, але посперечаюся, що у Google можна знайти мільярд рядків коду на С++ — їх ніяк не заміниш, цього ніколи не станеться. Можливо, на Carbon писатимуть нові програми, віднайдуть способи інтегрувати код «плюсів» у Carbon, щоб програми на старому коді поволі еволюціонували... Однак саме заміни C++ ніколи не буде.
І ви це вже бачите. Подивіться на кількість програм, написаних тією ж С, якій вже 50 років. Їх не замінюють, тому що це занадто складно, а свою функцію такі застосунки виконують. Звісно, новіші програми можуть бути написані більш сучасними мовами, але старі мови... Я не думаю, що вони колись помруть.
Запитайте у своєї подруги-розробниці: які мови програмування померли? Я не впевнений, що такі існують. Хіба що можу пригадати PL/I, яка була популярною в
— Я поставив попереднє запитання, тому що мені цікаво: чи справді так звані класичні мови програмування морально застарівають і є потреба замінити їх на нові?
Старі мови схильні еволюціонувати. Так, Fortran і COBOL, створені в
Мови, як правило, не вмирають — вони еволюціонують і вбирають у себе щось нове. І на оновлення однієї мови може мати великий вплив напрацювання в межах іншої мови — відбувається своєрідний обмін ідеями.
— Схожа ситуація з природними мовами, якими ми спілкуємось у житті...
Саме так.
Про власний курс у Принстоні
— Ви приєдналися до викладацького складу Принстонського університету у 2000 році й з того часу викладаєте курс «Комп’ютери в нашому світі». Можете трохи розповісти про цей курс і як він змінився за 20 років?
Цей курс призначений для людей, до сфери інтересів яких не входять технології. Деякі мої студенти ніколи не стануть програмістами і, ймовірно, ніколи не використовуватимуть комп’ютери, крім як у повсякденному житті. Типовий слухач мого курсу — це людина, яка вивчає історію або літературу, музику. Є багато студентів з гуманітарних факультетів. Університет вимагає, щоб усі студенти пройшли курс з категорії «Кількісні та обчислювальні міркування» . Мій курс задовольняє цю вимогу, тож деякі люди обирають його, щоб виконати це правило університету.
У цьому курсі я намагаюся пояснити, що таке комп’ютерні обчислення і комунікації, адже це надважливі складові сучасного світу. Ми з вами розмовляємо попри те, що нас розділяє цілий континент. Отже, це важлива частина життя кожного з нас. Іноді в дуже позитивному сенсі, а іноді — в негативному.
І більшість цих студентів обійматимуть ті чи інші керівні посади. Вони будуть політиками, керівниками компаній, вчителями тощо та впливатимуть на інших. Тож хіба не буде добре, якщо вони знатимуть щось про технології, від яких ми всі залежимо?
Наведу випадковий приклад: Верховний суд Сполучених Штатів наразі налічує 9 членів. Не беручи до уваги їхню політичну належність, троє з них — випускники Принстона. Отже, вони могли б бути слухачами мого курсу, якби я розпочав його на 20 років раніше. І це могло б мати потенційний вплив на них. Хіба це не допомогло б їм ухвалювати кращі рішення? Наприклад, близько року тому Верховний суд слухав справу «Oracle проти Google». Це було технічне питання, і я думаю, що судді ухвалили правильне рішення.
Довідка
2010 року технологічна корпорація Oracle подала позов до суду, звинувативши Google у несанкціонованому використанні скопійованого коду Java API в операційній системі Android. Oracle хотіла домогтись сплати збитків з боку Google у розмірі 8,8 мільярда доларів США.
Після тривалого розгляду 2021 року Верховний суд США ухвалив рішення на користь Google та постановив, що скопійована частина Java API підпадає під доктрину про добропорядне використання.
Ця справа стала знаковою для технологічної індустрії, оскільки багато програм і бібліотек написані з частковим використанням або відтворенням сторонніх API.
Ось як пояснити студенту-філологу, що таке API? Я розповідаю їм про апаратне забезпечення; про те, як працює комп’ютерне обладнання, аж до рівня інтегральних схем, а потім про те, як комп’ютери обчислюють тощо. Потім ми говоримо про програмне забезпечення і деякі абстрактні речі, такі як алгоритми. Як швидко ви можете щось обчислити? Що у технологіях є складним, що легким, а що — неможливим?
А ще ми розбираємо сторонні програми, операційні системи, те, як влаштовані мови програмування. Також я трохи навчаю їх Python. Вони не стануть професіоналами в розробці завдяки цьому, але принаймні не матимуть ілюзій щодо технологічної галузі.
Тож коли мої студенти обійматимуть керівні позиції, вони матимуть уявлення про те, що означає писати програму і чому це легко чи складно, як про це розповісти. Вони краще розумітимуть, коли технічні спеціалісти говоритимуть їм неправду.
І далі в межах курсу ми проходимо тему комунікацій: телефонні системи та інтернет (які на цьому етапі злилися), як він працює тощо. І про всі ті цікаві, дуже актуальні, часто небезпечні речі, які уможливлює інтернет. З хорошого — ми з вами можемо спілкуватися. З поганого: нескінченна кількість соціальних мереж, посягання на приватне життя; хто знає, на скільки воєн ця технологія вплинула. Тому я хочу, щоб мої студенти знали про це.
— Це справді важливий досвід для будь-якого майбутнього фахівця. Чи є серед ваших студентів українці?
Одна з першокурсниць, яку я консультую, — молода дівчина з України. Я хотів би незабаром з нею познайомитися наживо. На жаль, з огляду на нинішню ситуацію я не знаю, чи вона в США, чи все ще перебуває в Україні. Сподіваюся, що вона тут і в безпеці.
Як відбувався розвиток комп’ютерних технологій
— Ви мали змогу бачити, як розвивалася світова ІТ-індустрія протягом десятиліть. Які її віхи ви для себе відзначили?
Комп’ютери дуже швидко розвивалися і ставали все меншими за розмірами. Зростала кількість працівників в ІТ. І ось тепер ПК є повсюдно.
Коли я починав працювати з комп’ютерами, це були великі мейнфрейми, такі як IBM 7090 та IBM 360. Вони займали величезні кімнати, мали систему охолодження, прикріплених до них операторів і коштували мільйони доларів навіть 60 років тому. Це були гігантські штуки.
І з розвитком апаратного забезпечення вони ставали все меншими. Система UNIX була розроблена на PDP-11 — комп’ютері, який на той час, на початку
А потім з’явився ринок робочих станцій з такими компаніями, як Sun Microsystems, і ви могли отримати доволі потужний комп’ютер за ціною близько 10 тисяч доларів.
І, напевно, найбільші зміни відбулися з появою IBM PC 1981 року. Бо це означало, що кожен з нас міг отримати персональний комп’ютер. І це дало свободу створювати багато непересічних речей, а не лише здійснювати бізнесові чи наукові обчислення.
IBM PC з монітором CGA (модель 5153), клавіатурою і принтером IBM 5152
Іншою річчю, яка майже паралельно розвивалася в ті роки, було мережеве з’єднання. Все почалося з мережі ARPANET в 1969 році, яка врешті перетворилась на інтернет в середині
Втім просто зараз, на жаль, ми бачимо, що попри запевнення [перших телеком-компаній] у тому, що кожен матиме свою обчислювальну та комунікаційну систему, розвиток цієї сфери дедалі більше залежить від гігантів індустрії, які можуть мати на меті ненайкращі речі. Ще один момент, назвемо це геополітикою, — фрагментація комунікацій. Це те, що ми бачимо сьогодні в росії, Китаї та багатьох інших частинах світу.
Чи може Україна стати державою продуктового IT
— Я поставив попереднє запитання, тому що в нашій країні поширена думка, що в Україні бракує «продуктового мислення». Ми можемо надавати ІТ-послуги, але нам не вдається створювати інноваційні продукти такого рівня, як це роблять Apple, Amazon чи Google. Чи є це проблемою, на вашу думку? Або ж це нормальна ситуація, оскільки інноваційні продукти не можуть так швидко з’являтися на ринку?
Меншим за США країнам, напевно, важко створювати продукти з великою швидкістю. І в такому разі сервісний шлях в IT — це природно. Іноді це приводить до створення продукту. Я виріс у Канаді, і вона, мабуть, чимось схожа на Україну. Там важко конкурувати й починати щось нове, коли ти протистоїш таким компаніям, як Apple, Google абощо. Але це можливо. Наприклад, Blackberry, який довгий час був популярним телефоном, розробили в Канаді. Nokia у Фінляндії зуміла розбудувати пристойну телефонну індустрію навіть у країні з дуже невеликим населенням. Але я думаю, що це радше виняток, аніж правило.
Інфраструктура та ресурси, необхідні для виробництва апаратного та програмного забезпечення, як це робить Apple, вимагають величезних інвестицій та глобального доступу до всіх видів речей, які є в Apple у Сполучених Штатах.
— Наш уряд хоче збалансувати розвиток сервісних та продуктових ІТ-компаній, щоб їхній розподіл на ринку становив хоча б 50/50. Мені просто цікаво, чи це можливо, або ж це нездійсненна мрія?
Я дещо підозріло ставлюся до державного контролю за економікою. Це не дуже добре спрацювало в різних країнах не так далеко від вас. І не так далеко від мене теж [сміється]. Я думаю, що ринок сам визначить найкращий шлях. Уряд повинен забезпечити певне «ігрове поле» і передбачувані та стабільні правила гри; і винагороджувати за добру поведінку та розробити певний механізм покарання за погану. Все це дуже важко. Люди пробували протягом 10 тисяч років — і їм досі не вдалося це зробити як слід :)
Поточні проєкти
— Професоре, я знаю, що ви все ще вносите правки до основного коду AWK. Чи є ще якісь проєкти, над якими ви зараз працюєте?
Я працюю над кількома речами, зокрема над доповіддю до конференції Document Engineering, що відбудеться у вересні.
Крім того, ми з колегами почали досліджували історію дисертації Денніса Рітчі, винахідника мови програмування С, який помер 11 років тому. Фізичний примірник його дисертації в кількох копіях знайшли в його робочих документах; ця робота так і не потрапила в Гарвард (Рітчі захищав докторську дисертацію в Гарварді, але не зміг офіційно здобути ступінь, оскільки не надав переплетену копію своєї дисертації університету — ред.).
Музей комп’ютерної історії опублікував його дисертацію кілька років тому, тож ви теж можете побачити її в інтернеті. Втім нас цікавили певні технічні питання, як він зробив цю дисертацію, — адже вона надскладна з погляду типографіки, це 180 сторінок теорії рекурсивних функцій, це просто загадка... Уявіть: підрядкові знаки на підрядкових знаках, на надрядкових і підрядкових знаках... Кожна сторінка математично складна.
І цей текст, напевно, був надрукований на електричній друкарській машинці, але невідомо, чи використовував він ще й комп’ютер для цього... Рітчі написав дисертацію приблизно 1967 року, а ми досі не знаємо, як він це зробив. Але це дивовижний зразок складної типографіки в той час, коли люди ще не використовували комп’ютери для такого друку.
