Por que o Lisp não é mais difundido? [fechadas]

Estou começando a aprender o esquema pelos vídeos do SICP e gostaria de passar para o Common Lisp a seguir.

A linguagem parece muito interessante, e a maioria das pessoas que escreve seus livros defende que possui um poder expressivo inigualável. CL parece ter uma biblioteca padrão decente.

Por que o Lisp não é mais difundido? Se é realmente tão poderoso, as pessoas deveriam usá-lo todo, mas é quase impossível encontrar, por exemplo, anúncios de emprego do Lisp.

Espero que não sejam apenas parênteses, pois não são um grande problema depois de um tempo.

Expressividade nem sempre é uma característica positiva da linguagem em um ambiente corporativo. Java é extremamente popular em parte porque é fácil de aprender, fácil de escrever e fácil de ler. Programadores medíocres ainda podem ser muito produtivos em Java, mesmo que seu código seja prolixo e deselegante.

Além disso, é fácil abusar de idiomas expressivos. Um programador java especialista pode refatorar códigos mal escritos rapidamente. Quanto mais expressiva a linguagem, mais difícil é entender e refatorar o código horrível. As macros LISP são um bom exemplo. Macros são ferramentas poderosas nas mãos certas. Nas mãos erradas, eles podem resultar em códigos confusos e difíceis de depurar.

O LISP é uma escolha arriscada para a gerência sênior. Se tudo der errado, ninguém vai culpar o gerenciamento por escolher uma linguagem popular orientada a objetos, apoiada por uma grande corporação como Oracle ou Microsoft. É muito mais fácil contratar programadores com experiência em idiomas populares e fáceis de aprender.

Mesmo empresas progressistas que desejam usar uma linguagem mais poderosa geralmente não escolhem o LISP. Isso ocorre porque muitos dos idiomas mais novos tentam se comprometer emprestando recursos poderosos do LISP, mantendo o aprendizado fácil para as massas. Scala e Ruby seguem esse modelo. Os programadores ruins podem buscá-los rapidamente e continuar escrevendo o mesmo código medíocre que eles criaram em Java. Bons programadores podem tirar proveito dos recursos mais avançados para escrever um código bonito.

Parênteses não são o problema. Haskell é uma linguagem incrivelmente poderosa e expressiva com uma sintaxe semelhante a Python ou Ruby e não foi amplamente adotada pelos mesmos motivos que o LISP.

Apesar de tudo isso, eu espero ...

Clojure tem uma chance de se tornar popular. É executado na JVM, possui excelente interoperabilidade com Java e simplifica muito a programação simultânea. Tudo isso é importante para muitas empresas.

* Essa é minha perspectiva como programador profissional de JVM com experiência em Java, Clojure, JRuby e Scala.

Por que o Lisp não é mais difundido? Se é realmente tão poderoso, as pessoas deveriam usá-lo todo,

Se você acredita que os idiomas são escolhidos por seus méritos técnicos, você terá uma decepção esmagadora.

Tais decisões são tomadas com base em Strippers e bifes . A Microsoft pode pagar por eles. Oracle pode. A Sun gastou tanto dinheiro exagerando em Java que foi à falência. Duas vezes. Uma comunidade voluntária descentralizada, heterogênea e não pode competir com isso.

mas é quase impossível encontrar, digamos, anúncios de emprego do Lisp.

Curiosamente, as empresas Lisp dizem exatamente o oposto: elas constantemente têm vagas de emprego, mas não conseguem encontrar pessoas suficientes para preenchê-las. (O mesmo se aplica a Haskell, ML, O'Caml, Forth, Smalltalk, ...)

Não tenho experiência em trabalhar para uma empresa real, mas sei por que o LISP tem sido difícil de usar.

Antes de tudo, isso me lembra desta publicação no blog: http://steve-yegge.blogspot.com/2006/04/lisp-is-not-acceptable-lisp.html

O principal problema que tenho com o Lisp é a pergunta "qual Lisp". Normalmente trabalho no Linux como minha plataforma principal, mas as coisas que faço precisam ser compatíveis com o Windows. Isso significa que, quando estou avaliando uma tecnologia a ser usada, ela deve facilitar minha vida ao trabalhar em dois sistemas operacionais radicalmente diferentes. Não gosto desse requisito, mas usá-lo em um projeto real é um requisito. Agora vou usar idiomas que não têm um suporte muito bom no Windows para meus projetos paralelos pessoais, mas como nunca tenho a chance de escrever um grande projeto de software neles, não tenho a experiência necessária.

Agora, quando eu estava tentando aprender uma linguagem funcional, eu realmente queria aprender Common Lisp. Parecia a coisa certa a fazer. Comecei a ler o Practical Common Lisp como um ponto de partida, porque eu realmente não conhecia as funções internas e precisava de um projeto para trabalhar no Lisp. As expressões S eram bonitas e fáceis. Todos esses parênteses foram incrivelmente bonitos para mim, pois ficou claro como o dia exatamente o que estava acontecendo no código.

Então, eu tento escrever meu primeiro programa em Lisp fora do livro. Eu queria uma ferramenta de linha de comando que contasse linhas de código e removesse linhas triviais da contagem de códigos. Não é a ferramenta mais útil, mas divertida de fazer. Envolve acesso a arquivos, um pouco de análise e contagem. Eu havia implementado a mesma ferramenta em Python cerca de uma semana antes.

Eu preciso acessar argumentos de linha de comando. Então eu aprendo que não há uma maneira padrão de obter argumentos de linha de comando. Eles são todos os recursos não padrão. Não é de plataforma cruzada. A partir de então, a situação piora, pois a linguagem não possui muitas bibliotecas incorporadas. Acabei mudando para Haskell e não fui muito longe no Common Lisp (portanto, minhas queixas podem nem ser válidas).

Esse tipo de coisa fora do padrão sempre foi uma dor para mim no passado. O C ++ tem esse mesmo problema, mas com bibliotecas como o Boost, você pode contornar essas fraquezas.

Também não ajuda que a sintaxe Lisp para tudo que não seja expressões S seja um pouco feia.

IMO, é principalmente devido a:

• Suporte de biblioteca insuficiente. Claro, agora existe o Quicklisp, o que facilita a instalação de bibliotecas, mas não compensa o fato de elas ainda serem muito poucas, e algumas delas são mal documentadas ou mal mantidas. Comparado ao Python, há uma boa chance de que escrever um aplicativo Lisp não trivial (independentemente do dialeto em particular) provavelmente ainda envolva a reinvenção de pelo menos parte de uma roda ou duas.
• Falta de familiaridade com o modelo adotado pelas ferramentas de desenvolvimento. A maioria das pessoas que conheço se sente bastante intimidada por ter que usar o SLIME e o Emacs, o que é compreensível para as pessoas acostumadas ao Eclipse e ao Visual Studio. Acho que existem dois plug-ins do Eclipse, eu só tentei um deles há alguns anos e foi bastante complicado. Todo o ecossistema Lisp parece estar preso no meio do caminho entre os dias em que fazia parte de um sistema completo de execução de Lisp e o padrão moderno de oh-é-outro-idioma. Aprender o Lisp não se limita ao aprendizado de um novo idioma - você também precisa aprender uma maneira totalmente diferente de trabalhar e pensar, e embora isso seja bom se você estiver fazendo isso como um hobby, é questionável se vale a pena fazê-lo em um o negócio.

As coisas estão começando a parecer um pouco melhores, especialmente com Clojure por perto.

Eu aprendi o LISP há um bilhão de anos atrás na faculdade.

LISP, como FORTH, é ótimo para lógica. Mas a maioria da programação não é sobre lógica, trata-se de manipular dados de maneiras mecânicas chatas. Por exemplo, no momento, não há como justificar corretamente a saída numérica.

LISP é sobre funcionalidade aninhada, e as pessoas simplesmente não pensam assim. Eles pensam em termos de DO A, B, C, D e depois E. Não fazem A, que envolve fazer B e C, então D e E. Isso envolve um tipo de simultaneidade que é confusa. Exceto para tarefas predefinidas como "registrar uma declaração de imposto de renda", as pessoas não pensam simultaneamente, pensam sequencialmente. É por isso que as linguagens processuais são dominantes hoje.

Como resultado, o código produral como Java e C pode ser traduzido para o inglês facilmente. Código LISP não pode; nenhuma linguagem humana é estruturada dessa maneira.

Portanto, é ótimo para a solução de problemas, mas a solução de problemas não é muito importante na programação. Entrada de dados, validação, formatação de saída, todos os quais o LISP era terrivelmente fraco.

Eu acho que um problema com o Lisp ainda não mencionado é que, para um programador medíocre ou iniciante (como eu, eu admito livremente), pode ser difícil ver como você transforma o código Lisp em um grande programa. É fácil de escrever, mas difícil de arquitetar. Não acho que nenhum dos conceitos seja particularmente difícil, mas a mentalidade do bricolage é tão forte que muitas vezes me sinto perdido por onde começar.

Com uma linguagem OOP como Java ou C #, você pode usar o sistema de tipos para se aprimorar em direção a um modelo de trabalho e criar isso. Com Lisp (ou Lua, ou Javascript, para esse assunto), existe a noção de que você pode sair e fazer do jeito que quiser. Se você deseja POO, basta criar seu próprio sistema POO! Exceto fazer o seu próprio POO, ou aprender o de outra pessoa, é uma nova barreira no topo do idioma antes de você obter programas utilizáveis. Além disso, eu sempre sinto que o OOP no Lisp ou Lua não está realmente lá, como se eu pudesse simplesmente ignorá-lo, se quisesse, então qual é o objetivo?

Em resumo, acho que a programação no Lisp exige muita disciplina, e isso é muito difícil de encontrar. Linguagens fortemente tipadas e linguagens OOP oferecem um tipo de disciplina embutida, para que o programador possa concentrar suas reservas limitadas em projetos de conclusão, em vez de ajustar o idioma.

EDIT: Como uma analogia que acabou de me impressionar, é como se você precisasse trabalhar em madeira e duas pessoas oferecerem suas caixas de ferramentas. As ferramentas de uma pessoa são meio ruins, mas basicamente o trabalho seria feito com um pouco de esforço. A outra pessoa tem um grande compartimento de peças, mas é promissor que você possa combiná-las para criar as melhores ferramentas que você já usou, perfeitamente adequadas ao seu punho e da melhor qualidade. Você apenas precisa construí-los primeiro.

Há muito que me pergunto o mesmo, e fui até as conferências do Lisp para tentar entender o que é esse "lado sombrio" do Lisp que impede todos de adotá-lo.

Não encontrei uma resposta decente completa.

A ignorância pode ser o motivo da popularidade perdida, mas o que mais me intriga é que mesmo quem sabe com certeza o Lisp (por exemplo, o Google - Peter Norvig trabalha para eles) não o está usando.

A única explicação parcial que me é apresentada é que a maioria das grandes idéias do Lisp agora é comum, a única falta realmente importante (uma IMO extremamente importante) é a facilidade da metaprogramação.

Infelizmente, não vejo uma maneira fácil de absorver esse conceito para outros idiomas, porque a metaprogramação para ser agradável exige uma linguagem homoicônica e regular (estou falando de metaprogramação geral, não da versão simplificada do modelo). Em outras palavras, requer basicamente a abordagem Lisp da sintaxe: código é dados e dados são código. Escrever código em uma linguagem rica em sintaxe que manipula um AST é mais difícil porque você precisa conhecer dois idiomas: como escrever o código e como escrever o AST. Isso é especialmente difícil se o seu AST for fixo e também complexo e irregular com muitos tipos diferentes de nós. O Lisp possui um AST razoavelmente regular (e extensível!) E você já codifica normalmente escrevendo diretamente o AST.

A metaprogramação também é inerentemente mais difícil (e a meta-metaprogramação ainda mais e assim por diante) e a maioria dos programadores e gerentes aparentemente prefere apenas a resposta "ninguém precisaria disso".

Acho particularmente triste que linguagens "novas", como goacabaram usando metaprogramação baseada em texto, quando necessário (geradores externos de código gravando arquivos de texto) e "mágica" (ou seja, o compilador possa fazer o que os programadores não podem).

Eu acho que a solução para o problema da complexidade são ferramentas poderosas e educação. Aparentemente, a tendência é ferramentas bruscas e fingir que o problema não está presente.

Parece que mesmo o CL não possui um suporte de biblioteca muito bom. Pelo menos de acordo com as pessoas que mudaram de Lisp para Python:

http://www.redmountainsw.com/wordpress/archives/reddit-switches-from-lisp-to-python

Pessoalmente, conheço algum esquema e gosto de brincar com ele, mas não consigo imaginar fazer um projeto não trivial nesse idioma.

Ser poderoso não implica necessariamente uso generalizado. Você já ouviu falar do termo "Otimizar para o caso comum"? Infelizmente, como muitos disseram antes da mediocridade, se a garantia consistente é muito melhor para as pessoas do que grandes sucessos, com muitas falhas entre elas.

Este não é apenas o caso do lisp, mas de muitas tecnologias. Um bom toque nas ferramentas de processamento de texto Unix, awk, sed, perl, pode economizar dias de programação. Infelizmente, tenho visto pessoas que demoram dias realizando mal esse tipo de tarefa em outras ferramentas, o que poderia ter feito com essas ferramentas de maneira mais eficiente em minutos. Mas se alguém passa a vida inteira em eclipse, nunca chegará a apreciar o valor dessas coisas. Você pode escrever um programa enorme com legibilidade, facilidade de manutenção e tudo mais, mas qual é o objetivo de escrever um programa sem escrever, poderia ter feito o trabalho facilmente.

Outro aspecto ao projetar ferramentas hoje em dia é útil, pois elas são prontas para usá-las diretamente na solução de um problema. Você não pode criar algo muito genérico e, em seguida, dizer que irá proteger tudo isso por meio de bibliotecas e estruturas. É um pouco difícil resolver as coisas dessa maneira. Uma boa ferramenta combina bem com o ambiente e com os problemas ao seu redor. É por isso que ferramentas como php, perl e awk continuam a ser relevantes, apesar de intermináveis ​​trollagens e ataques, porque são úteis demais para jogá-las fora e geralmente fazem muito trabalho do que uma linguagem geral com muitas bibliotecas e estruturas ativadas.

Da mesma forma, você verá que linguagens como Java / Python são muito boas e eu diria o melhor para determinadas tarefas. O Python é especialmente bom e fácil de aprender e escrever. Além disso, esses idiomas são realmente bons se os pontos finais de dados forem padrão. Algum tipo de banco de dados ou XML ou dados desse tipo. Dados basicamente estruturados.

O Lisp estará lá por muito tempo, mas não necessariamente generalizado. Como você verá, cada ferramenta tem seu nicho. E eles resolvem certos problemas muito bem fora da caixa. Penso e tenho certeza que o lisp está se saindo bem em áreas e problemas para os quais foi projetado para resolver bem.

Para o desenvolvimento da Web com dialetos Lisp, pode haver um problema de galinha e ovo - porque poucas pessoas usam o Lisp, os hosts não o permitem ou não o facilitam, e porque não é fácil, poucas pessoas use-o. Mas, na verdade, colocar o Lisp em execução em um host pode ser mais fácil do que você imagina, mesmo que exija um pouco mais de trabalho do que o serviço PHP pronto para uso. Recentemente, recebi aplicativos do Scheme guile trabalhando aqui com apenas um pequeno esforço.

Na IMO, é principalmente uma questão de tempo ruim: o Lisp era velho (e quase por definição não é mais empolgante) muito antes de se tornar prático para a maioria das pessoas ou usos. Clojure (por exemplo) tem uma chance muito melhor. Seu sucesso dependerá muito mais de ser percebido como novo, elegante e legal do que qualquer coisa tão prática quanto a interoperação com Java (e tudo o mais que é executado na JVM).