SUPERANDO AS MÉDIAS

Abril de 2001, rev. Abril de 2003

(Este artigo é derivado de uma palestra proferida no Simpósio de Desenvolvedores Franz de 2001.)

No verão de 1995, meu amigo Robert Morris e eu começamos uma startup chamada Viaweb. Nosso plano era escrever software que permitiria aos usuários finais construir lojas online. O que havia de inovador neste software, na época, era que ele era executado em nosso servidor, usando páginas da Web comuns como interface.

Muitas pessoas poderiam estar tendo essa ideia ao mesmo tempo, é claro, mas, até onde sei, a Viaweb foi a primeira aplicação baseada na Web. Parecia uma ideia tão nova para nós que nomeamos a empresa com base nisso: Viaweb, porque nosso software funcionava via Web, em vez de ser executado no computador desktop.

Outra coisa incomum sobre este 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 havia sido usada 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 verdadeiramente sério deve considerar aprender Lisp:

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

Este é o mesmo argumento que você tende a ouvir para aprender latim. Não vai conseguir um emprego, exceto talvez como professor de clássicos, mas vai melhorar sua mente e torná-lo um melhor escritor em línguas que você realmente quer usar, como o inglês.

Mas espere um minuto. Essa metáfora não se estende tanto assim. A razão pela qual o latim não vai conseguir um emprego é que ninguém o fala. Se você escrever em latim, ninguém pode entendê-lo. Mas Lisp é uma linguagem de computador e os computadores falam qualquer linguagem que você, o programador, lhes disser para falar.

Então, se o Lisp o torna um programador melhor, como ele diz, por que você não o usaria? Se um pintor fosse oferecido um pincel que o tornaria um pintor melhor, parece-me que ele o usaria em todas as suas pinturas, não é? Não estou tentando zombar de Eric Raymond aqui. No geral, seu conselho é bom. O que ele diz sobre o Lisp é praticamente o consenso convencional. Mas há uma contradição no consenso convencional: o Lisp o tornará um programador melhor, e ainda assim você não o usará.

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

Essa não é apenas uma questão teórica. O software é um negócio muito competitivo, propenso a monopólios naturais. Uma empresa que escreve software mais rápido e melhor, tudo o mais sendo igual, vai 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 questão de tudo ou nada. Ou você fica rico, ou você não ganha nada. Em uma startup, se você apostar na tecnologia errada, seus concorrentes vão esmagar você.

Robert e eu conhecíamos bem o Lisp e não conseguíamos ver 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 a tecnologia dessa maneira, você estaria usando o Windows. Quando você escolhe a tecnologia, você tem que ignorar o que as 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 média de crescimento de uma grande empresa é de cerca de dez por cento ao ano. Então, se você está gerenciando uma grande empresa e faz tudo da mesma maneira que a média das grandes empresas, você pode esperar ter o mesmo desempenho da média das grandes empresas - ou seja, crescer cerca de dez por cento ao ano.

A mesma coisa acontecerá se você estiver gerenciando uma startup, é claro. Se você fizer tudo da mesma maneira que a startup média, você deve esperar um desempenho médio. O problema aqui é que o desempenho médio significa que você vai sair do negócio. A taxa de sobrevivência para startups é muito menor que cinquenta por cento. Então, se você está gerenciando uma startup, você precisa estar fazendo algo fora do comum. Caso contrário, você está em apuros.

Em 1995, sabíamos algo que acho que nossos concorrentes não entendiam e poucos entendem mesmo agora: quando você está escrevendo software que só precisa ser executado em seus próprios servidores, você pode usar qualquer linguagem que quiser. Quando você está escrevendo software de desktop, há uma forte tendência a escrever aplicativos na mesma linguagem do sistema operacional. Há dez anos, escrever aplicativos significava escrever aplicativos em C. Mas com o software baseado na Web, especialmente quando você tem o código-fonte tanto da linguagem quanto 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ê precisa 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? Nós escolhemos Lisp. Por um lado, era óbvio que o desenvolvimento rápido seria importante neste mercado. Estávamos todos partindo do zero, então uma empresa que pudesse concluir novos recursos antes de seus concorrentes teria uma grande vantagem. Sabíamos que o Lisp era uma linguagem realmente boa para escrever software rapidamente, e aplicativos baseados em servidor amplificam o efeito do desenvolvimento rápido, porque você pode lançar software assim que ele estiver pronto.

Se outras empresas não quisessem usar o 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, contratação de pessoas, captação de recursos ou obtenção de clientes. Nenhum de nós havia tido o que você chamaria de um emprego real. A única coisa em que éramos bons era em escrever software. Esperávamos que isso nos salvasse. Qualquer vantagem que pudéssemos obter no departamento de software, nós a teríamos.

Então, você poderia dizer que usar o Lisp foi um experimento. Nossa hipótese era que, se escrevêssemos nosso software em Lisp, conseguiríamos concluir recursos mais rapidamente do que nossos concorrentes e também fazer coisas em nosso software que eles não conseguiriam fazer. E, como o Lisp é 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 assim obter lucro. Acabaríamos conseguindo todos os usuários, e nossos concorrentes não conseguiriam nenhum, e eventualmente sairiam do negócio. Era isso que esperávamos que acontecesse, de qualquer maneira.

Quais foram os resultados desse experimento? Surpreendentemente, funcionou. Eventualmente, tivemos muitos concorrentes, na ordem de vinte a trinta deles, mas nenhum de seus softwares conseguia competir com o nosso. Tínhamos um construtor de lojas online wysiwyg que era executado no servidor, mas parecia um aplicativo de desktop. Nossos concorrentes tinham scripts CGI. E sempre estávamos muito à frente deles em recursos. Às vezes, em desespero, os concorrentes tentavam introduzir recursos que não tínhamos. Mas com o Lisp, nosso ciclo de desenvolvimento era tão rápido que, às vezes, poderíamos duplicar um novo recurso em um dia ou dois após um concorrente anunciá-lo em um comunicado à imprensa. Quando os jornalistas que cobriam o comunicado à imprensa chegavam a nos ligar, já tínhamos o novo recurso também.

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

Quando eu tinha cerca de nove anos, acabei por conseguir uma cópia de O Dia do Chacal, de Frederick Forsyth. O personagem principal é um assassino contratado para matar o presidente da França. O assassino precisa passar pela polícia para chegar a um apartamento que dá vista para a rota do presidente. Ele passa por eles vestido como um velho com muletas, e eles nunca desconfiam 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 incomodou ouvir o Lisp ser descrito dessa maneira. Mas agora isso funcionava a nosso favor. No mundo dos negócios, não há nada mais valioso do que uma vantagem técnica que seus concorrentes não entendem. Nos negócios, assim como na guerra, a surpresa vale tanto quanto a força.

E então, fico um pouco envergonhado de dizer, nunca disse nada publicamente sobre o Lisp enquanto trabalhávamos na Viaweb. Nunca o mencionamos à imprensa, e se você pesquisasse por Lisp em nosso site, tudo o que encontraria seriam os títulos de dois livros na minha biografia. Isso não foi um acidente. Uma startup deve fornecer o mínimo de informações possíveis aos seus concorrentes. Se eles não sabiam em que linguagem nosso software estava escrito, ou não se importavam, eu queria que continuasse assim.[2]

As pessoas que entendiam melhor nossa tecnologia eram os clientes. Eles não se importavam em que linguagem a Viaweb estava escrita, mas notavam que ela funcionava muito bem. Permitia que eles construíssem ótimas lojas online literalmente em minutos. E assim, principalmente por meio do boca a boca, conseguimos cada vez mais usuários. No final de 1996, tínhamos cerca de 70 lojas online. No final de 1997, tínhamos 500. Seis meses depois, quando a Yahoo nos comprou, tínhamos 1.070 usuários. Hoje, como Yahoo Store, esse software continua a dominar seu mercado. É uma das peças mais lucrativas da Yahoo, e as lojas construídas com ele são a base da Yahoo Shopping. Deixei a Yahoo em 1999, então não sei exatamente quantos usuários eles têm agora, mas a última vez que soube, eram cerca de 20.000.

O Paradoxo do Blub

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

Começarei com uma afirmação chocantemente controversa: as linguagens de programação variam em poder.

Poucos discordariam, pelo menos, que as linguagens de alto nível são mais poderosas do 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 que a traduza para linguagem de máquina por você. Essa ideia está até incorporada no hardware agora: desde a década de 1980, os conjuntos de instruções foram projetados para compiladores, em vez de programadores humanos.

Todos sabem que é um erro escrever todo o seu programa manualmente em linguagem de máquina. O que é menos entendido é que existe um princípio mais geral aqui: que se você tiver a escolha entre várias linguagens, é, todas as outras coisas sendo iguais, um erro programar em qualquer coisa que não seja a mais poderosa.[3]

Existem muitas exceções a essa regra. Se você estiver escrevendo um programa que precisa 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ê estiver escrevendo um programa que só precisa fazer algo muito simples, como processamento numérico ou manipulação de bits, você pode usar uma linguagem menos abstrata, especialmente se ela for um pouco mais rápida. E se você estiver escrevendo um programa curto e descartável, pode ser melhor usar a linguagem que tiver as melhores funções de biblioteca para a tarefa. Mas em geral, para software de aplicação, você quer usar a linguagem mais poderosa (razoavelmente eficiente) que puder conseguir, e usar qualquer outra é um erro, exatamente do mesmo tipo, embora possivelmente em menor grau, que 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 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á uma linha divisória com as linguagens de máquina de um lado e todas as linguagens de alto nível do outro. As linguagens se espalham ao longo de um contínuo [4] de abstração, do mais poderoso até as linguagens de máquina, que variam em poder por si mesmas.

Considere o Cobol. O Cobol é uma linguagem de alto nível, no sentido de que é compilada em linguagem de máquina. Alguém argumentaria seriamente que o Cobol é equivalente em poder ao Python, por exemplo? Ele provavelmente está mais próximo da linguagem de máquina do que o Python.

Ou o que dizer do Perl 4? Entre o Perl 4 e o Perl 5, os fechamentos lexicais foram adicionados à linguagem. A maioria dos hackers de Perl concordaria que o Perl 5 é mais poderoso que o 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 se segue inexoravelmente que, exceto em casos especiais, você deve usar o mais poderoso que puder obter.

Essa ideia raramente é levada à sua conclusão, no entanto. Depois de uma certa idade, os programadores raramente trocam de linguagem voluntariamente. Qualquer que seja a linguagem à qual as pessoas estejam acostumadas, elas tendem a considerá-la apenas suficientemente boa.

Os programadores ficam muito apegados às suas linguagens favoritas, e não quero ferir os sentimentos de ninguém, então, para explicar esse ponto, vou usar uma linguagem hipotética chamada Blub. O Blub fica bem no meio do contínuo de abstração. Não é a linguagem mais poderosa, mas é mais poderosa que o Cobol ou a linguagem de máquina.

E, de fato, nosso programador hipotético de Blub não usaria nenhum deles. Claro que ele não programaria em linguagem de máquina. Esse é o trabalho dos compiladores. E quanto ao Cobol, ele não sabe como alguém pode fazer algo com ele. Nem mesmo tem x (recurso Blub de sua escolha).

Enquanto nosso programador hipotético de Blub estiver olhando para baixo no contínuo de poder, ele sabe que está olhando para baixo. Linguagens menos poderosas que o Blub são obviamente menos poderosas, porque estão faltando alguns recursos aos quais ele está acostumado. Mas quando nosso programador hipotético de Blub olha na outra direção, para cima no contínuo de poder, ele não percebe que está olhando para cima. O que ele vê são apenas linguagens estranhas. Ele provavelmente as considera aproximadamente equivalentes em poder ao Blub, mas com todo esse outro material complicado também. O Blub é bom o suficiente para ele, porque ele pensa em Blub.

Quando mudamos para o ponto de vista de um programador usando qualquer uma das linguagens mais altas no contínuo de poder, no entanto, descobrimos que ele, por sua vez, olha para baixo do Blub. Como você pode fazer algo no Blub? Nem mesmo 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 delas. (Provavelmente é o que Eric Raymond quis dizer sobre o Lisp torná-lo um programador melhor.) Você não pode confiar nas opiniões dos outros, por causa do paradoxo do Blub: eles estão satisfeitos com a linguagem que usam, porque ela dita a maneira como eles pensam sobre os programas.

Eu sei disso por minha própria experiência, como um adolescente escrevendo programas em Basic. Essa linguagem nem mesmo suportava recursão. É difícil imaginar escrever programas sem usar recursão, mas eu não senti falta disso na época. Eu pensava em Basic. E eu era um prodígio nela. Mestre de tudo o que eu observava.

As cinco linguagens que Eric Raymond recomenda aos hackers se encontram em vários pontos do contínuo de poder. Onde elas se encontram em relação umas às outras é um tópico delicado. O que eu direi é que acho que o Lisp está no topo. E para apoiar essa afirmação, vou lhe contar sobre uma das coisas que acho que falta quando olho para as outras quatro linguagens. Como você pode fazer algo nelas, eu penso, sem macros? [5]

Muitas línguas têm algo chamado de macro. Mas os macros Lisp são únicos. E acredite ou não, o que eles fazem está relacionado aos parênteses. Os designers do Lisp não colocaram todos aqueles parênteses na linguagem apenas para ser diferente. Para o programador Blub, o código Lisp parece estranho. Mas esses parênteses estão lá por uma razão. 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 strings são um dos tipos de dados suportados pela linguagem. O código Lisp, depois de 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 o Lisp tem uma sintaxe estranha, mas que o 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 as manipulam. No Lisp, esses programas são chamados de macros. Eles são programas que escrevem programas.

Programas que escrevem programas? Quando você alguma vez iria querer fazer isso? Não muito, se você pensar em Cobol. O tempo todo, se você pensar em Lisp. Seria conveniente aqui se eu pudesse dar um exemplo de um macro poderoso e dizer: "Aí está! O que você acha disso?" Mas se eu fizesse isso, pareceria apenas um monte de bobagens para alguém que não conhecesse o Lisp; não há espaço aqui para explicar tudo o que você precisaria saber para entender o que isso significa. Em Ansi Common Lisp, tentei avançar o mais rápido possível, e mesmo assim não cheguei aos macros até a página 160.

Mas acho que posso dar um tipo de argumento que possa ser convincente. O código-fonte do editor Viaweb provavelmente tinha cerca de 20-25% de macros. Macros são mais difíceis de escrever do que funções Lisp comuns, e é considerado um mau estilo usá-los quando não são necessários. Então cada macro nesse código está lá porque precisa estar. Isso significa que pelo menos 20-25% do código nesse programa está fazendo coisas que você não pode fazer facilmente em nenhuma outra linguagem. Por mais cético que o programador Blub possa ser sobre minhas reivindicações sobre os poderes misteriosos do Lisp, isso deveria deixá-lo curioso. Não estávamos escrevendo esse código apenas por diversão. Éramos uma startup minúscula, 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 fazia coisas que o software dos nossos concorrentes não conseguia fazer. Talvez houvesse algum tipo de conexão. Eu te incentivo a seguir esse fio. Pode haver mais naquele velho homem mancando em suas muletas do que parece.

Aikido para Startups

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

Se você pensar em usar o Lisp em uma startup, não deve se preocupar por ele não ser amplamente compreendido. Você deve esperar que continue assim. E é provável que continue. É na natureza das linguagens de programação deixar a maioria das pessoas satisfeita com o que elas usam atualmente. O hardware de computador muda muito mais rápido do que os hábitos pessoais, de modo que a prática de programação geralmente fica 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 bem até a década de 1980. Eu aposto que muitas pessoas continuaram a escrever linguagem de máquina até que o processador, como um barman ansioso para fechar e ir para casa, finalmente as expulsasse ao mudar para um conjunto de instruções RISC.

Normalmente, a tecnologia muda rapidamente. Mas as linguagens de programação são diferentes: as linguagens de programação não são apenas tecnologia, mas também o que os programadores pensam. Elas são metade tecnologia e metade religião.[6] E, portanto, a linguagem mediana, ou seja, qualquer linguagem que o programador mediano usa, se move tão lentamente quanto um iceberg. A coleta de lixo, introduzida pelo Lisp por volta de 1960, agora é amplamente considerada uma coisa boa. A digitação em tempo de execução, idem, está ganhando popularidade. Fechamentos léxicos, introduzidos pelo Lisp no início da década de 1970, estão agora, apenas por pouco, no radar. Macros, introduzidos pelo Lisp em meados da década de 1960, ainda são terra incógnita.

Obviamente, a linguagem mediana tem um enorme momentum. 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ê possa usá-la 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 deixá-lo construir coisas em Lisp, quando ele acabou de ler no jornal que outra linguagem está prestes, como o Ada há vinte anos, a dominar o mundo. Mas se você trabalha para uma startup que ainda não tem chefes de cabelo espetado, você pode, como nós fizemos, transformar o paradoxo de Blub a seu favor: você pode usar tecnologia que seus concorrentes, grudados imóveis na linguagem mediana, nunca serão capazes de igualar.

Se você algum dia se encontrar trabalhando para uma startup, aqui está uma dica útil para avaliar os concorrentes. Leia os anúncios de emprego deles. Tudo o mais em seu site pode ser fotos de estoque ou o equivalente em prosa, mas os anúncios de emprego têm que ser específicos sobre o que eles querem, caso contrário eles obterão os candidatos errados.

Durante os anos em que trabalhamos na Viaweb, li muitas descrições de emprego. Um novo concorrente parecia surgir do nada a cada mês ou algo assim. A primeira coisa que eu faria, depois de verificar se eles tinham uma demonstração online ativa, seria olhar os anúncios de emprego deles. Depois de alguns anos fazendo isso, eu conseguia dizer quais empresas me preocupar e quais não. Quanto mais um sabor de TI as descrições de emprego tivessem, menos perigosa a empresa seria. O tipo mais seguro eram os que queriam experiência em Oracle. Você nunca precisava se preocupar com esses. Você também estava seguro se eles dissessem que queriam desenvolvedores de C++ ou Java. Se eles quisessem programadores de Perl ou Python, isso seria um pouco assustador - isso começa a soar como uma empresa em que o lado técnico, pelo menos, é dirigido por hackers de verdade. Se eu tivesse visto alguma vez um anúncio de emprego procurando por hackers de Lisp, eu teria ficado realmente preocupado.

Notas

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

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

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

[3] Todas as linguagens são igualmente poderosas no sentido de serem equivalentes a Turing, 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ó poderia obter na linguagem menos poderosa escrevendo um interpretador para a linguagem mais poderosa nela. Se a linguagem A tiver um operador para remover espaços de strings e a linguagem B não tiver, provavelmente isso não torna A mais poderosa, porque você provavelmente pode escrever uma subrotina para fazê-lo em B. Mas se A suporta, digamos, recursão, e B não, isso provavelmente não é algo que você possa consertar escrevendo funções de biblioteca.

[4] Observação 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 há pelo menos uma ordem parcial.

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

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