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

Expressividade nem sempre é um traço de linguagem positivo 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 especializado pode refatorar código mal escrito rapidamente. Quanto mais expressiva for a linguagem, mais difícil será o entendimento e a refatoração do código horrível. Macros LISP são um bom exemplo. As macros são ferramentas poderosas nas mãos certas. Nas mãos erradas, podem resultar confusos e difíceis de depurar o código.

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

Mesmo empresas progressistas dispostas a usar uma linguagem mais poderosa geralmente não escolhem o LISP. Isso ocorre porque muitas das novas linguagens tentam e se comprometem, emprestando recursos poderosos do LISP, enquanto ficam fáceis de aprender para as massas. Scala e Ruby seguem esse modelo. Bad programadores podem pegá-los rapidamente e continuar escrevendo o mesmo código medíocre que eles fizeram em Java. Bons programadores podem aproveitar os recursos mais avançados para escrever um código bonito.

Os parênteses não são o problema. O Haskell é uma linguagem incrivelmente poderosa e expressiva com uma sintaxe semelhante a Python ou Ruby e não foi amplamente adotada por muitas das mesmas razões que o LISP. / p>

Apesar de tudo isso, espero ...

O Clojure tem uma chance de se tornar popular. Ele é executado na JVM, tem ótima interoperabilidade com o Java e torna a programação simultânea muito mais simples. Estes são todos coisas importantes para muitas empresas.

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

Why is not Lisp more widespread? If it is really that powerful, people should be using it all over,

Se você acredita que os idiomas são escolhidos por seus méritos técnicos, você está prestes a ter um desapontamento alucinante.

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

but instead it is nearly impossible to find, say, Lisp job advertisements.

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

Em primeiro lugar, isso me faz lembrar desta postagem do blog: link

O principal problema que tenho com Lisp é a questão "qual Lisp". Eu costumo trabalhar no Linux como minha plataforma principal, mas as coisas que eu 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. Eu não gosto deste requisito, mas para usá-lo em um projeto real que é um requisito. Agora vou usar linguagens que não têm suporte muito bom no Windows para meus projetos pessoais, mas como eu nunca tenho a chance de escrever um grande projeto de software nelas, 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. Eu comecei a ler o Practical Common Lisp como um ponto de partida, pois eu realmente não conhecia as funções internas e precisava de um projeto para trabalhar em Lisp. As expressões S eram bonitas e fáceis. Todos esses parênteses eram inacreditavelmente lindos para mim, pois ficava claro como 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 o acesso a arquivos, um pouco de análise e contagem. Eu tinha implementado a mesma ferramenta no Python cerca de uma semana antes.

Eu preciso acessar os argumentos da 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 recursos não-padrão. Não é de plataforma cruzada em tudo. Na maioria das vezes, fica pior a partir daí, pois a linguagem não possui muitas bibliotecas embutidas nela. Acabei mudando para o Haskell e não fui muito longe no Common Lisp (então minhas queixas podem não ser válidas).

Esse tipo de coisa não-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 do Lisp para tudo que não seja a expressão S seja um pouco feia.

IMO, é principalmente devido a:

• Suporte inadequado à biblioteca. Claro, há o Quicklisp agora, o que facilita a instalação de bibliotecas, mas não compensa que ainda sejam poucas, e algumas são pouco documentadas ou não muito bem mantidas. Comparado ao Python, há uma boa chance de que escrever aplicativos Lisp não-triviais (independentemente do dialeto em particular) provavelmente envolverá reinventar pelo menos parte de uma ou duas rodas.
• Falta de familiaridade com o modelo adotado pelas ferramentas de desenvolvimento. A maioria das pessoas que conheço é bastante intimidada por ter que usar SLIME e Emacs, o que é compreensível para pessoas acostumadas ao Eclipse e ao Visual Studio. Existem dois plugins do Eclipse que eu acho, eu só tentei um deles há alguns anos e foi bastante buggy. Todo o ecossistema Lisp parece estar preso no meio do caminho entre os dias em que era parte de um sistema de execução Lisp completo e o padrão moderno de "oh-it-another-language". Aprender Lisp não se limita a aprender uma nova língua - você também precisa aprender uma maneira completamente diferente de trabalhar e pensar, e enquanto isso é bom se você está fazendo isso como um hobby, é questionável se vale a pena fazê-lo em um negócios.

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

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

LISP, como FORTH, é ótimo para lógica. Mas a maior parte 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 a saída numérica.

O LISP é sobre funcionalidade aninhada, e as pessoas simplesmente não pensam assim. Eles pensam em termos de DO A, B, C, D e, em seguida, E. Não A, que envolve fazer B e C, depois D e E. Isso envolve um tipo de concorrência que é confusa. Exceto para tarefas predefinidas como "arquivar um retorno de imposto de renda", as pessoas não pensam simultaneamente, pensam em seqüência. É por isso que as linguagens procedurais são dominantes hoje em dia.

Como resultado, os códigos de produção Java e C podem ser traduzidos para o inglês facilmente. Código LISP não pode; nenhuma linguagem humana é estruturada dessa forma.

Por isso, é ótimo para resolver problemas, mas a resolução de problemas não é muito importante na programação. Entrada de dados, validação, formatação de saída, tudo em que o LISP era terrivelmente fraco.

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

Com uma linguagem OOP, como Java ou C #, você pode usar o sistema de tipos para impulsionar a si mesmo em direção a um modelo funcional e construí-lo. Com Lisp (ou Lua, ou Javascript, para esse assunto) há essa noção de que você pode sair e fazer do jeito que quiser. Se você quiser OOP, basta criar seu próprio sistema OOP! Exceto fazer sua própria OOP, ou aprender outra pessoa, é uma nova barreira em cima do idioma antes de você obter programas utilizáveis. Além disso, eu sempre sinto que a OOP em Lisp ou Lua não está realmente lá, como eu poderia simplesmente ignorar se eu realmente quisesse, então qual é o ponto?

EDITAR: Como uma analogia que me impressionou, é como se você precisasse fazer um trabalho em madeira e duas pessoas lhe oferecessem suas caixas de ferramentas. As ferramentas de uma pessoa são meio ruins, mas basicamente faziam o trabalho com um pouco de esforço. A outra pessoa tem um grande monte de peças, mas é promissor que você pode combinar essas partes para fazer as melhores ferramentas que você já usou, perfeitamente adequadas para sua aderência e da melhor qualidade. Você só precisa construí-los primeiro.

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

link

Pessoalmente, conheço alguns Scheme 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 em uso generalizado. Você já ouviu falar do termo 'Otimizar para o caso comum'? Infelizmente, como muitos já disseram antes, a mediocridade, se assegurada consistentemente, é muito melhor para as pessoas do que grandes sucessos, com muitos fracassos entre eles.

Este não é apenas o caso do lisp, mas com muitas tecnologias. Um bom toque sobre as ferramentas de processamento de texto Unix, awk, sed, perl pode poupar dias de programação. Infelizmente eu tenho visto pessoas levarem dias fazer essas tarefas em outras ferramentas mal o que poderia ter feito com essas ferramentas de forma mais eficiente em minutos. Mas se alguém passa toda a sua vida em eclipse, nunca chegará a apreciar o valor dessas coisas. Você pode escrever um programa enorme com legibilidade e facilidade de manutenção e tudo mais, mas qual é o objetivo de escrever um programa desse tipo sem escrevê-lo poderia facilmente ter feito o trabalho.

Outro aspecto ao projetar ferramentas atualmente é que eles são úteis para usá-los diretamente para resolver um problema. Você não pode construir algo muito genérico e, em seguida, diz que você vai cobrir tudo isso através de bibliotecas e frameworks. É um pouco difícil resolver as coisas dessa maneira. Uma boa ferramenta funciona bem com o ambiente e o problema em torno dela. É por isso que ferramentas como php, perl e awk continuam a ser relevantes, apesar de infindáveis trolling e bashing, porque são muito úteis para serem jogadas fora e muitas vezes fazem muito trabalho do que uma linguagem geral com muitas bibliotecas e frameworks.

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

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

Eu tenho pensado o mesmo por muito tempo, e eu até fui a conferências Lisp para tentar entender o que é esse "lado negro" do Lisp que impede que todos o adotem.

Não encontrei uma resposta decente completa.

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

A única explicação parcial que obtenho é que a maioria das grandes ideias de Lisp agora são comuns, a única realmente importante em falta (uma IMO extremamente importante) é a facilidade de metaprogramação.

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

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

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

IMO, é principalmente uma questão de tempo ruim: Lisp era velho (e quase por definição não é mais excitante) 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 o Java (e tudo mais que roda na JVM).

Para desenvolvimento web com dialetos Lisp, pode haver um problema de galinha e ovo - porque poucas pessoas usam Lisp, os hosts não permitem ou não facilitam, e porque não é fácil poucas pessoas o usam. Mas, na verdade, fazer o Lisp rodando em um host pode ser mais fácil do que você imagina, mesmo que isso exija um pouco mais de trabalho do que o serviço PHP pronto para uso. Recentemente eu obtive o guile Aplicativos de esquemas trabalhando aqui com um pouco de esforço.