Мій досвід роботи з Ліспом і розвиток GNU Emacs

---

Оскільки жодна з моїх звичайних промов не має ніякого відношення до Ліспа, то ні одна з них не підходить для сьогоднішнього виступу. Тому мені доведеться імпровізувати. Позаяк у своїй професійній діяльності мені доводилося виконувати досить багато роботи, пов'язаної з Ліспом, у мене, мабуть, є що розказати.

Моя перша зустріч з Ліспом сталася, коли я прочитав посібник Ліспа 1.5 у старших класах. Саме тоді мене вразила ідея, що може бути така мова програмування. Можливість зробити що-небудь на Ліспі вперше з'явилася у мене, коли я був на молодших курсах в Гарварді і писав інтерпретатор Ліспа для PDP-11. Це була дуже маленька машина: у ній було десь біля 8 кБ пам'яті — й мені вдалося написати інтерпретатор довжиною в тисячу команд. Це залишало мені трохи місця для даних. Це було до того, як я дізнався, як виглядають справжні програми, які виконують справжні системні завдання.

Я почав виконувати роботи над справжньою реалізацією Ліспа з Джоном-Л Уайтом відразу, коли мене прийняли у MIT. Туди мене прийняв не Джон-Л, а Расселл Нофтскер, що було вельми іронічно з огляду на те, що трапилося згодом — він, імовірно, сильно про це шкодував.

У сімдесятих роках XX століття, до того, як огидні події політизували моє життя, я просто писав розширення до різноманітних програм, більшість із яких не мали жодного стосунку до Ліспа. Але водночас я писав текстовий редактор Emacs. Цікава думка, закладена в Emacs, полягала в тому, що в ньому була мова програмування, і користувацькі команди редагування писалися на цій інтерпретованій мові програмування, тому під час редагування у редактор можна було завантажувати нові команди. Можна було підредагувати програми, якими користуєшся, а потім продовжувати редагувати ними. Отже, у нас була система, корисна не для програмування, і все-таки під час користування нею можна було програмувати. Я не знаю, чи це була перша така система, але це точно був перший такий редактор.

Ця атмосфера побудови гігантських, складних програм для застосування в своєму власному редагуванні, а потім обміну ними з іншими людьми, живила дух вільної співпраці, який панував тоді в Лабораторії штучного інтелекту. Ідея була в тому, що можна передати копію програми, що в тебе є, тому, кому вона потрібна. Ми обмінювалися програмами з усіма, хто тільки хотів ними користуватися, програми були людським знанням. Отож, хоча і не було організованої політичної думки, яка б поєднувала те, як ми обмінювалися програмами, з облаштуванням Emacs, я переконаний, що між ними був зв'язок — можливо, неусвідомлений. Я думаю, що саме природа нашого способу життя в Лабораторії штучного інтелекту привела до створення Emacs і зробила його таким, яким він був.

У первісному Emacs Ліспа не було. Мовою низького рівня — неінтерпретованою мовою — був асемблер PDP-10. Інтерпретатор, який ми писали, насправді писався не для Emacs, він писався для TECO. Це були наші текстовий редактор і вкрай потворна мова програмування — настільки потворна, наскільки це взагалі можливо. Причина була в тому, що вона не була спроектована як мова програмування, а натомість як мова редактора і команд. Були такі команди, як 5l, що означало пересунутися на п'ять рядків, або i з наступним рядком та ESC для того, щоб вставити цей рядок. Можна було набрати рядок, який був послідовністю команд, який називався командним рядком. Тоді ви двічі натискали ESC — і послідовність виконувалася.

Втім люди хотіли доповнити цю мову засобами програмування, тому вони додали деякі засоби. Наприклад, однією з перших була додана конструкція циклу: < >. Нею оточували команди, і це був цикл. Були інші незрозумілі команди, якими можна було користуватися для умовного виходу з циклу. При створенні Emacs ми [1] додали можливість створення підпрограм з іменами. До того це був ніби Бейсик, а в назвах підпрограм могло бути тільки по одній букві. Писати на цьому великі програми було важко, тому ми дописали програму, щоб у них могли бути довгі назви. Насправді там були доволі хитромудрі засоби; здається, засіб “unwind-protect” Лісп запозичив з TECO.

Ми почали закладати досить хитромудрі засоби, і у всіх у них був потворний синтаксис, який тільки-но можна придумати, і це працювало — люди все одно були у змозі писати на цьому великі програми. Очевидним уроком було те, що така мова, як TECO, неспроектована як мова програмування,— є хибним шляхом. Мова, на якій ви будуєте свої розширення, повинна замислюватися як мова програмування не заднім числом; її відразу слід проектувати як мову програмування. Фактично, ми виявили, що найкращою мовою програмування для цих цілей був Лісп.

Це відкрив Берні Грінберг [2]. Він написав версію Emacs на MacLisp в Multics, і написані ним MacLisp-команди були прості й зрозумілі. Сам редактор був повністю написаний на Ліспі. Emacs для Multics мав великий успіх — програмування нових команд редагування було таким зручним, що навіть секретарки в його конторі почали навчання користуванню ним. Вони користувалися написаним кимось посібником, у якому було показано, як доповнювати Emacs, але там не говорилося, що це програмування. Тому секретарок, які думали, що не можуть програмувати, це не відлякувало. Вони читали посібник, виявляли, що можуть робити щось корисне, і вчилися програмувати.

Отож, Берні зрозумів, що застосунок — програма, яка робить щось корисне для вас — всередині якої був Лісп і яку ви можете доповнювати, переписуючи програми на Ліспі, — насправді дуже хороший спосіб навчитися програмувати. Це дає людям можливість писати невеликі програми, які для них корисні; інші середовища не дають вам такої змоги. Вони можуть отримувати заохочення від практичної користі для них самих на стадії, де це найважче — коли вони не думають, що можуть програмувати, — поки вони не дійдуть до точки, в якої вони вже стали програмістами.

У цей момент люди почали міркувати, як отримати щось подібне на платформі, де у них не було повної реалізації Ліспа. У MacLisp для Multics був компілятор та інтерпретатор — це була повністю оснащена система Лісп — але людям кортілося впровадити подібне на інших системах, де у них не було вже написаного компілятора Ліспа. Ну, якщо у вас немає компілятора Ліспа, ви не можете написати весь редактор на Ліспі — він був би занадто повільним, особливо перемальовування, якби довелося виконувати Лісп на інтерпретаторі. Через це ми розробили гібридну техніку. Ідея полягала в тому, щоб писати інтерпретатор Ліспа й низькорівневі частини редактора разом: тоді частини редактора ставали вбудованими засобами Ліспа. Це були б будь-які частини, в оптимізації яких ми відчували необхідність. Цю методику ми вже свідомо практикували у первісному Emacs, тому що були певні вельми високорівневі функції, які ми втілили ще раз на машинній мові, переробивши їх на примітиви TECO. Наприклад, був примітив TECO для заповнення абзацу (насправді лише для основної роботи з заповнення абзацу, тому що деякі з менш ресурсомістких робіт виконувалися на вищому рівні програмою TECO). Можна було б виконувати всю роботу програмою, написаною на TECO, але це було занадто повільно, тож ми оптимізували це, перенісши частину програми на машинну мову. Тут (у гібридній техніці) ми скористалися тією ж ідеєю: велика частина редактора буде написана на Ліспі, але певні його частини, які потрібно було виконувати особливо швидко, будуть написані на низькому рівні.

Таким чином, коли я писав свою другу реалізацію Emacs, я дотримувався цієї схеми. Мова низького рівня більше не була машинною мовою, це був Сі. Сі виявилася доброю, ефективною мовою для переносних програм, призначених для виконання у операційних системах на кшталт Unix. Там був інтерпретатор Ліспа, але я реалізував засоби для вирішення спеціальних завдань редагування безпосередньо на Сі — сюди входили маніпуляція буферами редактора, вставка тексту на початок, читання і запис файлів, оновлення буфера на екрані, управління вікнами редактора.

До речі, це був не перший Emacs, написаний на Сі й виконуваний на Unix. Перший — GosMacs — був написаний Джеймсом Гослінгом. З ним трапилася дивна історія. Спочатку він, здавалося, перебував під впливом тієї ж самої атмосфери обміну і співробітництва початкового Emacs. Я спочатку випускав початковий Emacs для людей в Массачусетському технологічному інституті. Дехто захотів перенести його на Twenex — спочатку редактор працював тільки у Несумісній системі поділу часу, якою ми користувалися в інституті. Вони перенесли його на Twenex, і це означало, що в світі було кілька сотень обчислювальних систем, в яких потенційно можна було його застосовувати. Ми почали поширення серед них із правилом “ви повинні надсилати назад свої поліпшення”, щоб ми всі могли отримувати з цього користь. Ніхто ніколи не намагався стежити за дотриманням цього, але наскільки я знаю, люди дійсно співпрацювали.

І Гослінг, на перших порах, здавалося, брав у цьому участь. Він написав підручник, в якому він називав цю програму Emacs, сподіваючися, що інші члени співтовариства будуть покращувати її, поки вона не заслужить цієї назви. Це був правильний підхід до спільноти — просити їх приєднатися і поліпшувати програму. Але після цього його ставлення, здається, змінилося, і він продав програму одній компанії.

В цей час я працював над системою GNU (вільною операційною системою типу Unix, яку багато хто помилково називає “Linux”). Вільного редактора Emacs, який працював би в Unix, не існувало. Проте був у мене знайомий, який брав участь у розробці Emacs Гослінга, котрий надав йому е-поштою дозвіл поширювати власну версію. Знайомий запропонував мені скористатися цією версією. Тоді я виявив, що в Emacs Гослінга не було справжнього Ліспа. В ньому була мова програмування, відома як “mocklisp”, вона синтаксично виглядає як Лісп, але в ній немає структур даних Ліспа. Тому програми не були даними і не вистачало життєво важливих елементів Ліспа. Його структурами даних були рядки, числа і деякі інші спеціалізовані об'єкти.

Я дійшов висновку, що користуватись цим неможливо, тож був змушений замінити це все. Першим кроком було написання справжнього інтерпретатора Ліспа. Я поступово перебазував кожну частину редактора на справжні структури даних Ліспа замість вузькоспеціалізованих структур даних, створивши можливість виведення внутрішніх структур даних редактора і маніпуляцій ними у користувацьких програмах на Ліспі.

Єдиним винятком був показ на дисплеї. Довгий час оновлення дисплея було ніби іншим світом. Редактор вступав у світ перемальовування, і все починало проводитися над абсолютно особливими структурами даних, для яких не було безпечного збору сміття, не було безпечних переривань, і в цей час не можна було виконувати ніяких програм на Ліспі. З тих пір ми це змінили: зараз можна виконувати програми на Ліспі під час перемальовування. Це дуже зручно.

Ця друга програма Emacs була “вільною програмою” в сучасному розумінні цього слова — вона була частиною відкритої політичної кампанії за звільнення програм. Сутність цієї кампанії полягала в тому, що кожен має право вільно робити те, що ми у старі часи робили в Массачусетському технологічному інституті, працюючи разом над програмами і працюючи з усіма, хто тільки бажав працювати з нами. Це стало основою руху за вільне програмне забезпечення — на основі досвіду мого життя в Лабораторії штучного інтелекту — працюйте над людським знанням і не стовбичте ні в кого на шляху до подальшого застосування та подальшого поширення людського знання.

В цей час можна було зробити комп'ютер, який коштував приблизно стільки ж, скільки інші комп'ютери, не призначені для Ліспа, але він виконував би Лісп набагато швидше, ніж вони, і при цьому з повною перевіркою типів на кожній операції. Звичайні комп'ютери, як правило, змушували вибирати між швидкістю виконання і хорошою перевіркою типів. Отож, звичайно, можна було отримати компілятор Ліспа і швидко виконувати програми, але коли вони намагалися взяти car від числа, це призводило до безглуздих результатів і врешті-решт коли-небудь призводило до збою.

Машина Ліспа була в змозі виконувати команди майже так само швидко, як ті інші машини, але кожна команда, як-от car, перевіряла типи даних — тому коли ви намагалися взяти car від числа у скомпільованій програмі, це негайно давало помилку. Ми побудували машину і у нас була для неї операційна система на Ліспі. Вона майже повністю була написана на Ліспі, за винятком частин, записаних мікрокодом. Виник інтерес до виробництва машин, а це означало, що потрібно створити компанію.

Було два різних уявлення про те, якою повинна бути ця компанія. Грінблет хотів створити те, що він називав “хакерською” компанією. Це означало, що компанією керували б хакери сприятливим саме для хакерів чином. Іншою метою була підтримка культури Лабораторії штучного інтелекту [3]. На жаль, у Грінблета не було ніякого ділового досвіду, тому інші люди з групи машини Ліспа говорили, що вони сумніваються в його спроможності це зробити. Вони думали, що уникнути зовнішніх капіталовкладень, як він планував, не вдасться.

Але чому він хотів уникнути зовнішніх капіталовкладень? Тому що коли у компанії є зовнішні вкладники, вони беруть контроль в свої руки і не дозволяють вам бути педантичним; а якщо ви скільки-небудь педантичні, то вони врешті-решт поставлять на керівну посаду кого-небудь іншого.

Отож, у Грінблета була думка, що він знайде клієнта, який платитиме за складники наперед. Вони збирали б машини й поставляли їх йому; отримуючи таким чином дохід із цих складників, вони змогли б купувати складники ще для декількох машин, продавати їх і купувати складники для більшого числа машин тощо. Інші люди з групи думали, що так працювати не вийде.

Грінблет залучив Расселла Нофтскера, людину, яка найняла мене, а згодом пішла з Лабораторії штучного інтелекту і створила прибуткову компанію. Вважалося, що у Расселла є ділова хватка. Він продемонстрував цю ділову хватку, сказавши людям в групі: “Давайте кинемо Грінблета, забудемо про його ідеї й створимо іншу компанію”. Вдарив у спину, зовсім як справжній підприємець. Ці люди вирішили сформувати компанію під назвою “Symbolics”, залучати зовнішній капітал, не бути педантичними і робити все можливе, щоб перемогти.

Але Грінблет не відступив. Він і деякі лояльні по відношенню до нього люди вирішили все одно утворити Lisp Machines Inc. і працювати за своїм планом. І що б ви думали? Їм це вдалося! У них з'явився перший клієнт, і їм заплатили наперед. Вони збирали машини, продавали їх і збирали ще і ще. Врешті-решт вони стали на ноги, незважаючи на те, що більшість людей в групі їм не допомагали. Компанія Symbolics також почала успішну діяльність, тобто дві компанії конкурували у виробництві Лісп-машин. Коли в Symbolics зрозуміли, що LMI не думає вилітати в трубу, вони стали шукати способи зруйнувати її.

Таким чином, за відходом з нашої лабораторії настала “війна” в нашій лабораторії. Відхід стався, коли компанія Symbolics переманила всіх хакерів, крім мене і тих, хто за сумісництвом працював у LMI. Потім вони встановили правило і виключили тих, хто за сумісництвом працював в інституті, тому їм довелося піти повністю, і я залишився один. Тепер Лабораторія штучного інтелекту була безпорадна. А інститут уклав з цими двома компаніями одну дуже дурну угоду. Це був тристоронній договір, у якому обидві компанії ліцензували вихідні тексти системи машини Ліспа. Ці компанії повинні були надавати свої зміни в користування інституту. Але в договорі не говорилося, що інститут має право розміщувати їх в системах своїх Лісп-машин, які ліцензували обидві компанії. Ніхто не передбачав, що групу хакерів Лабораторії штучного інтелекту розженуть, але так і сталося.

Отже, в Symbolics дозрів план [4]. Вони сказали лабораторії: «Ми продовжимо надавати у ваше користування свої зміни в системі, але вам не можна розміщувати їх в системі Лісп-машини інституту. Замість цього ми надамо вам доступ до системи Лісп-машини Symbolics, і ви зможете працювати на ній, але це все, що ви можете робити.»

Це фактично означало, що вони зажадали від нас стати на той чи інший бік і користуватися або версією інституту, або версією Symbolics. Що б ми не вибрали, це визначало б, в яку систему підуть наші удосконалення. Якби ми працювали над версією Symbolics і вдосконалювали її, ми підтримували б тільки Symbolics. Якби ми користувалися версією інституту і вдосконалювали її, ми надавали б роботу в розпорядження обох компаній, але в Symbolics вважали це підтримкою саме LMI з нашого боку, тому що ми допомагали б їм продовжувати існування. Отож, нам не дозволили залишатися нейтральними.

Аж до цього моменту я не приймав сторону жодної з компаній, хоча мені було боляче бачити, що сталося з нашим співтовариством і програмами. Але тепер компанія Symbolics примушувала мене до цього. Отже, намагаючись допомогти компанії Lisp Machines Inc. втриматися на плаву [5], я почав дублювати всі поліпшення в системі машини Ліспа, які робили в Symbolics. Я писав еквівалентні поліпшення сам (тобто тексти програм були моїми власними).

Через деякий час [6] я дійшов висновку, що краще за все навіть не заглядати в їхні тексти. Коли вони оголошували про випуск випробувальної версії й описували її нововведення, я дивився, які там були функції, а потім впроваджував їх. До того часу, як вони випускали остаточну версію, я теж випускав таку версію.

Таким чином, протягом двох років я не давав їм покінчити з LMI, і обидві компанії продовжували роботу. Але я не хотів витрачати довгі роки на те, щоб покарати когось, просто заважаючи злій справі. Я побачив, що вони покарані досить ґрунтовно, тому що вони натрапили на конкуренцію, яка не йшла і не збиралася зникати [7]. Тим часом настала пора почати облаштування нового співтовариства замість того, яке було знищено їхніми діями та діями інших.

У сімдесятих роках співтовариство Ліспа не обмежувалося Лабораторією штучного інтелекту Массачусетського технологічного інституту, і не всі хакери були в цьому інституті. Війна, яку розпочала компанія Symbolics, спустошила Массачусетський технологічний інститут, але в той час відбувалися й інші події. Люди припиняли діяти спільно, і все це разом спустошило наше співтовариство, і від нього майже нічого не залишилося.

Припинивши карати Symbolics, мені довелося планувати наступні дії. Мені потрібно було зробити вільну операційну систему, це було ясно — єдиним способом дати людям спільно працювати і обмінюватися була вільна операційна система.

Спершу я думав про створення системи на базі Ліспа, але усвідомив, що з технічної точки зору це не добре. Щоб отримати щось подібне до системи машини Ліспа, потрібен мікрокод спеціального призначення. Саме це дозволяло виконувати програми так само швидко, як інші комп'ютери виконували свої програми, і при цьому ще й користуватися перевіркою типів. Без цього усе звелося б до чогось на кшталт компіляторів Ліспа для інших машин. Програми були б швидшими, але водночас нестабільними. Так от, це припустимо, якщо виконувати одну програму на системі з поділом часу — якщо одна програма дає збій, це не катастрофа, це щось цілком очікуване від програми. Але це робило її не досить гарною, щоб писати на ній операційну систему, тому я відмовився від думки про те, щоб зробити систему на взірець Лісп-машини.

Замість цього я вирішив зробити операційну систему типу Unix, в якій були б реалізації Ліспа для виконання користувацьких програм. Ядро було б написаним не на Ліспі, але Лісп у нас був би. Тому сама розробка цієї операційної системи, операційної системи GNU, привела мене до написання GNU Emacs. В процесі цього я прагнув зробити абсолютно мінімально можливу реалізацію Ліспа. Розмір програм мав надзвичайне значення.

У той час, у 1985 році, в деяких людей ще були одномегабайтові машини без віртуальної пам'яті. Вони хотіли бути в змозі використовувати GNU Emacs. Це означало, що мені потрібно було робити програму якнайменшою.

Наприклад, у той час єдиною циклічною конструкцією була while у примітивній формі. Не було ніяких способів дострокового виходу з оператора while: доводилося просто користуватися механізмом винятків або перевіряти змінну в циклі. Це показує, як далеко я зайшов у обмеженнях на розмір. У нас не було caar, cadr тощо; “вичавити все можливе” — таким духом був просякнутий GNU Emacs і його Лісп з самого початку.

Зрозуміло, машини зараз більші, тож ми вже так не робимо. Ми заклали caar, cadr і так далі, і зараз при нагоді ми могли б закласти іншу циклічну конструкцію. Ми охоче розширимо його в деяких межах, але ми не хочемо розширювати його до рівня Common Lisp. Я одного разу реалізовував Common Lisp на Лісп-машині, й мені він не так вже й сподобався. Одна з речей, які мені страшенно не подобаються, — це аргументи — ключові слова [8]. На мій погляд, вони виглядають зовсім не по-ліспівськи; іноді я пишу так, але зводжу до мінімуму кількість випадків, коли я це роблю.

На цьому проекти GNU, пов'язані з Ліспом, не закінчилися. Згодом, приблизно в 1995 році, ми розмірковували над організацією проекту графічної стільниці. Було ясно, що стільничні програми нам потрібно писати переважно такою мовою програмування, яка робила б стільницю легко розширюваною, ніби наш редактор. Постало питання того, яку мову обрати.

У той час для таких цілей посилено просували TCL. Я був дуже невисокої думки про TCL, оскільки це був зовсім не Лісп: TCL злегка нагадує Лісп, але семантично відрізняється й не така елегантна. Потім мені показали оголошення: компанія Sun намагалася найняти кого-небудь для роботи над TCL, щоб зробити його “стандартом де-факто для мови розширень” в усьому світі. А я подумав: “Нам потрібно запобігти цьому”. Тому ми почали робити Scheme стандартною мовою розширень GNU. Не Common Lisp, бо він був занадто великий. Ідея була в тому, щоб розробити інтерпретатор Scheme, спроектований для компонування у застосунки по аналогії з TCL, і радити всім програмам GNU використовувати саме його для втілення розширень.

Є одна цікава вигода, яку можна отримати з застосування такої потужної мови, як варіант Ліспа, в якості первинної мови розширень. Ви можете втілювати інші мови перекладом їх вашою первинною мовою. Якщо ваша первинна мова — TCL, ви не можете легко втілити Лісп перекладом його на TCL. Але якщо ваш первинна мова — Лісп, то неважко реалізовувати інші мови, перекладаючи їх. Наша ідея полягала в тому, що якби кожний відкритий застосунок підтримував Scheme, то ви могли б написати на Scheme реалізацію TCL, Python або Perl, яка перекладає ту чи іншу програму на Scheme. Тоді ви могли б завантажити її в будь-який застосунок, надбудувати його своєю улюбленою мовою — й надбудова вашою мовою працювала б разом з іншими.

Використання слабких мов розширення примушує користувачів застосовувати лише ту мову, яку ви їм надаєте. Тобто прихильникам різних мов доводиться змагатися за вибір розробників застосунків, кажучи розробнику програми: «Закладіть, будь ласка, в свій застосунок мою мову, а не його». Тоді у користувачів взагалі не буде вибору: яким би застосунком вони не користувалися, його мову вже обрано й у них нема альтернатив. Але коли у вас потужна мова, здатна реалізовувати інші мови, перекладаючи їх, то ви надаєте користувачеві вибір мови, і нам більше не доводиться вести війну мов. Саме цього, як ми сподіваємося, досягне Guile — наш інтерпретатор Scheme. У нас є людина, яка цього літа працює над завершенням транслятора з Python на Scheme. Я не знаю, чи повністю він завершений, але якщо ви зацікавлені в цьому проекті — зв'яжіться, будь ласка. Ось такі у нас плани на майбутнє.

Я ще не згадував вільне програмне забезпечення, але дозвольте мені коротко розповісти вам трохи про те, що це означає. Вираз “вільна програма” передбачає не вартість; воно не означає, що ви отримаєте її безкоштовно. (Можливо, ви заплатили за копію або отримали копію безкоштовно.) Воно означає, що у вас як у користувача є свобода. Життєво важливо те, що ви вільні виконувати програму, вільні вивчати, що вона робить, вільні змінювати її під свої потреби, вільні розповсюджувати копії інших і вільні публікувати поліпшені, розширені версії. Ось що означає вільна програма. Якщо ви користуєтеся невільною програмою, то ви втратили життєво важливу свободу, тому ніколи цього не робіть.

Призначення проекту GNU полягає в тому, щоб полегшити людям відмову від зневажаючих свободу, пануючих над користувачем невільних програм наданням вільних програм для їхньої заміни. Для тих, у кого немає моральних сил для відмови від невільних програм, коли це означає яку-небудь практичну незручність,— для них ми намагаємося дати вільну альтернативу, щоб ви могли перейти до свободи з меншими зусиллями і меншими жертвами в практичному сенсі. Чим менші жертви, тим краще. Ми хочемо полегшити для вас співпрацю і вільне життя.

Співпраця — це питання свободи. Ми звикли думати про свободу і співпрацю з суспільством як про протилежності. Але в даному випадку вони на одному боці. При вільних програмах ви вільні співпрацювати з іншими й допомагати самим собі. При невільних програмах хтось домінує над вами і роз'єднує людей. Вам не дозволяють обмінюватися з ними, ви не вільні співпрацювати або допомагати суспільству, точно так само, як ви не вільні допомогти самим собі. Роз'єднаність і безпорадність — стан користувачів, які застосовують невільні програми.

Ми виробили запаморочливе число вільних програм. Ми зробили те, що, як стверджувалося, ми ніколи не зможемо зробити; у нас є дві операційні системи з вільних програм. У нас є безліч застосунків, і нам, очевидно, ще багато належить пройти. Отож, нам потрібна ваша допомога. Я хотів би попросити вас стати добровольцями проекту GNU; допоможіть нам розробити вільні програми для нових завдань. Загляньте на gnu.org/help за пропозиціями того, як допомогти. Якщо ви хочете замовити щось, на це є посилання з домашньої сторінки. Якщо ви хочете почитати про філософські питання, загляньте в /philosophy. Якщо ви шукаєте вільні програми для користування, загляньте в /directory, де зараз перераховано близько 1900 пакетів (це тільки частинка всіх вільних програм світу). Будь ласка, пишіть нові програми і передавайте нам. Мій збірник нарисів, “Вільні програми і вільне суспільство”, знаходиться у продажу, і його можна придбати на www.gnu.org [9]. Успішного хакерства!

Виноски

1. Гай Стіл розробив початковий симетричний набір команд Emacs; потім ми з ним почали реалізовувати Emacs (на базі TECO), але після однієї тривалої спільної сесії розробки Стіл втомився, тож Emacs дописав я. Інші, зокрема Юджин Чиччареллі й Майк Макмегон, згодом додали й свої великі внески.
2. Берні Грінберг стверджує, що реалізація Emacs Дена Вайнреба для Лісп-машини вийшла раніше реалізації Грінберга для Multics. Я прошу вибачення за цю помилку.
3. План Грінблета, наскільки я розумію, полягав у тому, щоб наймати людей з лабораторії за сумісництвом, щоби вони могли продовжувати працювати в Лабораторії штучного інтелекту. Symbolics замість цього наймала їх на повний робочий день, тому вони припиняли працювати в інституті.
4. Цей план базувався на тому (у тій промові я цього не сказав явно), що в початковий період колишні хакери Лабораторії штучного інтелекту, як у Symbolics, так і в LMI, продовжували вносити свої зміни в систему Лісп-машини інституту — хоча за контрактом цього не вимагалося. План Symbolics полягав у тому, щоб перервати цю співпрацю у односторонньому порядку.
5. Не те щоб мене особливо турбувала доля LMI, але я просто не хотів дозволити Symbolics нажитися на своїй агресії по відношенню до Лабораторії штучного інтелекту.
6. З цього твердження було зроблено неправильний висновок, що я ніколи-ніколи не заглядав у програми Symbolics. Насправді тут йдеться, що я це робив спочатку. Вихідний текст Symbolics був доступний в інституті, де я мав право його читати, й спочатку саме так я дізнавався про їхні зміни.

   Але тому я був змушений докладати особливих зусиль, щоб розв'язувати кожне завдання по-іншому, аби уникнути копіювання програм Symbolics. Через деякий час я зробив висновок, що краще навіть не дивитися. Так я міг писати програми яким завгодно найкращим чином, не озираючись на те, що могло бути в текстах Symbolics.

7. Symbolics якось висловила інституту претензію, ніби моя робота, перешкодивши їхнім планам, коштувала компанії Symbolics мільйон доларів.
8. Я не заперечую, якщо дуже складна і громіздка функція приймає аргументи-кодові слова. Турбує мене випадок, коли ними користуються такі прості функції, як “member”.
9. У 2021 цю книгу можна придбати в GNU Press.