SUPERANDO AS MÉDIAS

Abril de 2001, rev. Abril de 2003

(Este artigo é derivado de uma palestra dada 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 um software que permitisse aos usuários finais construir 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 poderiam ter 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 em sua homenagem: Viaweb, porque nosso software funcionava via Web, em vez de rodar em 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 para usuários finais a serem escritas em Lisp, que até então tinha 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 querrá 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:

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 Lisp muito.

Este é o mesmo argumento que você tende a ouvir para aprender latim. Não vai te garantir 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 deseja usar, como o inglês.

Mas espere um minuto. Essa metáfora não se estende tanto. A razão pela qual o latim não vai te garantir um emprego é que ninguém fala isso. Se você escrever em latim, ninguém pode entender você. Mas Lisp é uma linguagem de computador, e os computadores falam qualquer linguagem que você, o programador, dizer a eles.

Então, se Lisp faz de você um programador melhor, como ele diz, por que você não querria usá-lo? Se um pintor fosse oferecido um pincel que o tornaria um pintor melhor, parece que ele querria usá-lo 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 Lisp é praticamente 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 o usará.

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 produz, 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 consegue escrever software mais rápido e melhor vai, todas as outras coisas sendo iguais, colocar seus concorrentes fora do mercado. E quando você está começando uma startup, você sente isso muito intensamente. As startups tendem a ser uma proposta tudo ou nada. Você ou fica rico, ou não ganha nada. Em uma startup, se você apostar na tecnologia errada, seus concorrentes vão te esmagar.

Robert e eu conhecíamos bem Lisp, e não conseguíamos ver nenhuma razão para não confiar em nossos instintos e seguir com 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 forma, você estaria rodando Windows. Quando você escolhe tecnologia, você tem que ignorar o que os outros estão fazendo e considerar apenas o que 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 uma grande empresa cresce cerca de dez por cento ao ano. Então, se você está gerenciando uma grande empresa e faz tudo da maneira que a empresa média faz, pode esperar ter um desempenho tão bom quanto a empresa média-- 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 maneira que a startup média faz, deve esperar um desempenho médio. O problema aqui é que um desempenho médio significa que você vai sair do mercado. A taxa de sobrevivência para startups é muito inferior a cinquenta por cento. Então, se você está gerenciando uma startup, é melhor que você esteja fazendo algo estranho. Se não, você está em apuros.

Em 1995, sabíamos algo que não acho que nossos concorrentes entendiam, e poucos entendem até agora: 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 em favor de escrever aplicações na mesma linguagem que o sistema operacional. Dez anos atrás, escrever aplicações significava escrever aplicações em C. Mas com 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 espada de dois gumes, no entanto. Agora que você pode usar qualquer linguagem, você tem que pensar sobre qual usar. Empresas que tentam fingir que nada mudou correm o risco de descobrir que seus concorrentes não fazem isso.

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 concluir novos recursos antes de seus concorrentes teria uma grande vantagem. Sabíamos que Lisp era uma linguagem realmente boa para escrever software rapidamente, e aplicações baseadas em servidor amplificam o efeito do desenvolvimento rápido, porque você pode liberar software no minuto em que 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 obter. 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 nunca tido 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 na área de software, nós aproveitaríamos.

Então você poderia dizer que usar Lisp foi um experimento. Nossa hipótese era que se escrevêssemos nosso software em Lisp, conseguiríamos concluir recursos mais rápido do que nossos concorrentes, e também fazer coisas em nosso software que eles não podiam fazer. E como Lisp era tão de alto nível, não precisaríamos de uma grande equipe de desenvolvimento, então nossos custos seriam mais baixos. Se isso fosse verdade, poderíamos oferecer um produto melhor por menos dinheiro, e ainda assim ter lucro. Acabaríamos conseguindo todos os usuários, e nossos concorrentes não teriam nenhum, e eventualmente sairiam do mercado. Essa era a nossa esperança, de qualquer forma.

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

Devia parecer para nossos concorrentes que tínhamos algum tipo de arma secreta-- que estávamos decodificando o tráfego de suas Enigmas 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 conseguíamos 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 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 chegar a um apartamento que tem vista para a rota do presidente. Ele passa bem ao lado deles, vestido como um velho com 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. Durante anos me irritou ouvir Lisp descrito dessa forma. Mas agora isso trabalhou 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 assim, estou um pouco envergonhado de dizer que nunca disse nada publicamente sobre Lisp enquanto estávamos trabalhando na Viaweb. Nunca mencionamos isso à imprensa, e se você procurasse por Lisp em nosso site, tudo o que encontraria seriam os títulos de dois livros em minha biografia. Isso não foi um acidente. Uma startup deve dar a seus concorrentes o mínimo de informação possível. Se eles não soubessem em que linguagem nosso software foi escrito, ou não se importassem, eu queria manter assim.[2]

As pessoas que entendiam nossa tecnologia melhor eram os clientes. Eles também não se importavam com a linguagem em que a Viaweb foi escrita, mas notaram que funcionava muito bem. Isso lhes permitiu construir lojas online com ótima aparência literalmente em minutos. E assim, principalmente por meio do boca a boca, conseguimos 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 1070 usuários. Hoje, como Yahoo Store, esse software continua a dominar seu mercado. É uma das partes mais lucrativas do Yahoo, e as lojas construídas com ele são a base do Yahoo Shopping. Eu deixei o Yahoo em 1999, então não sei exatamente quantos usuários eles têm agora, mas a última vez que ouvi, havia cerca de 20.000.

O Paradoxo Blub

O que há de tão bom em Lisp? E se Lisp é tão bom, por que ninguém o usa? Essas parecem perguntas retóricas, mas na verdade 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 todos não a usam é que as linguagens de programação não são apenas tecnologias, mas hábitos de pensamento também, e nada muda mais devagar. É claro que ambas as respostas precisam de explicação.

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 que a traduza para a linguagem de máquina para você. Essa ideia está até incorporada no hardware agora: desde a década de 1980, conjuntos de instruções foram projetados para compiladores em vez de programadores humanos.

Todos sabem que é um erro escrever todo o seu programa à mão em linguagem de máquina. O que é menos frequentemente entendido é que há um princípio mais geral aqui: que se você tem a escolha de 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ê está escrevendo um programa que precisa trabalhar muito de perto com um programa escrito em uma certa 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 processamento de números ou manipulação de bits, pode muito bem usar uma linguagem menos abstrata, especialmente porque pode ser um pouco mais rápido. E se você está escrevendo um programa curto e descartável, pode ser melhor apenas usar 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, do mesmo tipo, embora possivelmente em um grau menor, 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, 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 ao longo de um continuum [4] de abstração, desde as mais poderosas até as linguagens de máquina, que por si mesmas variam em poder.

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

Ou que tal Perl 4? Entre Perl 4 e Perl 5, closures lexicais foram adicionadas à linguagem. A maioria dos hackers de Perl concordaria que Perl 5 é mais poderoso do que Perl 4. Mas uma vez que você admitiu isso, você admitiu que uma linguagem de alto nível pode ser mais poderosa do que outra. E segue-se 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. Após uma certa idade, programadores raramente mudam de linguagem voluntariamente. Qualquer que seja a linguagem à qual as pessoas estão acostumadas, elas tendem a considerar apenas boa o suficiente.

Os programadores se apegam muito à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. Blub cai bem no meio do continuum de abstração. Não é a linguagem mais poderosa, mas é mais poderosa do que Cobol ou linguagem de máquina.

E, de fato, nosso hipotético programador Blub não usaria nenhuma delas. É claro que ele não programaria em linguagem de máquina. Para isso servem os compiladores. E quanto ao Cobol, ele não sabe como alguém pode fazer algo com ele. Ele nem mesmo tem x (recurso Blub de sua escolha).

Enquanto nosso hipotético programador Blub está olhando para baixo no continuum de poder, ele sabe que está olhando para baixo. Linguagens menos poderosas do que Blub são obviamente menos poderosas, porque estão faltando algum recurso ao qual ele está acostumado. Mas quando nosso hipotético programador Blub 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 aproximadamente equivalentes em poder a Blub, mas com toda essa outra coisa estranha 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 uma das linguagens mais altas no continuum de poder, no entanto, descobrimos que ele, por sua vez, olha para baixo para Blub. Como você pode fazer algo em Blub? Ele 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. (Isso é provavelmente o 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 pensam sobre programas.

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

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

Muitas linguagens têm algo chamado macro. Mas as macros de Lisp são únicas. E acredite ou não, o que elas fazem está relacionado aos parênteses. Os designers de Lisp não colocaram todos aqueles parênteses na linguagem apenas para serem diferentes. Para o programador Blub, o código Lisp parece estranho. Mas aqueles 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 fonte contêm caracteres, e 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 navegar.

Se você entende 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 as manipulam. Em Lisp, esses programas são chamados de macros. Elas 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 absurdo para alguém que não soubesse Lisp; não há espaço aqui para explicar tudo o que você precisaria saber para entender o que isso significava. Em Ansi Common Lisp tentei avançar o mais rápido que pude, e mesmo assim não cheguei às macros até a página 160.

Mas acho que posso dar uma espécie de argumento que pode ser convincente. O código-fonte do editor da 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 mau estilo usá-las quando não são necessárias. Então, cada macro naquele código está lá porque precisa estar. O que isso significa é que pelo menos 20-25% do código neste programa está fazendo coisas que você não pode facilmente fazer em qualquer outra linguagem. No entanto, por mais cético que o programador Blub possa ser em relação às minhas afirmações sobre os poderes misteriosos de Lisp, isso deve deixá-lo curioso. Não estávamos escrevendo esse código para nosso próprio divertimento. Éramos uma pequena startup, programando o mais duro que podíamos para colocar barreiras técnicas entre nós e nossos concorrentes.

Uma pessoa suspeita pode começar a se perguntar se há alguma correlação aqui. Um grande pedaço 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 de nossos concorrentes não podia fazer. Talvez houvesse algum tipo de conexão. Eu encorajo você a seguir esse fio. Pode haver mais naquele velho homem mancando em suas muletas do que aparenta.

Aikido para Startups

Mas não espero convencer ninguém (mais de 25) a sair e aprender Lisp. O propósito deste artigo não é mudar a opinião de ninguém, mas tranquilizar pessoas já interessadas em usar Lisp-- pessoas que sabem que Lisp é uma linguagem poderosa, mas se preocupam porque não é amplamente utilizada. Em uma situação competitiva, isso é uma vantagem. O poder de 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 é amplamente compreendido. Você deve esperar que continue assim. E é provável que continue. É da natureza das linguagens de programação fazer com que a maioria das pessoas fique satisfeita com qualquer coisa que estejam usando atualmente. O hardware de computador muda muito mais rápido do que hábitos pessoais, de modo que 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 escrevendo código em linguagem de máquina bem até a década de 1980. Aposto que muitas pessoas continuaram a escrever em linguagem de máquina até que o processador, como um barman ansioso para fechar e ir para casa, finalmente os expulsou ao mudar para um conjunto de instruções risc.

Ordinary technology changes fast. But programming languages are different: programming languages are not just technology, but what programmers think in. They're half technology and half religion.[6] And so the median language, meaning whatever language the median programmer uses, moves as slow as an iceberg. Garbage collection, introduced by Lisp in about 1960, is now widely considered to be a good thing. Runtime typing, ditto, is growing in popularity. Lexical closures, introduced by Lisp in the early 1970s, are now, just barely, on the radar screen. Macros, introduced by Lisp in the mid 1960s, are still 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á-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 pontudo a deixá-lo construir coisas em Lisp, quando ele acabou de ler no jornal que alguma outra linguagem está prestes a, como Ada estava há vinte anos, dominar o mundo. Mas se você trabalha para uma startup que ainda não tem chefes de cabelo pontudo, você pode, como nós fizemos, transformar o paradoxo Blub a seu favor: você pode usar tecnologia que seus concorrentes, colados imutavelmente à 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 concorrentes. Leia suas listas de empregos. Todo o resto em seu site pode ser fotos de banco de imagens ou o equivalente em prosa, mas as listas de empregos precisam ser específicas sobre o que querem, ou eles receberão os candidatos errados.

Durante os anos em que trabalhamos na Viaweb, li muitas descrições de empregos. Um novo concorrente parecia surgir do nada a cada mês. A primeira coisa que eu faria, depois de verificar se eles tinham uma demonstração online ao vivo, era olhar suas listas de empregos. Depois de alguns anos disso, eu podia dizer quais empresas eram preocupantes e quais não eram. Quanto mais o sabor de TI as descrições de empregos tinham, menos perigosa a empresa era. O tipo mais seguro era aquele que queria experiência em Oracle. Você nunca precisava se preocupar com esses. 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 começava a soar como uma empresa onde o lado técnico, pelo menos, é dirigido por verdadeiros hackers. Se eu tivesse visto uma postagem de emprego procurando hackers Lisp, eu teria ficado realmente preocupado.

Notas

[1] A Viaweb no início 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, um gerador de imagens escrito em C, e um gerente de back-office 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, porque para traduzir esse programa para C++, eles literalmente tiveram que escrever um interpretador Lisp: os arquivos fonte de todos os templates geradores de páginas ainda são, até onde sei, código Lisp. (Veja A Décima Regra 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 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 tem um operador para remover espaços de strings e a linguagem B não tem, 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 corrigir 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 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 de Lisp, como closures lexicais e parâmetros rest.

[6] Como resultado, comparações de linguagens de programação ou assumem a forma de guerras religiosas ou de livros didáticos de graduação tão decididamente neutros que são realmente obras de antropologia. Pessoas que valorizam sua paz, ou querem tenure, 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.