SUPERANDO AS MÉDIAS

April 2001, rev. April 2003

(Este artigo é derivado de uma palestra proferida no Franz Developer Symposium de 2001.)

No verão de 1995, meu amigo Robert Morris e eu fundamos uma startup chamada Viaweb. Nosso plano era escrever software que permitisse que usuários finais criassem lojas online. O que era inovador nesse software, na época, era que ele rodava em nosso servidor, usando páginas da Web comuns como interface.

Muitas pessoas poderiam ter tido essa ideia ao mesmo tempo, é claro, mas que eu saiba, a Viaweb foi a primeira aplicação baseada na Web. Parecia tão uma ideia nova para nós que demos o nome da empresa em homenagem a ela: Viaweb, porque nosso software funcionava via Web, em vez de rodar no seu computador desktop.

Outra coisa incomum sobre esse software era que ele foi escrito principalmente em uma linguagem de programação chamada Lisp. Foi uma das primeiras grandes aplicações de usuário final a ser escrita em Lisp, que até então tinha sido usado principalmente em universidades e laboratórios de pesquisa. [1]

A Arma Secreta

Eric Raymond escreveu um ensaio chamado "Como se Tornar um Hacker", e nele, entre outras coisas, ele diz aos aspirantes a hackers quais linguagens eles devem aprender. Ele sugere começar com Python e Java, porque são fáceis de aprender. O hacker sério também vai querer aprender C, para hackear o Unix, e Perl para administração de sistemas e scripts cgi. Finalmente, o hacker realmente sério deve considerar aprender Lisp:

Lisp vale a pena aprender pela profunda experiência de iluminação que você terá quando finalmente entender; essa experiência fará de você um programador melhor pelo resto de seus dias, mesmo que você nunca realmente use o próprio Lisp muito.

Este é o mesmo argumento que você costuma ouvir para aprender latim. Não vai conseguir um emprego, exceto talvez como professor de clássicos, mas vai melhorar sua mente e fazer de você um escritor melhor em idiomas que você realmente quer usar, como o inglês.

Mas espere um pouco. Essa metáfora não se estende tanto. O motivo pelo qual o latim não vai conseguir um emprego é que ninguém fala. Se você escrever em latim, ninguém vai entender. Mas Lisp é uma linguagem de computador, e os computadores falam qualquer linguagem que você, o programador, diga a eles.

Então, se Lisp faz de você um programador melhor, como ele diz, por que não você quer usá-lo? Se um pintor fosse oferecido um pincel que o fizesse um pintor melhor, me parece que ele gostaria de usá-lo em todas as suas pinturas, não é? Não estou tentando fazer piada com Eric Raymond aqui. No geral, seu conselho é bom. O que ele diz sobre Lisp é mais ou menos a sabedoria convencional. Mas há uma contradição na sabedoria convencional: Lisp vai fazer de você um programador melhor, e ainda assim você não vai usá-lo.

Por que não? Linguagens de programação são apenas ferramentas, afinal. Se Lisp realmente produz programas melhores, você deve usá-lo. E se não, então quem precisa dele?

Esta não é apenas uma questão teórica. O software é um negócio muito competitivo, propenso a monopólios naturais. Uma empresa que consegue escrever software mais rápido e melhor vai, todas as outras coisas sendo iguais, colocar seus concorrentes fora do negócio. E quando você está começando uma startup, você sente isso muito intensamente. As startups tendem a ser uma proposta de tudo ou nada. Você fica rico ou não ganha nada. Em uma startup, se você apostar na tecnologia errada, sua concorrentes vão esmagá-lo.

Robert e eu conhecíamos bem o Lisp e não víamos nenhuma razão para não confiar em nossos instintos e ir com o Lisp. Sabíamos que todos os outros estavam escrevendo seu software em C++ ou Perl. Mas também sabíamos que isso não significava nada. Se você escolhesse tecnologia dessa forma, você estaria executando o Windows. Quando você escolhe tecnologia, você tem que ignorar o que outras pessoas estão fazendo e considerar apenas o que vai funcionar melhor.

Isso é especialmente verdadeiro em uma startup. Em uma grande empresa, você pode fazer o que todas as outras grandes empresas estão fazendo. Mas uma startup não pode fazer o que todas as outras startups fazem. Não acho que muitas pessoas percebam isso, mesmo em startups.

A empresa grande média cresce cerca de dez por cento ao ano. Então se você está administrando uma grande empresa e faz tudo da maneira como a empresa grande média faz, você pode esperar ter o mesmo desempenho que a empresa grande média - ou seja, crescer cerca de dez por cento ao ano.

A mesma coisa vai acontecer se você estiver administrando uma startup, é claro. Se você fizer tudo da maneira como a startup média faz, você deve esperar um desempenho médio. O problema aqui é que o desempenho médio significa que você vai quebrar. A taxa de sobrevivência para startups é muito inferior a cinquenta por cento. Então, se você está administrando uma startup, é melhor você estar fazendo algo estranho. Se não, você está em apuros.

Em 1995, sabíamos algo que acho que nossos concorrentes não entenderam, e poucos entendem até hoje: quando você está escrevendo software que só precisa rodar em seus próprios servidores, você pode usar qualquer linguagem que quiser. Quando você está escrevendo software para desktop, há um forte viés para escrever aplicativos na mesma linguagem que o sistema operacional. Dez anos atrás, escrever aplicativos significava escrever aplicativos em C. Mas com software baseado na Web, especialmente quando você tem o código-fonte da linguagem e do sistema operacional, você pode usar qualquer linguagem que quiser.

Essa nova liberdade é uma faca de dois gumes, no entanto. Agora que você pode usar qualquer linguagem, você tem que pensar em qual usar. As empresas que tentam fingir que nada mudou correm o risco de descobrir que seus concorrentes não.

Se você pode usar qualquer linguagem, qual você usa? Escolhemos Lisp. Por um lado, era óbvio que o desenvolvimento rápido seria importante nesse mercado. Todos estávamos começando do zero, então uma empresa que pudesse lançar novas funcionalidades antes de seus concorrentes teria uma grande vantagem. Sabíamos que Lisp era uma linguagem muito boa para escrever software rapidamente, e as aplicações baseadas em servidor amplificam o efeito do desenvolvimento rápido, porque você pode lançar software no minuto em que ele está pronto.

Se outras empresas não quisessem usar Lisp, tanto melhor. Isso poderia nos dar uma vantagem tecnológica, e precisávamos de toda a ajuda que pudéssemos conseguir. Quando começamos a Viaweb, não tínhamos experiência em negócios. Não sabíamos nada sobre marketing, ou contratar pessoas, ou levantar dinheiro, ou conseguir clientes. Nenhum de nós tinha jamais tido o que você chamaria de um emprego de verdade. A única coisa que nós éramos bons era escrever software. Esperávamos que isso nos salvasse. Qualquer vantagem que pudéssemos obter no departamento de software, nós iríamos pegar.

Então você poderia dizer que usar Lisp foi um experimento. Nossa hipótese era que se escrevêssemos nosso software em Lisp, poderíamos obter funcionalidades mais rápido que nossos concorrentes, e também fazer coisas em nosso software que eles não poderiam fazer. E porque Lisp era tão de alto nível, não precisaríamos de uma grande equipe de desenvolvimento, então nossos custos seriam menores. Se isso fosse verdade, poderíamos oferecer um produto melhor por menos dinheiro e ainda lucrar. No final das contas, nós acabaríamos recebendo todos os usuários, e nossos concorrentes não receberiam nenhum, e eventualmente sairiam do negócio. Era isso que esperávamos que acontecesse, de qualquer maneira.

Quais foram os resultados desse experimento? Um tanto surpreendentemente, funcionou. Eventualmente, tivemos muitos concorrentes, na ordem de vinte a trinta deles, mas nenhum de seus softwares poderia competir com o nosso. Tínhamos um construtor de lojas online wysiwyg que rodava no servidor e ainda parecia uma aplicação de desktop. Nossos concorrentes tinham scripts cgi. E estávamos sempre muito à frente deles em recursos. Às vezes, em desespero, os concorrentes tentavam introduzir recursos que não tínhamos. Mas com Lisp, nosso ciclo de desenvolvimento era tão rápido que às vezes podíamos duplicar uma nova funcionalidade dentro de um ou dois dias de um concorrente anunciá-la em um comunicado de imprensa. Por o tempo que os jornalistas que cobriam o comunicado de imprensa chegassem a nos ligar, nós também teríamos a nova funcionalidade.

Deve ter parecido para nossos concorrentes que tínhamos algum tipo de arma secreta - que estávamos decodificando o tráfego Enigma ou algo assim. Na verdade, tínhamos uma arma secreta, mas era mais simples do que eles perceberam. Ninguém estava vazando notícias de seus recursos para nós. Nós apenas conseguimos desenvolver software mais rápido do que qualquer um pensava ser possível.

Quando eu tinha cerca de nove anos, consegui uma cópia de O Dia do Chacal, de Frederick Forsyth. O personagem principal é um assassino que é contratado para matar o presidente da França. O assassino tem que passar pela polícia para chegar a um apartamento que tem vista para a rota do presidente. Ele passa direto por eles, vestido como um velho de muletas, e eles nunca suspeitam dele.

Nossa arma secreta era semelhante. Escrevemos nosso software em uma linguagem de IA estranha, com uma sintaxe bizarra cheia de parênteses. Por anos me irritou ouvir Lisp descrito dessa forma. Mas agora funcionou a nosso favor. Nos negócios, não há nada mais valioso do que uma vantagem técnica que seus concorrentes não entendem. Em negócios, como na guerra, a surpresa vale tanto quanto a força.

E assim, tenho um pouco de vergonha de dizer, nunca disse nada publicamente sobre Lisp enquanto estávamos trabalhando na Viaweb. Nós nunca mencionamos isso para a imprensa, e se você procurasse por Lisp em nosso site, tudo o que você encontraria seriam os títulos de dois livros na minha biografia. Isso não foi por acaso. Uma startup deve dar a seus concorrentes o mínimo possível de informações. Se eles não soubessem em qual linguagem nosso software foi escrito, ou não se importassem, eu queria manter assim. [2]

As pessoas que mais entenderam nossa tecnologia foram os clientes. Eles também não se importavam com a linguagem em que a Viaweb foi escrita, mas notaram que funcionava muito bem. Permitiu que eles construíssem grandes lojas online com aparência profissional em literalmente minutos. E assim, por boca a boca principalmente, conseguimos cada vez mais usuários. No final de 1996, nós tínhamos cerca de 70 lojas online. No final de 1997, tínhamos 500. Seis meses depois, quando o Yahoo nos comprou, tínhamos 1070 usuários. Hoje, como Yahoo Store, esse software continua dominando seu mercado. É uma das partes mais lucrativas do Yahoo, e as lojas construídas com ele são a base do Yahoo Shopping. Saí do Yahoo em 1999, então não sei exatamente quantos usuários eles têm agora, mas a última vez que ouvi, eram cerca de 20.000.

O Paradoxo Blub

O que é tão bom em Lisp? E se Lisp é tão bom, por que todo mundo não usa? Essas parecem perguntas retóricas, mas na verdade elas têm respostas diretas. Lisp é tão bom não por causa de alguma qualidade mágica visível apenas para devotos, mas porque é simplesmente a linguagem mais poderosa disponível. E a razão pela qual todo mundo não usa é que as linguagens de programação não são meramente tecnologias, mas também hábitos de mente, e nada muda mais devagar. Claro, ambas as respostas precisam de explicação.

Vou começar com uma declaração chocantemente controversa: linguagens de programação variam em poder.

Poucos contestariam, pelo menos, que as linguagens de alto nível são mais poderosas que a linguagem de máquina. A maioria dos programadores hoje concordaria que você não quer, normalmente, programar em linguagem de máquina. Em vez disso, você deve programar em uma linguagem de alto nível e ter um compilador traduzindo para linguagem de máquina para você. Essa ideia é até mesmo integrada ao hardware agora: desde a década de 1980, conjuntos de instruções foram projetados para compiladores em vez de programadores humanos.

Todo mundo sabe que é um erro escrever todo o seu programa à mão em linguagem de máquina. O que é menos compreendido é que existe um princípio mais geral aqui: que se você tiver a opção de várias linguagens, é, todas as outras coisas sendo iguais, um erro programar em qualquer coisa, exceto na mais poderosa. [3]

Existem muitas exceções a essa regra. Se você está escrevendo um programa que tem que funcionar muito próximo a um programa escrito em uma determinada linguagem, pode ser uma boa ideia escrever o novo programa na mesma linguagem. Se você está escrevendo um programa que só precisa fazer algo muito simples, como cálculos numéricos ou manipulação de bits, você pode muito bem usar uma linguagem menos abstrata, especialmente porque ela pode ser um pouco mais rápida. E se você está escrevendo um programa curto e descartável, você pode ser melhor apenas usando qualquer linguagem que tenha as melhores funções de biblioteca para a tarefa. Mas em geral, para software de aplicação, você quer estar usando a linguagem mais poderosa (razoavelmente eficiente) que puder obter, e usar qualquer outra coisa é um erro, exatamente do mesmo tipo, embora possivelmente em um grau menor, como programar em linguagem de máquina.

Você pode ver que a linguagem de máquina é muito de baixo nível. Mas, pelo menos como uma espécie de convenção social, as linguagens de alto nível são frequentemente todas tratadas como equivalentes. Elas não são. Tecnicamente, o termo "linguagem de alto nível" não significa nada muito definido. Não há linha divisória com linguagens de máquina de um lado e todas as linguagens de alto nível do outro. As linguagens caem ao longo de um continuum [4] de abstração, da mais poderosa até as linguagens de máquina, que também variam em poder.

Considere Cobol. Cobol é uma linguagem de alto nível, no sentido de que é compilado para linguagem de máquina. Alguém argumentaria seriamente que Cobol é equivalente em poder a, digamos, Python? É provavelmente mais próximo da linguagem de máquina do que o Python.

Ou que tal Perl 4? Entre Perl 4 e Perl 5, os closures lexicais foram adicionados à linguagem. A maioria dos hackers Perl concordaria que Perl 5 é mais poderoso que Perl 4. Mas uma vez que você admitiu isso, você admitiu que uma linguagem de alto nível pode ser mais poderosa que outra. E segue inexoravelmente que, exceto em casos especiais, você deve usar a mais poderosa que puder obter.

Essa ideia raramente é seguida até sua conclusão, no entanto. Depois de uma certa idade, os programadores raramente mudam de linguagem voluntariamente. Qualquer linguagem que as pessoas estejam acostumadas, elas tendem a considerar apenas boa o suficiente.

Os programadores se apegam muito às suas linguagens favoritas, e eu não quero magoar os sentimentos de ninguém, então para explicar esse ponto, vou usar uma linguagem hipotética chamada Blub. Blub cai bem no meio do continuum de abstração. Não é a linguagem mais poderosa, mas é mais poderosa que Cobol ou linguagem de máquina.

E na verdade, nosso programador Blub hipotético não usaria nenhum deles. Claro que ele não programaria em linguagem de máquina. É para isso que servem os compiladores. E quanto ao Cobol, ele não sabe como alguém pode fazer alguma coisa com ele. Ele nem sequer tem x (recurso Blub de sua escolha).

Enquanto nosso programador Blub hipotético estiver olhando para baixo o continuum de poder, ele sabe que está olhando para baixo. Linguagens menos poderosas que Blub são obviamente menos poderosas, porque estão faltando alguns recursos que ele está acostumado. Mas quando nosso programador Blub hipotético olha na outra direção, para cima no continuum de poder, ele não percebe que está olhando para cima. O que ele vê são apenas linguagens estranhas. Ele provavelmente as considera equivalentes em poder ao Blub, mas com toda essa outra coisa cabeluda jogada também. Blub é bom o suficiente para ele, porque ele pensa em Blub.

Quando mudamos para o ponto de vista de um programador usando qualquer um das linguagens mais acima no continuum de poder, no entanto, descobrimos que ele, por sua vez, olha para baixo para Blub. Como você pode fazer alguma coisa em Blub? Ele nem sequer tem y.

Por indução, os únicos programadores em posição de ver todas as diferenças de poder entre as várias linguagens são aqueles que entendem a mais poderosa. (É provavelmente isso que Eric Raymond quis dizer sobre Lisp fazer de você um programador melhor.) Você não pode confiar nas opiniões dos outros, por causa do paradoxo Blub: eles estão satisfeitos com qualquer linguagem que estejam usando, porque ela dita a maneira como eles pensam sobre programas.

Sei disso por experiência própria, como um garoto do ensino médio escrevendo programas em Basic. Essa linguagem nem sequer suportava recursão. É difícil imaginar escrever programas sem usar recursão, mas eu não senti falta na época. Eu pensava em Basic. E eu era um gênio nisso. Mestre de tudo o que eu observava.

As cinco linguagens que Eric Raymond recomenda aos hackers caem em vários pontos no continuum de poder. Onde eles caem em relação um ao outro é um tópico sensível. O que direi é que eu acho que Lisp está no topo. E para apoiar essa afirmação, vou contar sobre uma das coisas que sinto falta quando olho para as outras quatro linguagens. Como você pode fazer alguma coisa nelas, penso eu, sem macros? [5]

Muitas linguagens têm algo chamado macro. Mas as macros Lisp são únicas. E acredite ou não, o que elas fazem está relacionado ao parênteses. Os designers do Lisp não colocaram todos esses parênteses na linguagem apenas para serem diferentes. Para o programador Blub, o código Lisp parece estranho. Mas esses parênteses estão lá por um motivo. Eles são a evidência externa de uma diferença fundamental entre Lisp e outras linguagens.

O código Lisp é feito de objetos de dados Lisp. E não no sentido trivial de que os arquivos de origem contêm caracteres, e as strings são um dos tipos de dados suportados pela linguagem. O código Lisp, depois de ser lido pelo analisador, é feito de estruturas de dados que você pode percorrer.

Se você entender como os compiladores funcionam, o que realmente está acontecendo é não tanto que Lisp tem uma sintaxe estranha, mas que Lisp não tem sintaxe. Você escreve programas nas árvores de análise que são geradas dentro do compilador quando outras linguagens são analisadas. Mas essas árvores de análise são totalmente acessíveis aos seus programas. Você pode escrever programas que os manipulam. Em Lisp, esses programas são chamados macros. São programas que escrevem programas.

Programas que escrevem programas? Quando você gostaria de fazer isso? Não muito frequentemente, se você pensar em Cobol. O tempo todo, se você pensar em Lisp. Seria conveniente aqui se eu pudesse dar um exemplo de uma macro poderosa e dizer: olha! que tal isso? Mas se eu fizesse, isso pareceria apenas um monte de bobagem para alguém que não conhecesse Lisp; não há espaço aqui para explicar tudo o que você precisaria saber para entender o que significava. Em Ansi Common Lisp tentei mover as coisas o mais rápido possível, e mesmo assim não cheguei às macros até a página 160.

Mas acho que posso dar um tipo de argumento que pode ser convincente. O código-fonte do editor Viaweb era provavelmente cerca de 20-25% macros. As macros são mais difíceis de escrever do que funções Lisp comuns, e é considerado um estilo ruim usá-las quando não são necessárias. Então, cada macro nesse código está lá porque tem que estar. O que isso significa é que pelo menos 20-25% do código nesse programa está fazendo coisas que você não pode fazer facilmente em nenhum outro linguagem. Por mais cético que o programador Blub possa ser sobre minhas afirmações sobre os poderes misteriosos do Lisp, isso deve deixá-lo curioso. Não estávamos escrevendo esse código para nosso próprio divertimento. Nós éramos uma pequena startup, programando o mais rápido que podíamos para colocar barreiras técnicas entre nós e nossos concorrentes.

Uma pessoa desconfiada pode começar a se perguntar se havia alguma correlação aqui. Uma grande parte do nosso código estava fazendo coisas que são muito difíceis de fazer em outras linguagens. O software resultante fez coisas que o software de nossos concorrentes não conseguia fazer. Talvez houvesse algum tipo de conexão. Eu o incentivo a seguir essa linha de raciocínio. Pode haver mais nesse velho cambaleando em suas muletas do que parece.

Aikido para Startups

Mas não espero convencer ninguém (acima de 25) para sair e aprender Lisp. O objetivo deste artigo não é mudar a mente de ninguém, mas para tranquilizar as pessoas que já estão interessadas em usar Lisp - pessoas que sabem que Lisp é uma linguagem poderosa, mas se preocupam porque ela não é amplamente utilizada. Em uma situação competitiva, essa é uma vantagem. O poder do Lisp é multiplicado pelo fato de que seus concorrentes não entendem.

Se você pensa em usar Lisp em uma startup, não deve se preocupar que não seja amplamente compreendido. Você deve esperar que continue assim. E é provável que continue. É a natureza das linguagens de programação fazer com que a maioria das pessoas fique satisfeita com o que elas usam atualmente. O hardware do computador muda muito mais rápido do que os hábitos pessoais, então a prática de programação geralmente está dez a vinte anos atrás do processador. Em lugares como o MIT, eles estavam escrevendo programas em linguagens de alto nível no início da década de 1960, mas muitas empresas continuaram a escrever código em linguagem de máquina até bem na década de 1980. Aposto que um monte de gente continuou a escrever linguagem de máquina até o processador, como um barman ansioso para fechar e ir para casa, finalmente os expulsou mudando para um conjunto de instruções risc.

Normalmente, a tecnologia muda rápido. Mas as linguagens de programação são diferentes: as linguagens de programação não são apenas tecnologia, mas o que os programadores pensam. Elas são metade tecnologia e metade religião. [6] E assim, a linguagem mediana, significando qualquer linguagem que a mediana o programador usa, move-se tão devagar quanto um iceberg. Coleta de lixo, introduzida pelo Lisp por volta de 1960, agora é amplamente considerada uma coisa boa. Digitação em tempo de execução, idem, está crescendo em popularidade. Closures lexicais, introduzidos pelo Lisp no início da década de 1970, agora, apenas, estão na tela do radar. Macros, introduzidas pelo Lisp na década de 1960, ainda são terra incognita.

Obviamente, a linguagem mediana tem um enorme impulso. Não estou propondo que você possa lutar contra essa força poderosa. O que estou propondo é exatamente o oposto: que, como um praticante de Aikido, você pode usá-lo contra seus oponentes.

Se você trabalha para uma grande empresa, isso pode não ser fácil. Você terá dificuldade em convencer o chefe de cabelo espetado a deixar você construir coisas em Lisp, quando ele acabou de ler no jornal que alguma outra linguagem está pronta, como Ada estava há vinte anos, para assumir o mundo. Mas se você trabalha para uma startup que não tem chefes de cabelo espetado ainda, você pode, como nós fizemos, virar o Blub paradoxo a seu favor: você pode usar tecnologia que seus concorrentes, presos de forma imóvel à linguagem mediana, nunca serão capazes de combinar.

Se você alguma vez se encontrar trabalhando para uma startup, aqui está uma dica útil para avaliar concorrentes. Leia suas ofertas de emprego. Tudo o mais em seu site pode ser fotos de estoque ou o equivalente em prosa, mas as ofertas de emprego têm que ser específicas sobre o que querem, ou eles vão conseguir os candidatos errados.

Durante os anos em que trabalhamos na Viaweb, li muitas descrições de vagas. Um novo concorrente parecia surgir do nada a cada mês ou mais. A primeira coisa que eu faria, depois de verificar se eles tinham uma demonstração online ao vivo, era olhar para suas ofertas de emprego. Depois de um par de anos fazendo isso, eu conseguia dizer quais empresas me preocupariam e quais não. Quanto mais sabor de TI as descrições de vagas tivessem, menos perigosa a empresa era. O tipo mais seguro eram as que queriam experiência com Oracle. Você nunca tinha que se preocupar com essas. Você também estava seguro se eles dissessem que queriam desenvolvedores C++ ou Java. Se eles quisessem programadores Perl ou Python, isso seria um pouco assustador - isso está começando a soar como uma empresa onde o lado técnico, pelo menos, é administrado por hackers de verdade. Se eu tivesse visto uma oferta de emprego procurando hackers Lisp, eu teria ficado realmente preocupado.

Notas

[1] A Viaweb inicialmente tinha duas partes: o editor, escrito em Lisp, que as pessoas usavam para construir seus sites, e o sistema de pedidos, escrito em C, que gerenciava os pedidos. A primeira versão era principalmente Lisp, porque o sistema de pedidos era pequeno. Mais tarde, adicionamos dois módulos adicionais, um gerador de imagens escrito em C e um back-office gerenciador escrito principalmente em Perl.

Em janeiro de 2003, o Yahoo lançou uma nova versão do editor escrito em C++ e Perl. É difícil dizer se o programa não é mais escrito em Lisp, no entanto, porque para traduzir esse programa para C++, eles literalmente tiveram que escrever um interpretador Lisp: os arquivos de origem de todos os modelos de geração de páginas ainda são, que eu saiba, código Lisp. (Veja Regra Dez de Greenspun.)

[2] Robert Morris diz que eu não precisava ser secreto, porque mesmo que nossos concorrentes soubessem que estávamos usando Lisp, eles não teriam entendido o porquê: "Se eles fossem tão inteligentes, já estariam programando em Lisp."

[3] Todas as linguagens são igualmente poderosas no sentido de serem Turing equivalentes, mas esse não é o sentido da palavra que os programadores se importam. (Ninguém quer programar uma máquina de Turing.) O tipo de poder que os programadores se importam pode não ser formalmente definível, mas uma maneira de explicá-lo seria dizer que se refere a recursos que você só conseguiria na linguagem menos poderosa escrevendo um interpretador para a linguagem mais poderosa nela. Se a linguagem A tem um operador para remover espaços de strings e a linguagem B não, isso provavelmente não torna A mais poderosa, porque você provavelmente pode escrever uma sub-rotina para fazer isso em B. Mas se A suporta, digamos, recursão, e B não, isso não é algo que você pode consertar escrevendo funções de biblioteca.

[4] Nota para nerds: ou possivelmente uma rede, estreitando-se em direção ao topo; não é a forma que importa aqui, mas a ideia de que existe pelo menos uma ordem parcial.

[5] É um pouco enganoso tratar as macros como um recurso separado. Na prática, sua utilidade é muito aumentada por outros Lisp recursos como closures lexicais e parâmetros de descanso.

[6] Como resultado, as comparações de linguagens de programação ou assumem a forma de guerras religiosas ou livros didáticos de graduação tão decididamente neutros que são realmente obras de antropologia. Pessoas que valorizam sua paz, ou querem a posse, evitam o assunto. Mas a questão é apenas metade religiosa; há algo lá que vale a pena estudar, especialmente se você quiser projetar novas linguagens.