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

(Запис промови Річарда Столмена, виголошеної 28 жовтня 2002 року на Міжнародній конференції по Ліспу).

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

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

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

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

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

У первісному Emacs Ліспа не було. Мовою низького рівня — неітерпретованою мовою   був асемблер PDP-10. Інтерпретатор, який ми писали, насправді писався не для Emacs, він писався для TECO [1]. Це був наш текстовий редактор і вкрай потворна мова програмування, настільки потворна, наскільки це взагалі можливо. Причина була в тому, що вона не була спроектована як мова програмування, а натомість як мова редактора і команд. Були такі команди, як “5l”, що означало “пересунутися на п'ять рядків”, або “i” з наступним рядком та ESC для того, щоб вставити цей рядок. Можна було набрати рядок, який був послідовністю команд, який називався командним рядком. Він завершувався символами 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” і так далі, і зараз при нагоді ми могли б закласти іншу циклічну конструкцію. Ми охоче розширимо його в деяких межах, але ми не хочемо розширювати його до рівня Загального Ліспа. Я одного разу реалізовував Загальний Лісп на машині-Ліспі, і мені він не так вже сподобався. Одна з речей, які мені страшенно не подобаються   аргументи-ключові слова (8). На мій погляд, це виглядає не зовсім по-ліспівськи; іноді я пишу так, але зводжу до мінімуму кількість випадків, коли я це роблю.

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

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

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

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

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

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

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

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

  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”.