Мой опыт работы с Лиспом и развитие GNU Emacs

---

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

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

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

В семидесятые годы 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; помогите нам разработать свободные программы для новых задач. Загляните на 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”.
9. В 2021 году эту книгу можно купить в магазине GNU Press.