SUPERANDO AS MÉDIAS

Abril de 2001, rev. Abril de 2003

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

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

Muitas pessoas podem ter tido essa ideia ao mesmo tempo, é claro, mas, até onde eu sei, a Viaweb foi o primeiro aplicativo baseado na Web. Parecia uma ideia tão nova para nós que demos o nome dela à empresa: Viaweb, porque nosso software funcionava pela 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 um dos primeiros grandes aplicativos de usuário final a ser escrito 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 Unix, e Perl para administração de sistemas e scripts cgi. Finalmente, o hacker realmente sério deve considerar aprender Lisp:

Vale a pena aprender Lisp pela profunda experiência de esclarecimento que você terá quando finalmente aprender; essa experiência fará de você um programador melhor pelo resto de seus dias, mesmo que você nunca use muito o Lisp.

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

Mas espere um minuto. Essa metáfora não se estende tanto. A razão pela qual o latim não lhe dará um emprego é que ninguém o fala. Se você escrever em latim, ninguém poderá entendê-lo. 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 você não iria querer usá-lo? Se um pintor recebesse um pincel que o tornaria um pintor melhor, parece-me que ele iria querer usá-lo em todas as suas pinturas, não é? Não estou tentando tirar sarro de Eric Raymond aqui. No geral, seu conselho é bom. O que ele diz sobre Lisp é basicamente a sabedoria convencional. Mas há uma contradição na sabedoria convencional: Lisp fará 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. Software é um negócio muito competitivo, propenso a monopólios naturais. Uma empresa que escreve software mais rápido e melhor irá, todas as outras coisas sendo iguais, tirar seus concorrentes do mercado. E quando você está começando uma startup, você sente isso muito intensamente. Startups tendem a ser uma proposta de tudo ou nada. Ou você fica rico, ou não ganha nada. Em uma startup, se você apostar na tecnologia errada, seus concorrentes vão esmagá-lo.

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

Isso é especialmente verdade 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. Acho que muitas pessoas não percebem isso, mesmo em startups.

A empresa grande média cresce cerca de dez por cento ao ano. Então, se você está dirigindo uma empresa grande e faz tudo do jeito que a empresa grande média faz, você pode esperar se sair tão bem quanto a empresa grande média-- ou seja, crescer cerca de dez por cento ao ano.

A mesma coisa vai acontecer se você estiver comandando uma startup, é claro. Se você fizer tudo do jeito que uma startup média faz, você deve esperar um desempenho médio. O problema aqui é que desempenho médio significa que você vai sair do mercado. A taxa de sobrevivência para startups é bem menor que cinquenta por cento. Então, se você estiver comandando uma startup, é melhor estar fazendo algo estranho. Se não, você está em apuros.

Em 1995, sabíamos algo que acho que nossos concorrentes não entendiam, e poucos entendem até agora: quando você está escrevendo um software que só precisa rodar em seus próprios servidores, você pode usar qualquer linguagem que quiser. Quando você está escrevendo um software de desktop, há uma forte tendência a escrever aplicativos na mesma linguagem do 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 espada de dois gumes, no entanto. Agora que você pode usar qualquer idioma, precisa pensar em qual usar. Empresas que tentam fingir que nada mudou correm o risco de descobrir que seus concorrentes não mudaram.

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 começando do zero, então uma empresa que pudesse obter novos recursos antes de seus concorrentes teria uma grande vantagem. Sabíamos que Lisp era uma linguagem muito boa para escrever software rapidamente, e aplicativos baseados em servidor ampliam o efeito do desenvolvimento rápido, porque você pode lançar software no minuto em que ele estiver pronto.

Se outras empresas não quisessem usar Lisp, tanto melhor. Poderia nos dar uma vantagem tecnológica, e precisávamos de toda a ajuda que pudéssemos obter. 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 jamais teve o que você chamaria de um emprego de verdade. A única coisa em que éramos bons era escrever software. Esperávamos que isso nos salvasse. Qualquer vantagem que pudéssemos obter no departamento de software, nós aproveitávamos.

Então você poderia dizer que usar Lisp foi um experimento. Nossa hipótese era que se escrevêssemos nosso software em Lisp, seríamos capazes de obter recursos mais rápido do que nossos concorrentes, e também fazer coisas em nosso software que eles não conseguiam fazer. E como Lisp era de alto nível, não precisaríamos de uma grande equipe de desenvolvimento, então nossos custos seriam menores. Se fosse assim, poderíamos oferecer um produto melhor por menos dinheiro, e ainda ter lucro. Acabaríamos obtendo todos os usuários, e nossos concorrentes não obteriam nenhum, e eventualmente sairiam do mercado. Era isso que esperávamos que acontecesse, de qualquer forma.

Quais foram os resultados desse experimento? Surpreendentemente, funcionou. Acabamos tendo muitos concorrentes, na ordem de vinte a trinta deles, mas nenhum software deles conseguia competir com o nosso. Tínhamos um construtor de loja online wysiwyg que rodava no servidor e ainda 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 podíamos duplicar um novo recurso em um ou dois dias após um concorrente anunciá-lo em um comunicado à imprensa. Quando os jornalistas que cobriam o comunicado à imprensa ligassem para nós, nós também teríamos o novo recurso.

Deve ter parecido aos 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. Nós apenas fomos capazes de desenvolver software mais rápido do que qualquer um pensava ser possível.

Quando eu tinha uns nove anos, por acaso consegui uma cópia de The Day of the Jackal, 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 subir até um apartamento com vista para a rota do presidente. Ele passa bem por eles, vestido como um velho de muletas, e eles nunca suspeitam dele.

Nossa arma secreta era parecida. Nós escrevemos nosso software em uma linguagem de IA estranha, com uma sintaxe bizarra cheia de parênteses. Por anos, me incomodou ouvir Lisp descrito dessa forma. Mas agora funcionava a nosso favor. Nos 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, estou um pouco envergonhado de dizer, eu nunca disse nada publicamente sobre Lisp enquanto trabalhávamos no Viaweb. Nós nunca mencionamos isso para a imprensa, e se você procurasse por Lisp em nosso site, tudo o que encontraria seriam os títulos de dois livros na minha biografia. Isso não foi acidente. Uma startup deve dar a seus concorrentes o mínimo de informações possível. Se eles não soubessem em que linguagem nosso software foi escrito, ou não se importassem, eu queria que continuasse assim.[2]

As pessoas que melhor entendiam nossa tecnologia eram os clientes. Eles também não se importavam com a linguagem em que o Viaweb era escrito, mas notaram que funcionava muito bem. Isso os deixou construir lojas online de ótima aparência literalmente em minutos. E assim, principalmente pelo boca a boca, conquistamos mais e 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 o 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 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 falar eram cerca de 20.000.

O paradoxo do Blub

O que há de tão bom em Lisp? E se Lisp é tão bom, por que nem todo mundo 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 nem todo mundo o usa é que linguagens de programação não são meramente tecnologias, mas hábitos mentais também, e nada muda mais devagar. Claro, ambas as respostas precisam ser explicadas.

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

Poucos contestariam, pelo menos, que 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 traduzindo-a para a linguagem de máquina para você. Essa ideia está até mesmo embutida no 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 seu programa inteiro à mão em linguagem de máquina. O que é menos compreendido é que há um princípio mais geral aqui: que se você tem a opção de escolher entre várias linguagens, é, todas as outras coisas sendo iguais, um erro programar em qualquer coisa que não seja a mais poderosa. [3]

Há muitas exceções a essa regra. Se você estiver escrevendo um programa que tem que trabalhar muito próximo de 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ó tem que fazer algo muito simples, como processamento numérico 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ê estiver escrevendo um programa curto e descartável, pode ser melhor usar qualquer linguagem que tenha as melhores funções de biblioteca para a tarefa. Mas, em geral, para software de aplicativo, você quer usar a linguagem mais poderosa (razoavelmente eficiente) que puder obter, e usar qualquer outra coisa é um erro, exatamente do mesmo tipo, embora possivelmente em menor grau, como programar em linguagem de máquina.

Você pode ver que a linguagem de máquina é de nível muito baixo. Mas, pelo menos como um tipo 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 caem em um continuum [4] de abstração, das mais poderosas até as linguagens de máquina, que variam em poder.

Considere Cobol. Cobol é uma linguagem de alto nível, no sentido de que é compilada em linguagem de máquina. Alguém argumentaria seriamente que Cobol é equivalente em poder a, digamos, Python? Provavelmente está mais perto de uma linguagem de máquina do que Python.

Ou que tal Perl 4? Entre Perl 4 e Perl 5, fechamentos 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-se inexoravelmente que, exceto em casos especiais, você deve usar o mais poderoso que puder obter.

Essa ideia raramente é seguida até a conclusão, no entanto. Depois de uma certa idade, os programadores raramente trocam de idioma voluntariamente. Não importa qual idioma as pessoas estejam acostumadas, elas tendem a considerar apenas bom o suficiente.

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

E, de fato, nosso hipotético programador Blub 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 tem x (recurso Blub de sua escolha).

Enquanto nosso hipotético programador Blub estiver olhando para baixo no continuum de potência, ele sabe que está olhando para baixo. Linguagens menos poderosas que Blub são obviamente menos poderosas, porque estão faltando algum recurso que ele está acostumado. Mas quando nosso hipotético programador Blub olha na outra direção, para cima no continuum de potência, 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 todas essas outras coisas cabeludas jogadas 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 uma das linguagens mais acima no continuum de poder, no entanto, descobrimos que ele, por sua vez, menospreza o Blub. Como você consegue fazer alguma coisa no Blub? Ele nem 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 de Blub: eles ficam satisfeitos com qualquer linguagem que usam, porque ela dita a maneira como pensam sobre programas.

Eu 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 disso na época. Eu pensava em Basic. E eu era um gênio nisso. Mestre em tudo que eu pesquisava.

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

Muitas linguagens têm algo chamado macro. Mas macros Lisp são únicas. E acredite ou não, o que elas fazem está relacionado aos parênteses. Os designers do Lisp não colocaram todos esses parênteses na linguagem só para ser diferente. 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 strings são um dos tipos de dados suportados pela linguagem. O código Lisp, depois de ser lido pelo parser, é feito de estruturas de dados que você pode percorrer.

Se você entende 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ê gostaria de fazer isso? Não muito frequentemente, se você pensa em Cobol. O tempo todo, se você pensa em Lisp. Seria conveniente aqui se eu pudesse dar um exemplo de uma macro poderosa, e dizer lá! que tal isso? Mas se eu fizesse, pareceria apenas um jargão para alguém que não conhecesse Lisp; não há espaço aqui para explicar tudo o que você precisa saber para entender o que isso significa. Em Ansi Common Lisp, tentei mover as coisas o mais rápido que pude, 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. 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 naquele código está lá porque tem que estar. O que isso significa é que pelo menos 20-25% do código neste 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 alegações sobre os poderes misteriosos do Lisp, isso deve deixá-lo curioso. Não estávamos escrevendo este código para nossa própria diversão. Éramos uma pequena startup, programando o mais duro 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 o encorajo a seguir esse tópico. Pode haver mais naquele velho mancando com suas muletas do que aparenta.

Aikido para Startups

Mas não espero convencer ninguém ( acima de 25 ) a sair e aprender Lisp. O propósito deste artigo não é mudar a mente de ninguém, mas tranquilizar as pessoas já interessadas em usar Lisp — pessoas que sabem que Lisp é uma linguagem poderosa, mas se preocupam porque ela não é amplamente usada. 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ê pensa em usar Lisp em uma startup, não deve se preocupar que ele não seja amplamente compreendido. Você deve torcer para que continue assim. E é provável que continue. É da natureza das linguagens de programação deixar a maioria das pessoas satisfeitas com o que elas usam atualmente. O hardware do computador muda muito mais rápido do que os hábitos pessoais, de modo que a prática de programação geralmente está de 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 dos anos 1960, mas muitas empresas continuaram a escrever código em linguagem de máquina até os anos 1980. 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 os expulsou, mudando para um conjunto de instruções risc.

Normalmente a tecnologia muda rápido. Mas linguagens de programação são diferentes: 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 então a linguagem mediana, significando qualquer linguagem que o programador mediano usa, move-se 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á crescendo em popularidade. Os fechamentos lexicais, introduzidos pelo Lisp no início dos anos 1970, estão agora, apenas um pouco, na tela do radar. As macros, introduzidas pelo Lisp em meados dos anos 1960, ainda são terra incógnita.

Obviamente, a linguagem mediana tem um momentum enorme. 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á-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 cabelos espetados 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 dominar o mundo. Mas se você trabalha para uma startup que ainda não tem chefes de cabelos espetados, você pode, como nós fizemos, transformar o paradoxo Blub a seu favor: você pode usar tecnologia que seus concorrentes, colados inamovivelmente à linguagem mediana, nunca serão capazes de igualar.

Se você se encontrar trabalhando para uma startup, aqui vai uma dica útil para avaliar concorrentes. Leia as listas de empregos deles. Todo o resto no site deles pode ser fotos de stock ou o equivalente em prosa, mas as listas de empregos têm que ser específicas sobre o que eles querem, ou eles vão pegar 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 algo assim. A primeira coisa que eu fazia, depois de verificar se eles tinham uma demonstração on-line ao vivo, era olhar suas listas de vagas. Depois de alguns anos disso, eu sabia com quais empresas me preocupar e com quais não. Quanto mais um toque de TI as descrições de vagas tinham, menos perigosa era a empresa. O tipo mais seguro era aquele que queria experiência em Oracle. Você nunca precisava se preocupar com isso. 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 um anúncio de emprego procurando por hackers 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 lidava com pedidos. A primeira versão era basicamente 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, 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, até onde eu sei, código Lisp. (Veja a Décima Regra de Greenspun .)

[2] Robert Morris diz que eu não precisava ser reservado, porque mesmo que nossos concorrentes soubessem que estávamos usando Lisp, eles não entenderiam 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 equivalentes a Turing, mas esse não é o sentido da palavra com que os programadores se importam. (Ninguém quer programar uma máquina de Turing.) O tipo de poder com 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 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 provavelmente não é algo que você pode consertar escrevendo funções de biblioteca.

[4] Nota para os nerds: ou possivelmente uma treliça, estreitando 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 é bastante aprimorada por outros recursos do Lisp, como fechamentos lexicais e parâmetros rest.

[6] Como resultado, as comparações de linguagens de programação ou tomam a forma de guerras religiosas ou de livros didáticos de graduação tão determinadamente neutros que são realmente obras de antropologia. 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.