Tradução do texto “Beating the Averages”, por Paul Graham.
Tradução: Helio H. Monte-Alto
Link para o texto original: http://www.paulgraham.com/avg.html
No verão de 1995, meu amigo Robert Morris e eu começamos uma empresa startup chamada Viaweb. Nosso plano era escrever um software que permitisse aos usuários finais construírem lojas virtuais. O que era inovador sobre esse software, naquela época, é que ele rodava em nosso servidor usando páginas Web comuns como interface.
Muitas pessoas poderiam ter tido essa ideia naquela época, é claro, mas até onde eu sei, Viaweb foi a primeira aplicação baseada na Web. Nos parecia uma ideia tão inovadora que demos o mesmo nome à empresa – Viaweb – pois nosso software funcionava via Web em vez de rodar em seu computador pessoal.
Outra coisa incomum sobre esse software era o fato de ele ser escrito primariamente em uma linguagem chamada Lisp. Foi um das primeiras grandes aplicações para usuário final já escritas em Lisp, que até o momento tinha sido usada principalmente em universidades e laboratórios de pesquisa. [1]
— A Arma Secreta —
Eric Raymond tinha escrito uma tese chamada “Como se Tornar um Hacker”, e nela, dentre outras coisas, ele dizia quais linguagens um aspirante a hacker deveria aprender. Ele sugere começar com Python e Java, porque são fáceis de aprender. O hacker sério também desejaria aprender C para poder hackear o Unix, e Perl para administração de sistema e scripts cgi. Finalmente, o hacker realmente sério deveria considerar aprender Lisp:
“”Vale a pena aprender Lisp pela profunda experiência de iluminação que você terá após dominá-lo. Tal experiência te tornará um programador melhor pelo resto de teus dias, mesmo se você não usar a linguagem com muita frequência.””
É o mesmo argumento que você tende a ouvir sobre aprender Latim. Não vai te arrumar um emprego, exceto talvez como um professor erudito, mas irá melhorar sua mente e fazê-lo um melhor escritor nas linguagens que você deseja usar, como o Inglês ou Português.
Mas, espere um minuto. Essa metáfora não pode ir tão longe. O motivo pelo qual o Latim não te arrumará um emprego é que ninguém fala essa língua. Se você escrever em Latim, ninguém consegue te entender. Mas Lisp é uma linguagem de computadores, e computadores falam qualquer linguagem que você, o programador, quiser.
Então, se o Lisp te torna um programador melhor, como ele diz, por que você não desejaria usá-lo? Se oferecessem a um pintor um pincel que o tornaria um pintor melhor, imagino que ele desejaria 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 é o que diz a sabedoria convencional. Mas há uma contradição na sabedoria convencional: Lisp te tornará um programador melhor, e ainda assim você não irá usá-lo.
Por que não? Linguagens de programação são apenas ferramentas, afinal. Se o Lisp realmente produz melhores programas, você deveria usá-lo. E se não o faz, então quem precisa dele?
Essa não é apenas uma questão teórica. Software é um negócio muito competitivo, naturalmente sujeito a monopólios. Uma empresa que adquire um software escrito mais rapidamente e melhor irá, sendo todas as outras coisas iguais, colocar seus concorrentes fora do negócio. E quando você está iniciando uma empresa, você sente isso muito sutilmente. Empresas startup tendem a se tornar tudo ou nada. Ou você fica rico, ou você não ganha nada. Em uma startup, se você apostar na tecnologia errada, seus concorrentes irão esmagá-lo.
Robert e eu conhecíamos bem o Lisp, e não podíamos ver motivo algum para não confiar em nossos instintos e ir de Lisp. Sabíamos que o resto do mundo estava escrevendo seus softwares em C++ ou Perl. Mas também sabíamos que isso não significava nada. Se você escolhesse tecnologia dessa forma, você sempre escolheria o Windows como sistema operacional. Quando você escolhe uma tecnologia, você tem que ignorar o que as outras pessoas estão fazendo e considerar apenas o que vai funcionar melhor.
Isto é especialmente verdadeiro em uma startup. Em uma empresa grande, você pode fazer o que todas as outras empresas estão fazendo. Mas uma startup não pode fazer o que todas as outras startup fazem. Eu acho que muita gente não percebe isso, mesmo em startups.
A empresa grande e na média cresce cerca de dez por cento ao ano. Então, se você está tocando uma grande empresa e você faz tudo da mesma forma que as outras empresas grandes e medíocres fazem, você pode esperar fazer tão bem quanto as outras empresas grandes e medíocres – isto é, crescer cerca de dez por cento ao ano.
O mesmo ocorre se você estiver tocando uma startup, é claro. Se você fizer tudo do jeito que as startup na média fazem, você deveria esperar um desempenho medíocre. O problema aqui é: um desempenho medíocre significa que você vai acabar caindo fora dos negócios. A taxa de sobrevivência para startups é muito menor do que cinquenta por cento. Então, se você está tocando uma startup, é bom que você faça algo estranho. Senão, você estará em apuros.
Voltando a 1995, sabíamos de algo que eu acho que nossos concorrentes não entendiam, e poucos entendem ainda hoje: quando você está escrevendo software que deve rodar apenas em seu próprio servidor, você pode usar qualquer linguagem que você quiser. Quando você está escrevendo um software para desktop, há uma forte tendência a escrever aplicações na mesma linguagem do sistema operacional. Dez anos antes, 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 você quiser.
Essa nova liberdade é, no entanto, uma espada de dois gumes. Agora que você pode usar qualquer linguagem, você deve pensar bem em qual usar. Empresas que tentam fingir que nada mudou se arriscam a descobrir que seus concorrentes não fazem o mesmo.
Se você pode usar qualquer linguagem, qual você usa? Nós escolhemos o Lisp. Por um lado, era óbvio que o desenvolvimento rápido seria importante nesse mercado. Estávamos todos começando do zero, então uma empresa que pudesse obter novas funcionalidades feitas 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 ampliavam o efeito do desenvolvimento rápido, porque você pode liberar o software no minuto em que ele é feito.
Se outras empresas não queriam usar o Lisp, tanto melhor. Isto poderia nos dar uma vantagem tecnológica, e precisávamos de toda a ajuda possível. Quando começamos o Viaweb, não tínhamos experiência com os negócios. Não sabíamos nada sobre marketing, ou sobre contratar pessoas, ou sobre fazer dinheiro, ou conseguir clientes. Nenhum de nós tínhamos sequer 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 salvaria. Qualquer vantagem que pudéssemos obter no departamento de software, nós agarraríamos.
Podemos dizer que usar o Lisp era um experimento. Nossa hipótese era que, se escrevêssemos nosso software em Lisp, seríamos capazes de conseguir funcionalidades feitas mais rapidamente do que nossos concorrentes, e também fazer coisas em nosso software que eles não poderiam fazer. E como o Lisp é de tão alto nível, não precisaríamos de uma equipe de desenvolvimento grande, logo nossos custos seriam menores. Se desse certo, poderíamos oferecer um produto melhor por menos dinheiro, e ainda fazer um lucro. Terminaríamos adquirindo todos os usuários, e nossos competidores não teriam nada e, eventualmente, sairiam do negócio. Isso era o que esperávamos que acontecesse, afinal.
Quais foram os resultados desse experimento? Surpreendentemente, funcionou. Eventualmente tínhamos muitos concorrentes, na ordem de vinte a trinta deles, mas nenhum dos software deles podia competir com o nosso. Tínhamos um construtor WYSIWYG de lojas online que rodava no nosso servidor e ainda parecia uma aplicação para desktop. Nossos concorrentes tinham scripts cgi. E nós estávamos sempre muito à frente deles em funcionalidades. Às vezes, em desespero, os concorrentes tentavam introduzir funcionalidades que nós não tínhamos. Mas com o Lisp, o nosso ciclo de desenvolvimento era tão rápido que podíamos, às vezes, imitar uma nova funcionalidade dentro de um dia ou dois depois do anúncio dos nossos concorrentes em um comunicado de imprensa. Era só os jornalistas colocarem o comunicado de imprensa em circulação que lá estávamos nós com a mesma nova funcionalidade do concorrente.
Deve ter parecido, para nossos concorrentes, que tínhamos algum tipo de arma secreta – que nós estaríamos decodificando o tráfego de rede deles ou algo assim. De fato nós tínhamos uma arma secreta, mas era mais simples do que eles imaginavam. Ninguém estava deixando vazar as notícias de suas funcionalidade para nós. Nós apenas éramos capazes de desenvolver software mais rápido do que qualquer um pensava ser possível.
Quando eu tinha uns nove anos aconteceu de eu ganhar uma cópia do filme “O Dia do Chacal”, de Frederick Forsyth. O principal personagem é um assassino que é contratado para matar o presidente da França. O assassino tem que passar pela polícia para chegar a um apartamento com vista para a rota do presidente. Ele anda normalmente no meio dos policiais, vestido como um velho de muletas, e eles nunca suspeitam dele.
Nossa arma secreta era algo parecido. Nós escrevíamos nosso software um uma estranha linguagem de IA (Inteligência Artificial), com uma sintaxe bizarra cheia de parênteses. Por anos, me irritou ouvir o Lisp sendo descrito dessa maneira. Mas agora ele 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 assim, eu estou um pouco envergonhado de dizer, mas eu nunca disse nada publicamente sobre o Lisp enquanto estávamos trabalhando no Viaweb. Nunca o mencionamos à imprensa, e se você procurasse por Lisp em nosso site, tudo o que você encontraria seriam os títulos de dois livros em minha biografia. Isto não foi um acidente. Uma startup deve dar a seus competidores o mínimo de informação possível. Se eles não soubessem em que linguagem nosso software era escrito, ou não se importassem, eu preferia que isso permanecesse assim. [2]
As pessoas que melhor entendiam nossa tecnologia eram nossos clientes. Eles não se importavam com qual linguagem o Viaweb era escrito, mas eles percebiam que funcionava muito bem. Ela permitia a eles construirem lojas virtuais com ótima aparência literalmente em minutos. E assim, de boca em boca, principalmente, conseguíamos mais e mais usuários. Ao final de 1996 tínhamos cerca de 70 lojas online. Ao final de 1997, tínhamos 500. Seis meses depois, quando a Yahoo nos comprou, tínhamos 1070 usuários. Hoje (2001), como Yahoo Store, esse software continua dominando o mercado. É um dos pedaços mais lucrativos do Yahoo, e as lojas construídas com ele são o fundamento do Yahoo Shopping. Eu deixei a Yahoo em 1999, então não sei exatamente quantos usuários eles têm agora, mas da última vez que ouvi havia cerca de 20.000.
— O Paradoxo Blub —
O que há de tão bom no Lisp? E, se Lisp é tão bom, por que as pessoas não o utilizam? Isto soa como perguntas retóricas, mas na verdade elas têm respostas bastante diretas. Lisp é tão bom, não por causa de alguma qualidade mágica visível apenas aos devotos, mas porque ela é simplesmente a mais poderosa linguagem disponível. E o motivo pelo qual as pessoas não o usam é porque linguagens de programação não são meramente tecnologias, mas também hábitos mentais, e nada é mais resistente a mudanças do que isso. É claro, essas duas respostas requerem uma explicação.
Vou começar com uma afirmação chocante e controversa: linguagens de programação variam em poder.
Poucos discutiriam, ao menos, que linguagens de alto nível são mais poderosas que linguagem de máquina. A maioria dos programadores hoje em dia concordam que você normalmente não desejaria programar em linguagem de máquina. Em vez disso, você deveria programar em uma linguagem de alto nível, com um compilador que a traduza em linguagem de máquina para você. Esta ideia é posta em prática até mesmo no hardware: desde os anos 80, conjuntos de instruções têm sido projetados para compiladores em vez de programadores humanos.
Todo mundo sabe que é um erro escrever um programa inteiro, na mão, em linguagem de máquina. O que é ainda menos frequentemente entendido é que há um princípio mais geral aqui: que se você tem que fazer uma escolha entre várias linguagens, seria 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 funcionar em conjunto com outro programa escrito em uma certa linguagem, pode ser uma boa ideia escrever o novo programa na mesma linguagem. Se você estiver escrevendo um programa que deve apenas fazer algo muito simples, como processamento de números e manipulação de bits, você pode também usar uma linguagem menos abstrata, especialmente se ela for mais rápida (ex: linguagem C). E se você está escrevendo um programa pequeno e descartável, talvez seja melhor você simplesmente usar qualquer linguagem que tenha as melhores funções em bibliotecas para a tarefa. Mas em geral, para software de aplicação, você vai desejar usar a linguagem mais poderosa (e razoavelmente eficiente) que você puder, e usar qualquer outra coisa seria um erro exatamente do mesmo tipo, embora possivelmente em um grau menor, do erro de programar em linguagem de máquina.
Você pode ver que linguagem de máquina é muito baixo nível. Mas, ao menos como um tipo 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 que separa linguagens de máquina de um lado e todas as linguagens de alto nível do outro. Linguagens se encaixam ao longo de um continuum [4] de abstratividade, partindo da mais poderosa, percorrendo todo o caminho até as linguagens de máquina, variando em poder.
Considere Cobol. Cobol é uma linguagem de alto nível, no sentido de ser compilada para linguagem de máquina. Alguém, em sã consciência, argumentaria que Cobol é equivalente em poder a, digamos, Python? Cobol é provavelmente mais próxima de uma linguagem de máquina do que Python.
E quanto ao Perl 4? Entre Perl 4 e Perl 5, closures léxicos foram adicionados à linguagem. A maioria dos hackers que programam em Perl 4 concordariam que Perl 5 é mais poderoso que Perl 4 [[Nota do tradutor: A mesma analogia pode ser usada em relação ao Java, sendo Java 8 > Java 7, por exemplo]]. Mas uma vez que você admite isso, você está admitindo que uma linguagem de alto nível pode ser mais poderosa que outra. E disso segue inexoravelmente que, com exceção de alguns casos especiais, você deveria usar a linguagem mais poderosa que você conseguir.
Esta ideia, no entanto, é raramente acompanhada de sua conclusão. Depois de uma certa idade, os programadores raramente trocam de linguagem voluntariamente. Qualquer linguagem que as pessoas estiverem acostumadas a usar, elas tendem a considerar boas o suficiente.
Programadores se tornam muito ligados a suas linguagens favoritas, e não quero ferir os sentimentos de ninguém. Então, para explicar esse ponto de vista vou usar uma linguagem hipotética chamada Blub. Blub cai bem no meio do continuum de abstratividade. Não é a linguagem mais poderosa, mas é mais poderosa que Cobol e linguagem de máquina.
E de fato, nosso hipotético programador Blub não usaria nenhum destes (Cobol e linguagem de máquina). É 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 conseguir fazer alguma coisa nele. Ele nem mesmo tem ‘x’ (um recurso qualquer que o Blub tenha).
Enquanto nosso hipotético programador Blub olha mais para baixo no continuum de poder, ele sabe que está olhando para baixo. Linguagens menos poderosas que Blub são obviamente menos poderosas, porque elas não têm alguns dos recursos que 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 meramente linguagens estranhas. Ele provavelmente as considera meio que equivalentes em poder ao Blub, mas acompanhadas de todas as outras coisas cabeludas. Blub é bom o suficiente para ele, porque ele pensa em Blub.
Quando mudamos, no entanto, para o ponto de vista de um programador usando qualquer uma das linguagens mais acima no continuum de poder descobrimos que ele, ao olhar para baixo, vê o Blub. Como você pode fazer qualquer coisa em Blub? Ele nem mesmo tem o recurso ‘y’.
Por indução, os únicos programadores em uma posição que permite ver todas as diferenças de poder entre as várias linguagens são aqueles que entendem a mais poderosa. (Isto é provavelmente o que o Eric Raymond quis dizer sobre Lisp te tornar 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 eles estejam acostumados a usar, porque elas ditam a forma com que eles pensam sobre programas.
Eu sei disso pela minha própria experiência como um garoto no ensino médio escrevendo programas em Basic. A linguagem nem mesmo suportava recursão. É difícil agora me imaginar escrevendo programas sem usar recursão, mas eu não sentia falta disso naquele tempo. Eu pensava em Basic. E eu era um gênio no que fazia. Era o melhor nisso entre todos os que eu conhecia.
As cinco linguagens que Eric Raymond recomenda aos hackers caem em vários pontos do continuum de poder. Onde eles caem em relação uns aos outros é um tópico delicado. O que eu digo é que eu acho que o Lisp está no topo. E para suportar esta alegação vou te contar algo sobre as coisas que eu sinto falta ao olhar 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 do Lisp são únicas. E, quer você acredite ou não, o que elas fazem está relacionada aos parênteses. Os projetistas do Lisp não colocaram todos aqueles parênteses na linguagem apenas para serem diferentes. Para o programador Blub, um código em 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 as outras linguagens.
O código em Lisp é feito de objetos de dados Lisp. E não no sentido trivial de que o código fonte contém caracteres, e string é um dos tipos de dados suportados pela linguagem. O código em Lisp, após ser lido pelo analisador sintático, é feito de estruturas de dados que você pode percorrer.
Se você entende como os compiladores funcionam, o que realmente acontece não é tanto que o Lisp tem uma sintaxe estranha, mas que o Lisp não tem sintaxe. Você escreve programas nas árvores sintáticas que são geradas dentro do compilador. Mas tais árvores sintáticas são totalmente acessíveis por 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 diabos você iria querer fazer isso? Não com muita frequência, 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 dissesse: que tal isso? Mas se eu o fizesse, apenas pareceria tralha para alguém que não conhece Lisp; não há lugar aqui para explicar tudo o que você precisaria saber para entender o que isso significa. No meu livro “Ansi Common Lisp” eu tentei mostrar as coisas o mais rápido que eu conseguia, e ainda assim eu não explico as macros até a página 160.
Mas eu acho que posso dar um tipo de argumento que possa te convencer. O código fonte do editor do Viaweb era composto por cerca de 20-25% de macros. Macros são mais difíceis de escrever do que funções Lisp comuns, e é considerado falta de estilo usá-las quando não são necessárias. Portanto, cada macro naquele código está lá porque ela tem que estar lá. O que isso significa é que pelo menos 20-25% do código nesse programa faz coisas que você não conseguiria fazer facilmente em qualquer outra linguagem. Por mais cético que o programador Blub possa ser sobre minhas alegações sobre os misteriosos poderes de Lisp, isto deveria torná-lo curioso. Não estávamos escrevendo esse código para nossa própria diversão. Éramos uma pequena startup, programando o mais duro que conseguíamos para conseguir colocar barreiras técnicas entre nós e nossos concorrentes.
Uma pessoa desconfiada poderia começar a se perguntar se haveria alguma correlação aqui. Uma grande parte de nosso código fazia coisas que eram muito difíceis de se fazer em outras linguagens. O software resultante fazia coisas que o software de nossos concorrentes não podia fazer. Talvez havia algum tipo de conexão. Eu o encorajo a seguir essa linha. Pode haver mais coisa naquele velho homem manco em suas muletas do que parece.
— Aikido para Startups —
Mas eu não espero convencer ninguém (acima de 25 anos) a ir lá fora e aprender Lisp. O propósito deste artigo não é mudar a opinião de ninguém, mas para tranquilizar as pessoas já interessadas em usar Lisp – pessoas que sabem que Lisp é uma linguagem poderosa, mas que se preocupam porque ela não é amplamente utilizada. Em uma situação competitiva, isto é até uma vantagem. O poder do Lisp é multiplicado pelo fato de seus competidores não o conhecerem.
Se você não pensa em usar Lisp em uma startup, você não deveria se preocupar por ele não ser amplamente compreendido. Você deveria esperar que ele continue assim. E é provável que fique. Faz parte da natureza das linguagens de programação fazer as pessoas ficarem satisfeitas com qualquer uma que elas usem no momento. O hardware dos computadores muda tão mais rapidamente do que os hábitos pessoais que a prática de programação está geralmente de dez a doze anos atrás do processador. Em lugares como o MIT eles já escreviam programas em linguagens de alto nível no começo dos anos 60, mas muitas empresas continuaram a escrever código em linguagem de máquina até os anos 80. Eu 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 as chutaram para fora ao trocar para um conjunto de instruções RISC.
Normalmente, a tecnologia muda a passos rápidos. Mas linguagens de programação são diferentes: linguagens de programação não são apenas tecnologia, mas são aquilo que os programadores usam para pensar. Elas são meio tecnologia e meio religião [6]. E assim a linguagem mediana, isto é, qualquer linguagem que os programadores medianos usam, anda tão devagar quanto um iceberg. O recurso de coleta de lixo (garbage collection), introduzido pelo Lisp nos anos 60, é agora amplamente considerada uma coisa boa. Tipagem dinâmica, idem, está crescendo em popularidade. Closures léxicos, introduzidos pelo Lisp no começo dos anos 70, estão agora, pouco a pouco, em voga. Macros, introduzidos pelo Lisp na metade dos anos 60, ainda são uma incógnita.
Obviamente, a linguagem mediana tem um enorme impulso. Não estou propondo que você lute contra essa poderosa força. 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 companhia, isto pode não ser fácil. Você terá tempos difíceis convencendo seu chefe topetudo a deixá-lo fazer as coisas em Lisp, quando ele acabou de ler em um artigo que alguma outra linguagem está pronta, como o Ada estava a vinte anos atrás, para dominar o mundo. Mas se você trabalha para uma startup que ainda não tem chefes topetudos, você pode, como fizemos, virar o paradoxo Blub ao seu favor: você pode usar uma tecnologia que seus concorrentes, grudados sem movimento à sua linguagem mediana, nunca serão capazes de igualar.
Se um dia você for trabalhar para uma startup, aqui vai uma dica útil para avaliar os concorrentes. Leia seus anúncios de vaga. O site deles pode estar cheio de fotos ou prosa que podem dar alguma dica, mas os anúncios de vaga devem ser específicos quanto ao que eles querem, ou eles obterão os candidatos errados.
Durante os anos em que trabalhei no Viaweb eu lia um monte de descrições de vagas. Um novo concorrente parecia emergir para fora da toca a cada mês. A primeira coisa que eu fazia, após checar para ver se eles tinham uma demo online, era olhar seus anúncios de vaga. Após alguns anos disso eu podia dizer com quais empresas eu deveria me preocupar e com quais não. Quanto mais as descrições de vaga tinham um sabor de TI, menos perigosa era a empresa. Os tipos mais seguros eram aqueles que desejavam experiência em Oracle. Você nunca precisava se preocupar com esses. Você também estaria seguro se dissessem que queriam desenvolvedores C++ ou Java. Se desejassem programadores Perl ou Python, já seria mais alarmante – começava a soar como uma empresa onde a parte técnica, pelo menos, era tocada por hackers de verdade. Se eu tivesse visto um anúncio de emprego procurando por hackers Lisp, eu ficaria realmente preocupado.
—
Observações:
[1] O Viaweb, a princípio, era composto de duas partes: o editor, escrito em Lisp, que as pessoas usavam para construir seus sites, e o sistema de pedidos, escrito em C, que controlava os pedidos. A primeira versão era escrita 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 gerador de back-office escrito em maior parte em Perl.
Em Janeiro de 2003, a Yahoo lançou uma nova versão do editor escrito em C++ e Perl. É difícil dizer, no entanto, se o programa ainda é ou não escrito em Lisp, porque para traduzir esse programa para C++ eles literalmente tinham que escrever um interpretador Lisp: o código-fonte de todos os templates geradores de página são ainda, na medida do que eu sei, código em Lisp. (Veja Greenspun’s Tenth Rule)
[2] Robert Morris diz que eu não precisava manter as coisas em segredo, porque mesmo que nossos competidores soubessem que estávamos usando Lisp, eles não entenderiam por quê: “Se eles fossem tão espertos eles já estariam programando em Lisp.”
[3] Todas as linguagens são igualmente poderosas no sentido de serem Turing-equivalentes, mas não é este o sentido da palavra com que os programadores se preocupam. (Ninguém quer programar uma máquina de Turing). O tipo de poder com que os programadores se preocupam pode não ser formalmente definido, mas um modo de explicá-lo seria dizer que se refere aos recursos que você só poderia conseguir na linguagem menos poderosa ao escrever um interpretador para a linguagem mais poderosa com ela. Se a linguagem A tem um operador para remover espaços de strings e a linguagem B não tem, isto provavelmente não torna A mais poderosa, porque você provavelmente consegue escrever uma sub-rotina para fazer isso em B. Mas se A suporta, digamos, recursão, e B não, não é provável que haja algo que você possa fazer para corrigir escrevendo funções para uma biblioteca.
[4] Observação para os nerds: ou, possivelmente, uma rede que vai se estreitando até o topo; não é a forma que importa aqui, mas a ideia de que há ao menos uma ordem parcial.
[5] É um pouco equivocado tratar macros como um recurso separado. Na prática sua utilidade é bastante reforçada por outros recursos do Lisp como closures léxicos e parâmetros de descanso.
[6] Como resultado, comparações entre linguagens de programação acabam tomando, ou a forma de guerras religiosas, ou de livros-texto para graduação tão determinadamente neutros que são verdadeiros trabalhos de antropologia. Pessoas que valorizam sua paz, ou que querem estabilidade, evitam o tópico. Mas a questão é somente metade religião; há algo aí que é digno de estudo, especialmente se você deseja projetar novas linguagens.
Prof. Helio H. Monte-Alto 