Minhas experiências com Lisp e o desenvolvimento do GNU Emacs

---

Como nenhum dos meus discursos habituais tem nada a ver com Lisp, nenhum deles era apropriado para hoje. Então eu vou ter que improvisar. Desde que fiz coisas suficientes em minha carreira conectadas com Lisp, eu deveria poder dizer algo interessante.

Minha primeira experiência com Lisp foi quando li o manual do Lisp 1.5 no ensino médio. Foi quando tive a impressão de que poderia haver uma linguagem de computação como essa. A primeira vez que tive a chance de fazer qualquer coisa com Lisp foi quando eu era um calouro em Harvard e escrevi um interpretador de Lisp para o PDP-11. Era uma máquina muito pequena – tinha algo como 8k de memória – e consegui escrever o interpretador com mil instruções. Isso me deu algum espaço para um pouco de dados. Isso foi antes de eu ver como era o software real, que funcionava no sistema real.

Comecei a trabalhar em uma implementação real do Lisp com JonL White quando comecei a trabalhar no MIT. Fui contratado no Laboratório de Inteligência Artificial (AI Lab) não por JonL, mas por Russ Noftsker, o que foi muito irônico considerando o que estava por vir – ele deve ter realmente se arrependido daquele dia.

Durante a década de 1970, antes de minha vida se tornar politizada por conta de eventos horríveis, eu estava apenas fazendo uma extensão após a outra para vários programas, e a maioria deles não tinha nada a ver com Lisp. Mas, ao longo do caminho, escrevi um editor de texto, o Emacs. A ideia interessante sobre o Emacs era que ele tinha uma linguagem de programação e os comandos de edição do usuário seriam escritos naquela linguagem de programação interpretada, para que você pudesse carregar novos comandos no editor enquanto estava editando. Você poderia editar os programas que estava usando e depois continuar editando com eles. Então, nós tínhamos um sistema que era útil para outras coisas além de programação, e ainda assim você poderia programá-lo enquanto você o estivesse usando. Não sei se foi o primeiro deles, mas certamente foi o primeiro editor assim.

Este espírito de construir programas gigantescos e complicados para usar em sua própria edição e depois trocá-los com outras pessoas, alimentou o espírito de cooperação livre que tivemos no AI Lab. A ideia era que você pudesse dar uma cópia de qualquer programa que você tivesse para alguém que quisesse uma cópia dele. Nós compartilhamos programas para quem quisesse usá-los, eles eram conhecimento humano. Assim, embora não houvesse um pensamento político organizado relacionando à forma como compartilhamos software com o design do Emacs, estou convencido de que havia uma conexão entre eles, talvez uma conexão inconsciente. Eu acho que é a natureza do jeito que vivemos no AI Lab que levou ao Emacs e fez dele o que se tornou.

O Emacs original não tinha Lisp nele. A linguagem de baixo nível, a linguagem não interpretada – era o Assembler de PDP-10. O interpretador que escrevemos na verdade não foi escrito para o Emacs, foi escrito para o TECO. Era o nosso editor de texto, e era uma linguagem de programação extremamente feia, tão feia quanto poderia ser. O motivo foi que não foi projetado para ser uma linguagem de programação, foi projetado para ser um editor e uma linguagem de comando. Havia comandos como 5l, significando mover cinco linhas, ou i e, em seguida, uma sequência de caracteres e, em seguida, um ESC para inserir essa sequência de caracteres. Você digitaria uma string que era uma série de comandos, que era chamada de string de comando. Você terminaria com ESC ESC, e o comando seria executado.

Bem, as pessoas queriam estender essa linguagem com recursos de programação, então elas adicionaram alguns. Por exemplo, um dos primeiros foi uma construção em loop, que foi < >. Você colocaria essas coisas em volta e os comandos dentro delas executariam em loop. Havia outros comandos enigmáticos que poderiam ser usados para sair condicionalmente do loop. Para fazer o Emacs, nós [1] adicionamos recursos para termos sub-rotinas com nomes. Antes disso, era como o Basic, e as sub-rotinas só podiam ter letras únicas como seus nomes. Foi difícil desenvolver programas grandes, então adicionamos código para que eles pudessem ter nomes mais longos. Na verdade, havia algumas instalações bastante sofisticadas; eu acho que o Lisp obteve seu mecanismo de unwind-protect do TECO.

Começamos a colocar instalações bastante sofisticadas, todas com a sintaxe mais feia que você poderia imaginar, e funcionou – as pessoas eram capazes de escrever programas grandes de qualquer maneira. A lição óbvia foi que uma linguagem como TECO, que não foi projetada para ser uma linguagem de programação, era o caminho errado a seguir. A linguagem na qual você constrói suas extensões não deve ser pensada como uma linguagem de programação na reflexão posterior; deve ser projetada como uma linguagem de programação. De fato, descobrimos que a melhor linguagem de programação para esse propósito era Lisp.

Foi Bernie Greenberg, que descobriu que ela era [2]. Ele escreveu uma versão do Emacs no Multics MacLisp e escreveu seus comandos no MacLisp de maneira direta. O editor em si foi escrito inteiramente em Lisp. Multics Emacs provou ser um grande sucesso – programar novos comandos de edição era tão conveniente que até os secretários de seu escritório começaram a aprender como usá-lo. Eles usaram um manual que alguém escreveu que mostrava como estender o Emacs, mas não disse que era uma programação. Então os secretários, que acreditavam que não podiam programar, não ficaram assustados. Eles leram o manual, descobriram que podiam fazer coisas úteis e aprenderam a programar.

Então Bernie percebeu que um aplicativo – um programa que faz algo útil para você – que tem Lisp dentro dele e que você poderia estender reescrevendo os programas Lisp, é na verdade uma ótima maneira de as pessoas aprenderem programação. Isso lhes dá a chance de escrever pequenos programas que são úteis para eles, o que na maioria das arenas você não pode fazer. Eles podem obter incentivo para seu próprio uso prático – na fase em que é o mais difícil – onde eles não acreditam que podem programar, até chegarem ao ponto em que são programadores.

Nesse ponto, as pessoas começaram a se perguntar como poderiam obter algo assim em uma plataforma em que não tivessem a implementação de Lisp de serviço completo. Multics MacLisp tinha um compilador, bem como um interpretador – era um sistema Lisp completo – mas as pessoas queriam implementar algo assim em outros sistemas onde elas não tinham escrito um compilador Lisp. Bem, se você não tivesse o compilador Lisp você não poderia escrever o editor inteiro em Lisp – seria muito lento, especialmente para reexibição de tela, se tivesse que executar Lisp interpretado. Então nós desenvolvemos uma técnica híbrida. A ideia era escrever um interpretador Lisp e as partes de baixo nível do editor juntos, de modo que partes do editor fossem recursos Lisp embutidos. Essas seriam as partes que sentimos que precisávamos otimizar. Esta foi uma técnica que já tínhamos praticado conscientemente no Emacs original, porque havia certos recursos de alto nível que reimplementamos em linguagem de máquina, transformando-os em primitivas do TECO. Por exemplo, havia uma primitiva do TECO para preencher um parágrafo (na verdade, para fazer a maior parte do trabalho de preencher um parágrafo, porque algumas das partes menos demoradas do trabalho seriam feitas em um nível mais alto por um programa do TECO). Você poderia fazer o trabalho inteiro escrevendo um programa do TECO, mas isso era muito lento, então otimizamos isso colocando parte dele em linguagem de máquina. Usamos a mesma ideia aqui (na técnica híbrida), que a maior parte do editor seria escrita em Lisp, mas certas partes dele que tinham que rodar particularmente rápido seriam escritas em um nível mais baixo.

Portanto, quando escrevi minha segunda implementação do Emacs, segui o mesmo tipo de design. A linguagem de baixo nível não era mais linguagem de máquina, era C. C era uma linguagem boa e eficiente para programas portáveis rodarem em um sistema operacional parecido com Unix. Havia um interpretador Lisp, mas implementei recursos para trabalhos de edição para fins especiais diretamente no C – manipulação de buffers do editor, inserção de texto inicial, leitura e gravação de arquivos, exibição do buffer novamente na tela, gerenciamento de janelas do editor.

Agora, este não foi o primeiro Emacs que foi escrito em C e rodou no Unix. O primeiro foi escrito por James Gosling e foi referido como GosMacs. Uma coisa estranha aconteceu com ele. No começo, ele parecia influenciado pelo mesmo espírito de compartilhamento e cooperação do Emacs original. Eu lancei pela primeira vez o Emacs original ao público no MIT. Alguém queria portá-lo para rodar no Twenex – originalmente rodava apenas no Sistema de Compartilhamento de Tempo Incompatível (ITS) que usávamos no MIT. Eles o levaram para o Twenex, o que significava que havia algumas centenas de instalações em todo o mundo que poderiam usá-lo. Nós começamos a distribuí-lo para eles, com a regra de que “você tinha que mandar de volta todos os seus aprimoramentos” para que todos pudéssemos nos beneficiar. Ninguém nunca tentou impor isso, mas até onde eu sei, as pessoas cooperaram.

Gosling, a princípio, pareceu participar desse espírito. Ele escreveu em um manual que ele chamou o programa Emacs, esperando que outros na comunidade o melhorassem até que fosse digno desse nome. Essa é a abordagem correta a ser adotada para com uma comunidade – pedir que participem e melhorem o programa. Mas depois disso ele pareceu mudar o espírito e vendeu o programa o vendeu para uma empresa.

Naquela época, eu estava trabalhando no sistema GNU (um sistema operacional similar ao Unix, de software livre, que muitas pessoas erroneamente chamam de “Linux”). Não havia um editor Emacs de software livre que fosse executado no Unix. Eu tinha, no entanto, um amigo que participou do desenvolvimento do Emacs de Gosling. Gosling havia lhe dado, por e-mail, permissão para distribuir sua própria versão. Ele propôs-me que eu usasse essa versão. Então eu descobri que o Emacs de Gosling não tinha um Lisp real. Ele tinha uma linguagem de programação que era conhecida como “mocklisp”, que se parece sintaticamente com o Lisp, mas não possui as estruturas de dados do Lisp. Então os programas não eram dados e os elementos vitais do Lisp estavam faltando. Suas estruturas de dados eram sequências de caracteres, números e algumas outras coisas especializadas.

Eu concluí que não poderia usá-lo e tive que substituir tudo, o primeiro passo foi escrever um interpretador Lisp. Gradualmente adaptei cada parte do editor com base em estruturas de dados do Lisp real, em vez de estruturas de dados ad hoc, tornando as estruturas de dados internas do editor expostas e manipuláveis pelos programas Lisp do usuário.

A única exceção foi a reexibição. Durante muito tempo, a reexibição era uma espécie de mundo alternativo. O editor entraria no mundo da reexibição e as coisas continuariam com estruturas de dados muito especiais que não eram seguras para a coleta de lixo, não eram seguras para a interrupção, e você não poderia executar nenhum programa Lisp durante isso. Nós mudamos isso desde então – agora é possível executar o código Lisp durante a reexibição. É uma coisa bastante conveniente.

Este segundo programa Emacs era “software livre” no sentido moderno do termo – foi parte de uma campanha política explícita para desenvolver software livre. A essência dessa campanha era que todos deveriam ser livres para fazer as coisas que fazíamos antigamente no MIT, trabalhando juntos em software e trabalhando com quem quisesse trabalhar conosco. Essa é a base para o movimento do software livre – a experiência que tive, a vida que vivi no AI Lab do MIT de estar trabalhando no conhecimento humano, e não estar no caminho impedindo as pessoas de usar e disseminar ainda mais o conhecimento humano.

Na época, você poderia construir um computador com a mesma faixa de preço de outros computadores que não fossem feitos para rodar Lisp, exceto que ele executaria o Lisp muito mais rápido do que os outros, e com a verificação de tipo completa em todas as operações também. Computadores comuns normalmente o forçavam a optar pela velocidade de execução e boa verificação da digitação. Então, sim, você poderia ter um compilador Lisp e rodar seus programas rapidamente, mas quando eles tentavam pegar o car de um número, ele obtinha resultados absurdos e eventualmente falhava em algum ponto.

A máquina Lisp era capaz de executar instruções tão rápido quanto as outras máquinas, mas cada instrução – uma instrução car – faria uma verificação de tipo de dados de forma que quando se tentava obter o car de um número em um programa compilado, ele causaria um erro imediato. Nós construímos a máquina e tínhamos um sistema operacional Lisp para ela. Ele foi escrito quase inteiramente em Lisp, as únicas exceções sendo partes escritas no microcódigo. As pessoas ficaram interessadas em fabricá-las, o que significava que deveriam abrir uma empresa.

Havia duas ideias diferentes sobre como essa empresa deveria ser. Greenblatt queria começar o que ele chamou de um empresa “hacker”. Isso significava que seria uma empresa administrada por hackers e funcionaria de maneira favorável aos hackers. Outro objetivo era manter a cultura do AI Lab [3]. Infelizmente, o Greenblatt não tinha experiência em negócios, então outras pessoas do grupo de máquinas Lisp disseram duvidar que ele pudesse ter sucesso. Eles pensaram que seu plano para evitar investimentos externos não funcionaria.

Por que ele queria evitar investimentos externos? Porque quando uma empresa tem investidores externos, eles assumem o controle e não deixam que você tenha nenhum escrúpulo. E, eventualmente, se você tiver algum escrúpulo, eles também o substituirão como administrador.

Então, Greenblatt teve a ideia de que encontraria um cliente que pagaria antecipadamente para comprar as peças. Eles construiriam máquinas e as entregariam; com os lucros dessas partes, eles poderiam comprar peças para mais algumas máquinas, vendê-las e então comprar peças para um número maior de máquinas, e assim por diante. As outras pessoas do grupo acharam que isso possivelmente não funcionaria.

Greenblatt então recrutou Russell Noftsker, o homem que havia me contratado, que posteriormente havia deixado o AI Lab e criado uma empresa de sucesso. Acreditava-se que Russell tinha uma aptidão para negócios. Ele demonstrou essa aptidão para os negócios, dizendo às outras pessoas do grupo: “Vamos abandonar Greenblatt, esquecer suas ideias e faremos outra empresa”. Esfaqueando pelas costas, claramente, um verdadeiro homem de negócios. Essas pessoas decidiram que iriam formar uma empresa chamada Symbolics. Eles obteriam investimento externo, não teriam escrúpulos e fariam todo o possível para vencer.

Mas Greenblatt não desistiu. Ele e as poucas pessoas leais a ele decidiram começar a Lisp Machines Inc. de qualquer forma, e seguir em frente com seus planos. E sabe que eles conseguiram! Eles conseguiram o primeiro cliente e foram pagos antecipadamente. Eles construíram máquinas e as venderam e construíram mais máquinas e mais máquinas. Eles realmente conseguiram, apesar de não terem a ajuda da maioria das pessoas do grupo. A Symbolics também teve um começo bem-sucedido, então você tinha duas empresas concorrentes de máquinas Lisp. Quando a Symbolics viu que a LMI não ia cair de cara no chão, eles começaram a procurar maneiras de destruí-la.

Assim, o abandono do nosso laboratório foi seguido por uma “guerra” em nosso laboratório. O abandono aconteceu quando a Symbolics contratou todos os hackers, exceto eu e os poucos que trabalhavam na LMI em meio período. Então eles invocaram uma regra e eliminaram pessoas que trabalhavam em meio período para o MIT, então tiveram que sair completamente, restando apenas eu. O AI Lab estava agora indefeso. E o MIT fez um acordo muito tolo com essas duas empresas. Foi um contrato de três vias em que ambas as empresas licenciaram o uso de fontes do sistema de máquinas Lisp. Essas empresas foram obrigadas a deixar o MIT usar suas mudanças. Mas não disse no contrato que o MIT tinha o direito de colocá-los nos sistemas de máquinas MIT Lisp que ambas as empresas tinham licenciado. Ninguém previra que o grupo de hackers do AI Lab seria aniquilado, mas foi.

Então, a Symbolics criou um plano [4]. Eles disseram para o laboratório, “Continuaremos a disponibilizar nossas alterações no sistema para você usar, mas você não pode colocá-las no sistema da máquina Lisp do MIT. Em vez disso, daremos acesso ao sistema de máquina Lisp da Symbolics e você poderá executá-lo, mas isso é tudo que você pode fazer.”

Isso, na verdade, significava que eles precisavam escolher um lado e, ou usar a versão MIT do sistema ou a versão da Symbolics. A depender da escolha que fizéssemos, seria determinado para qual sistema nossas melhorias iriam. Se trabalhássemos e melhorássemos a versão da Symbolics, estaríamos apoiando a Symbolics sozinha. Se usássemos e melhorássemos a versão do sistema do MIT, estaríamos disponibilizando o trabalho para ambas as empresas, mas a Symbolics viu que estaríamos apoiando a LMI porque estaríamos ajudando-a a continuar existindo. Então não nos permitiram mais ser neutros.

Até aquele momento, eu não havia tomado o lado de nenhuma das duas empresas, embora isso me fizesse sentir infeliz ao ver o que havia acontecido com nossa comunidade e com o software. Mas agora, a Symbolics tinha forçado a barra. Então, em um esforço para ajudar a dar continuidade à Lisp Machines Inc. [5] – comecei a duplicar todas as melhorias que a Symbolics tinha feito no sistema de máquinas Lisp. Escrevi as melhorias equivalentes novamente (ou seja, o código era meu).

Após algum tempo [6], cheguei à conclusão de que seria melhor se eu nem olhasse para o código deles. Quando eles fizeram um anúncio da versão beta que dava as notas de lançamento, eu veria quais eram os recursos e depois os implementaria. No momento em que eles tinham um lançamento real, eu também lançava.

Desta forma, por dois anos, eu os impedi de eliminar a Lisp Machines Incorporated, e as duas empresas sobreviveram. Mas eu não queria passar anos e anos punindo alguém, apenas frustrando um ato maligno. Eu percebi que eles tinham sido punidos muito bem porque estavam presos a uma competição que não acabava e não ia desaparecer [7]. Enquanto isso, era hora de começar a construir uma nova comunidade para substituir aquela que as ações da Symbolics e outros haviam eliminado.

A comunidade Lisp nos anos 70 não se limitou ao AI Lab do MIT, e os hackers não estavam todos no MIT. A guerra que a Symbolics iniciou foi o que acabou com o MIT, mas havia outros eventos acontecendo na época. Havia pessoas desistindo da cooperação, e juntos eles acabaram com a comunidade e não sobrou muito.

Quando parei de punir a Symbolics, tive que descobrir o que fazer em seguida. Eu tinha que fazer um sistema operacional livre, isso estava claro – a única maneira que as pessoas poderiam trabalhar juntas e compartilhar era com um sistema operacional livre.

No começo, pensei em criar um sistema baseado em Lisp, mas percebi que não seria uma boa ideia tecnicamente. Para ter algo como o sistema da máquina Lisp, você precisava de um microcódigo de propósito especial. Foi isso que tornou possível rodar programas tão rápido quanto outros computadores e ainda assim obter o benefício da verificação de tipo. Sem isso, você seria reduzido a algo como os compiladores Lisp para outras máquinas. Os programas seriam mais rápidos, mas instáveis. Agora, tudo bem se você estiver executando um programa em um sistema de tempo compartilhado – se um programa falhar, isso não é um desastre, isso é algo que seu programa ocasionalmente faz. Mas isso não era bom para escrever um sistema operacional, então rejeitei a ideia de fazer um sistema como o da Lisp.

Decidi, em vez disso, criar um sistema operacional semelhante ao Unix que tivesse implementações Lisp para serem executadas como programas do usuário. O kernel não seria escrito em Lisp, mas teríamos Lisp. Então o desenvolvimento desse sistema operacional, o sistema operacional GNU, é o que me levou a escrever o GNU Emacs. Ao fazer isso, meu objetivo era fazer a implementação mínima possível do Lisp. O tamanho dos programas foi uma tremenda preocupação.

Havia pessoas naqueles dias, em 1985, que tinham máquinas de um megabyte sem memória virtual. Eles queriam poder usar o GNU Emacs. Isso significava que eu tinha que manter o programa o menor possível.

Por exemplo, naquele momento a única construção em loop era o while, o que era extremamente simples. Não havia maneira de sair da declaração while, você tinha que fazer um catch e um throw, ou testar uma variável que estava no loop. Isso mostra até onde eu estava indo para manter as coisas pequenas. Nós não tínhamos caar e cadr e assim por diante; “espremer tudo o que for possível” era o espírito do GNU Emacs, o espírito do Emacs Lisp, desde o começo.

Obviamente, as máquinas são maiores agora, e nós não fazemos mais isso. Nós colocamos em caar e cadr e assim por diante, e podemos colocar em outra construção de loop um dia desses. Estamos dispostos a estendê-lo agora, mas não queremos estendê-lo no nível do Lisp comum. Eu implementei o Common Lisp uma vez na máquina Lisp, e não estou muito feliz com isso. Uma coisa que eu não gosto muito é dos argumentos das palavras-chave [8]. Eles não se parecem muito com algo do Lisp para mim; Às vezes faço isso, mas minimizo as vezes em que faço isso.

Esse não foi o fim dos projetos GNU envolvidos com o Lisp. Mais tarde, por volta de 1995, estávamos procurando iniciar um projeto de área de trabalho gráfica. Ficou claro que, para os programas na área de trabalho, queríamos que uma linguagem de programação escrevesse muito nela para torná-la facilmente extensível, como o editor. A questão era o que deveria ser.

Na época, a TCL estava sendo intensamente utilizada para essa finalidade. Eu tinha uma opinião muito ruim sobre a TCL, basicamente porque não era Lisp. Se parece um pouco com Lisp, mas semanticamente não é, e não é tão limpa. Então, alguém me mostrou um anúncio em que a Sun estava tentando contratar alguém para trabalhar em TCL para torná-la a “linguagem de extensão padrão de fato” do mundo. E eu pensei: “Temos que impedir que isso aconteça”. Então começamos a fazer do Scheme a linguagem de extensibilidade padrão do GNU. Não Common Lisp, porque era muito grande. A ideia era que teríamos um interpretador Scheme projetado para ser vinculado a aplicativos da mesma forma que a TCL estava vinculada a aplicativos. Recomendaríamos então que ela fosse o pacote de extensibilidade preferido para todos os programas GNU.

Há um benefício interessante que você pode obter usando uma linguagem tão poderosa quanto uma versão do Lisp como sua principal linguagem de extensibilidade. Você pode implementar outras linguagens traduzindo-as em sua linguagem principal. Se a sua linguagem principal é a TCL, você não pode implementar facilmente o Lisp traduzindo-o para o TCL. Mas se a sua linguagem principal é o Lisp, não é tão difícil implementar outras coisas traduzindo-as. Nossa ideia era que, se cada aplicativo extensível suportasse o Scheme, você poderia escrever uma implementação da TCL ou Python ou Perl no Scheme que traduz esse programa em Scheme. Em seguida, você poderia carregá-lo em qualquer aplicativo e personalizá-lo em seu idioma favorito e também funcionaria com outras personalizações.

Enquanto as linguagens de extensibilidade forem fracas, os usuários terão que usar apenas a linguagem que você forneceu. O que significa que as pessoas que gostam de determinada linguagem têm que competir pela escolha dos desenvolvedores de aplicativos – dizendo “Por favor, desenvolvedor do aplicativo, coloque minha linguagem em seu aplicativo e não em sua linguagem”. Então, os usuários ficam sem escolhas – Qualquer aplicativo que eles estejam usando vem com uma linguagem e eles estão presos [a essa linguagem]. Mas quando você tem uma linguagem poderosa que pode implementar outras traduzindo-as, então você dá ao usuário uma escolha de linguagem e nós não precisamos mais ter uma guerra de linguagens. É o que esperamos que “Guile”, nosso interpretador scheme, fará. Tivemos uma pessoa trabalhando no último verão, terminando um tradutor do Python para o Scheme. Eu não sei se está totalmente pronto ainda, mas para qualquer pessoa interessada neste projeto, por favor entre em contato. Então esse é o plano que temos para o futuro.

Eu não tenho falado sobre software livre, mas deixe-me contar um pouco sobre o que isso significa. Software livre não se refere ao preço; não significa que você pode obtê-lo de graça. (Você pode ter pago por uma cópia ou obtido uma cópia grátis.) Significa que você tem liberdade como usuário. O importante é que você esteja livre para executar o programa, livre para estudar o que ele faz, livre para mudá-lo para atender às suas necessidades, livre para redistribuir as cópias de outros e livre para publicar versões aprimoradas e estendidas. Isto é o que significa software livre. Se você estiver usando um programa não livre, você perdeu a liberdade crucial, então nunca faça isso.

O objetivo do projeto GNU é facilitar para que as pessoas rejeitarem softwares que dominam o usuário, não livres, que atropelam a liberdade, por meio do fornecimento de software livre para substituí-los. Para aqueles que não têm a coragem moral de rejeitar o software não livre, quando isso significa algum inconveniente prático, o que tentamos fazer é dar uma alternativa livre para que você possa se mover para a liberdade com menos confusão e menos sacrifício em termos práticos. Quanto menos sacrifício, melhor. Queremos que seja mais fácil viver em liberdade, cooperar.

Cooperação é uma questão de liberdade. Estamos acostumados a pensar que liberdade e cooperação na sociedade são coisas opostas. Mas elas estão do mesmo lado. Com o software livre, você é livre para cooperar com outras pessoas, bem como para ajudar a si mesmo. Com software não-livre, alguém está dominando você e mantendo as pessoas divididas. Você não tem permissão para compartilhar com as pessoas, você não está livre para cooperar ou ajudar a sociedade, para ajudar a si mesmo. Divididos e desamparados são os estados dos usuários que usam software não-livre.

Nós produzimos uma tremenda variedade de software livre. Fizemos o que as pessoas disseram que nunca poderíamos fazer; temos dois sistemas operacionais de software livre. Temos muitos aplicativos e obviamente temos muito mais caminhos para trilhar. Então precisamos da sua ajuda. Eu gostaria de pedir para você ser voluntário no projeto GNU; Ajude-nos a desenvolver software livre para mais tarefas. Dê uma olhada em gnu.org/help para encontrar sugestões de como ajudar. Se você quiser encomendar coisas, há um link para isso na página principal. Se você quiser ler sobre questões filosóficas, veja em /philosophy. Se você está procurando por software livre para usar, veja em /directory, que lista cerca de 1900 pacotes agora (o que é uma fração de todo o software livre disponível). Por favor, escreva mais e contribua conosco. Meu livro de ensaios, “Free Software and Free Society”, está à venda e pode ser adquirido em www.gnu.org [9]. Happy hacking!

Notas de rodapé

1. Guy Steele projetou o conjunto original de comandos simétrico do Emacs; então ele e eu começamos a implementar o Emacs (sobre o TECO), mas depois de uma longa sessão de desenvolvimento conjunto, Steele começou a se afastar, então terminei o Emacs. Outros, particularmente incluindo Eugene C. Cicciarelli e Mike McMahon contribuíram substancialmente mais tarde.
2. Bernie Greenberg diz que a implementação de Dan Weinreb do Emacs para a Máquina Lisp (Lisp Machine) veio antes da implementação de Greenberg para o Multics. Peço desculpas pelo erro.
3. O plano de Greenblatt, como eu entendia, era contratar pessoal de laboratório em meio período, para que eles pudessem continuar trabalhando no AI Lab. A Symbolics os contratou em tempo integral, então pararam de trabalhar no MIT.
4. O cenário por trás desse plano, que não mencionei explicitamente na palestra, é que durante um período inicial os ex-hackers da AI Lab, seja na Symbolics ou na LMI, continuaram contribuindo com suas mudanças no sistema da Máquina Lisp do MIT – mesmo que o contrato não exigisse isso. O plano da Symbolics era romper essa cooperação unilateralmente.
5. Não era que eu me importasse particularmente com o destino da LMI, mas eu não queria deixar a Symbolics ganhar através de sua agressão contra o AI Lab.
6. Esta declaração foi mal interpretada como dizendo que eu nunca olhei para o código da Symbolics. Na verdade, diz que eu olhei, no começo. O código-fonte da Symbolics estava disponível no MIT, onde eu tinha o direito de lê-lo e, a princípio, foi assim que descobri suas mudanças.

   Mas isso significava que eu tinha que fazer um esforço especial para resolver cada problema de forma diferente, para evitar copiar o código da Symbolics. Depois de um tempo, concluí que era melhor nem olhar. Dessa forma, eu poderia escrever o código da maneira que fosse melhor, sem me preocupar com o que poderia estar no código da Symbolics.

7. A Symbolics, em certa altura, protestou ao MIT que meu trabalho, frustrando o plano deles, havia custado à Symbolics um milhão de dólares.
8. Não me importo se uma função muito complexa e pesada requer argumentos de palavras-chave. O que me incomoda é fazer funções básicas simples, como “member” usá-los.
9. Em 2021, este livro pode ser comprado da GNU Press.