Author: Rudolf Winestock
The Lisp Curse
por Rudolf Winestock
Este ensaio é mais uma tentativa de conciliar o poder da linguagem de programação Lisp com a incapacidade da comunidade Lisp de reproduzir seus pré-AI Winter Realizações. Sem dúvida, Lisp tem sido uma influente fonte de idéias, mesmo durante o seu tempo de retiro. Esse fato, além do brilho das diferentes arquiteturas da Lisp Machine e do atual renascimento Lisp depois de mais de uma década na região selvagem, demonstram que os partidários Lisp devem ter alguma justificativa para sua presunção. No entanto, eles não conseguiram traduzir o poder da Lisp em um movimento com um impulso irresistível..
Neste ensaio, argumento que o poder expressivo de Lisp é realmente uma causa de sua falta de impulso.
O poder de Lisp é o seu pior inimigo.
Aqui está um experimento de pensamento para provar: tome duas linguagens de programação, nenhuma das quais é orientada a objetos. Sua missão, se você optar por aceitá-lo, é torná-los orientados a objetos, mantendo-os compatíveis com os idiomas originais, modulo alguns casos de borda. Inserir qualquer par de linguagens de programação neste experimento de pensamento mostrará que isso é mais fácil com alguns idiomas do que com outros. Esse é o objetivo do experimento de pensamento. Aqui está um exemplo trivial: Intercal e Pascal.
Agora, faça este experimento de pensamento interessante: imagine adicionar orientação de objeto às linguagens de programação C e Scheme. Making Scheme orientado a objetos é uma tarefa de lição de segundo ano. Por outro lado, a adição de orientação de objeto a C requer as costeletas de programação de Bjarne Stroustrup.
As consequências dessa divergência no talento e esforço necessários causam The Lisp Curse:
Lisp é tão poderoso que os problemas que são questões técnicas em outras linguagens de programação são questões sociais em Lisp.
Considere o caso de Scheme, novamente. Uma vez que fazer o Scheme orientado a objetos é tão fácil, muitos hackers Scheme o fizeram. Mais ao ponto, muitos individuos Scheme hackers fizeram isso. Na década de 1990, isso levou a uma verdadeira lista de estoque de armazém de pacotes orientados a objetos para o idioma. O Paradoxo da Escolha, alone, guaranteed that none of them would become standard. Now that some Scheme implementations have their own object orientation facilities, it's not so bad. Nevertheless, the fact that many of these packages were the work of lone individuals led to problems which Olin Shivers wrote about in documenting the Scheme Shell, scsh.
Os programas escritos por hackers individuais tendem a seguir o modelo de arranhão e coceira. Esses programas irão resolver o problema que o hacker, ele próprio, está tendo sem necessariamente lidar com partes relacionadas do problema, o que tornaria o programa mais útil para outros. Além disso, o programa certamente funcionará na configuração do próprio hacker solitário, mas pode não ser portátil para outras implementações do Esquema ou para a mesma implementação do Esquema em outras plataformas. A documentação pode estar faltando. Sendo essencialmente um projeto feito no tempo livre copioso do hacker, o programa é susceptível de sofrer se as responsabilidades da vida real interferirem com o hacker. Como observou Olin Shivers, isso significa que esses projetos de banda única tendem a resolver oitenta por cento do problema.
Ensaio do Dr. Mark Tarver, O Programador Bipolar Lisp, tem uma descrição adequada desse fenômeno. Ele escreve sobre esses hackers Liso-lobo Lisp e seus
...incapacidade de terminar as coisas corretamente. A frase "design descartável" é absolutamente feita para o BBM e vem da comunidade Lisp. Lisp permite que você simplesmente desenrolle as coisas com tanta facilidade, e é fácil dar isso por certo. Eu vi isso há 10 anos quando eu procurava uma GUI para o meu Lisp. Não havia problema, havia 9 ofertas diferentes. O problema era que nenhum dos 9 estava devidamente documentado e nenhum deles era livre de erros. Basicamente, cada pessoa havia implementado sua própria solução e funcionou para ele, então estava bem. Isto é um a BBM atitude; Isso funciona para mim e eu entendo. É também o produto de não precisar ou querer a ajuda de outra pessoa para fazer algo.
Mais uma vez, considere a linguagem de programação C nesse experimento de pensamento. Devido à dificuldade de tornar o objeto C orientado, apenas duas tentativas sérias para o problema fizeram qualquer tração: C ++ e Objective-C. Objective-C é mais popular no Macintosh, enquanto o C ++ administra em qualquer outro lugar. Isso significa que, para uma determinada plataforma, a questão de qual extensão orientada a objeto de C usar já foi respondida de forma definitiva. Isso significa que as facilidades orientadas a objetos para essas linguagens foram documentadas, que os ambientes de desenvolvimento integrados estão cientes deles, que as bibliotecas de códigos são compatíveis com elas, e assim por diante.
O ensaio do Dr. Mark Tarver sobre Lispers bipolar faz questão:
Agora, em contraste, a abordagem C / C ++ é bastante diferente. É muito difícil fazer qualquer coisa com pinças e colar que qualquer coisa significativa que você faça será uma conquista real. Você quer documentá-lo. Além disso, você é responsável por precisar de ajuda em qualquer projeto C de tamanho significativo; Então você é passível de ser social e trabalhar com os outros. Você precisa, apenas para chegar a algum lugar.
E tudo isso, do ponto de vista de um empregador, é atraente. Dez pessoas que se comunicam, documentam as coisas corretamente e trabalham em conjunto são preferíveis a uma BBM pirateando Lisp, que só pode ser substituído por outro BBM (se você consegue encontrar um) no caso improvável de que ele, em algum momento, desça sem ser reinicializado.
Portanto, aqueles que já conhecem C não perguntam "Qual sistema de objeto devo aprender?" Em vez disso, eles usam C ++ ou Objective-C, dependendo do que seus colegas estão usando, então, vá para "Como eu uso recurso orientado a objeto X?" Resposta: "Goog it" e devemos descobrir.
Os hackers reais, é claro, sabem há muito tempo que a programação orientada a objetos não é a panacéia que seus partidários reivindicaram. Os hackers reais passaram para conceitos mais avançados, como estruturas de dados imutáveis, tipo de inferência, avaliação preguiçosa, mônadas, setas, correspondência de padrões, programação baseada em restrições e assim por diante. Os hackers reais também sabem, por um tempo, que C e C ++ não são apropriados para a maioria dos programas que não precisam fazer arbitrários. No entanto, a Lisp Curse ainda segura
Alguns instigadores amantes de Lisp pesquisaram a atual safra de idiomas acadêmicos (Haskell, Ocaml, etc.) e achou-os quererem, dizendo que qualquer característica deles já está presente em Lisp ou pode ser facilmente implementada — e melhorou — com macros Lisp. Eles provavelmente estão certos.
Pity the Lisp hackers.
Dr. Mark Tarver - duas vezes citado, acima - escreveu um dialeto de Lisp chamado Qi. É menos de dez mil linhas de macros correndo sobre o Clisp. Ele implementa a maioria das características únicas de Haskell e OCaml. Em alguns aspectos, Qi os supera. Por exemplo, o mecanismo de inferência do tipo Qi é Turing complete. Em um mundo onde equipes de acadêmicos talentosos eram necessários para escrever Haskell, um homem, o Dr. Tarver escreveu Qi tudo por seu solitário.
Leia esse parágrafo, novamente, e extrapola.
Exercício para o leitor: Imagine que uma forte rivalidade se desenvolve entre Haskell e Common Lisp. O que acontece depois?
Resposta: A legenda de Lisp chuta. Cada segundo ou terceiro hacker Lisp grave irá rolar sua própria implementação de avaliação preguiçosa, pureza funcional, setas, correspondência de padrões, inferência de tipo e o resto. A maioria desses projetos serão operações de lobos solitários. Assim, terão oitenta por cento dos recursos que a maioria das pessoas precisa (um oitenta por cento diferente em cada caso). Eles serão mal documentados. Eles não serão portáteis em todos os sistemas Lisp. Alguns mostrarão grande promessa antes de serem abandonados, enquanto o mantenedor do projeto vai pagar suas contas. Vários irão vencer Haskell ao longo desta ou daquela dimensão (novamente, um diferente em cada caso), mas sua aceitação será dificultada por guerras de chamas no grupo comp.lang.lisp Usenet.
Endgame: Uma coleção de macros de hackers aleatórios de Lisp hacker vai se somar a uma implementação indocumentada, incipiente e bug-ridden de 80% de Haskell porque Lisp é mais poderoso do que Haskell.
A moral dessa história é essa efeitos secundários e terciários são importantes. A tecnologia não só afeta o que podemos fazer com respeito a questões tecnológicas, mas também afeta nosso comportamento social. Esse comportamento social pode reverter e afetar as questões tecnológicas originais sob consideração.
Lisp é um exemplar dolorosamente eloqüente desta lição. Lisp é tão poderoso, que incentiva a independência individual até o ponto de espírito sangrento. Esta independência produziu inovação incrivelmente boa, como nos dias Lisp Machine. Esta mesma independência também dificulta os esforços para reviver os sistemas "Lisp todo o caminho para baixo" dos antigos; Nenhum projeto "Lisp OS" reuniu massa crítica desde o desaparecimento de Symbolics e LMI
Um resultado desses efeitos secundários e terciários é que, mesmo que Lisp seja o idioma mais expressivo de sempre, de modo que é teoricamente impossível fazer uma linguagem mais expressiva, Lispers ainda terá coisas para aprender de outras linguagens de programação. Os garotos de Smalltalk ensinaram a todos - incluindo hackers Lisp - uma coisa ou duas sobre programação orientada a objetos. A linguagem de programação Clean e o Mozart/Oz combo pode ter algumas surpresas próprias.
A Curse Lisp não contradiz a máxima de Stanislav Datskovskiy: Os empregadores preferem que os trabalhadores sejam fungíveis e não sejam maximamente produtivos. Muito verdadeiro. Com grande dificuldade, qualquer pessoa aplana a venalidade da classe gerencial. No entanto, as últimas linhas de seu ensaio são problemáticas. Para saber:
Quanto ao mundo do "software livre", ele se opõe fortemente aos dogmas industriais na retórica, mas na verdade na prática. Nenhum conceito evitado pelos infernos do cubo farm já ganhou força real entre as massas amadoras.
Em uma nota de rodapé, ele oferece o Linux como um exemplo dessa falta de vontade de buscar diferentes idéias. Com certeza, ele tem um ponto em que se trata sistemas operacionais (o comentário mais alto, em particular, é irritantemente obtuso). Ele não tem um ponto em relação às linguagens de programação. Python e Ruby foram influenciados por Lisp. Muitos de seus fãs expressam respeito pela Lisp e alguns de seus interesses aumentaram o renascimento Lisp. Com alguma justiça, o JavaScript foi descrito como "Esquema na roupa de C" apesar de originar aqueles infernos do cubo.
No entanto, apesar desta influência, tanto nas empresas e mundos de código aberto, Lisp ainda tem apenas uma fração do compartilhamento de mente do desenvolvedor que a atual safra de linguagens de script avançadas atraiu. A mentalidade fechada dos MBA não pode ser a única explicação para isso. O Lisp Curse tem mais poder explicativo.
Os ambientes de desenvolvimento gratuito disponíveis para Lisp exemplificam ainda mais a Lisp Curse.
É embaraçoso apontar isso, mas deve ser feito. Esqueça a máquina Lisp; Nós nem sequer temos sistemas de desenvolvimento que combinam com o que média Smalltalk hacker dá por certo ("Sempre senti que Lisp é o idioma superior e Smalltalk é o ambiente superior." - Ramon Leon). A menos que paguem milhares de dólares, os hackers Lisp ainda estão presos com Emacs.
James Gosling, o autor do primeiro Emacs que correu no Unix, apontou corretamente que Emacs não mudou fundamentalmente em mais de vinte anos. Isso ocorre porque os mantenedores da Emacs ainda estão em camadas de código em cima de um projeto que foi resolvido quando o Emacs era um projeto de graduado-estudante no MIT AI Lab, ou seja, quando o desenvolvimento da Emacs ainda estava sendo indiretamente financiado pela dívida nacional. Um Slashdotter pode objetar que o Emacs já é bastante capaz e pode fazer qualquer coisa que qualquer outro ambiente de desenvolvimento possa fazer, apenas melhor. Essa que usaram Lisp Machines diz o contrário.
Então, por que os hackers Lisp não colocam os caras Smalltalk em seu lugar apropriado? Por que eles não fazem um sistema de desenvolvimento gratuito que lembra algumas das glórias perdidas do LispM, mesmo que não possam reproduzir outro LispM
A razão pela qual isso não acontece é por causa da Lisp Curse. Um grande número de hackers Lisp teria que cooperar um com o outro. Olhe mais de perto: grandes números do tipo de pessoas que se tornam hackers Lisp teria que cooperar um com o outro. E eles teriam que cooperar uns com os outros em um projeto que já não era um dado desde o início. E não haveria nenhuma disciplina externa, como um capitalista de risco ou outro mestre corporativo, para mantê-los.
Todo projeto tem fricção entre membros, desentendimentos, conflitos sobre estilo e filosofia. Esses problemas sociais são contrariados pelo fato de que nenhum projeto grande pode ser realizado de outra forma. "Devemos todos ficar juntos, ou todos ficaremos pendurados separadamente". Mas a expressividade de Lisp torna essa força compensatória muito mais fraca; Sempre pode começar o próprio projeto. Assim, hackers individuais decidem que o problema não vale a pena. Então, eles abandonam o projeto ou não se juntam ao projeto para começar. Esta é a Maldição de Lisp
Pode-se mesmo picar Emacs para obter algo que é bom o bastante. Assim, a Curse Lisp é o aliado de Pior é melhor.
O poder expressivo da Lisp tem inconvenientes. Não existe um almoço grátis.