Nos processos que é melhor usar Clojure? [fechadas]

https://stackoverflow.com/questions/1800896

05-07-2019
|

Pergunta

Eu desenvolver em Lisp e no esquema, mas eu estava lendo sobre Clojure e, em seguida, eu quero saber, em que casos é melhor usá-lo do que usar Lisp ou Scheme? Graças

Solução

"Clojure é executado na JVM" significa que você começa toda a cornucópia de Java bibliotecas disponíveis. Você pode fazer GUIs bonitas em Swing, usar o cliente Web do Apache ou código do servidor, conectar um Sudoku pronto-construída solver ... o que quiser.

Outra grande vantagem do Clojure é o seu apoio a simultaneidade muito polido, com cerca de 3 sabores diferentes. Se você tem, uma tarefa paralelizável de computação intensiva, Clojure pode tornar mais fácil. Bem, mais fácil.

Update: Outro argumento. Clojure é muito fortemente funcional, por isso é uma vantagem se você quiser forçar-se a pensar e escrever funcionalmente.

Outras dicas

Esta questão é impossível de responder. Você deve usar Clojure quase 100% do tempo ao longo do CL e Scheme, é o que eu diria. Mas isso não significa que você deve me ouvir. Outros podem fazer um bom argumento de que o oposto é o caso.

Para mim, os nomes de sintaxe e função em Clojure esteticamente agradável. Certas bibliotecas Java são de valor inestimável para o que eu faço para dados munging e programação web e outras coisas GUI. A programação funcional é desafiador e agradável. falhas do Clojure não são importantes e superados pelos seus benefícios nos meus olhos. Certas falhas intoleráveis ??em outros Lisps são "fixas" em Clojure, porque é novo e pode ignorar a compatibilidade retroativa. Ele tem uma nova abordagem e sem dúvida poderosa para a simultaneidade. A comunidade Clojure é vibrante e acolhedor e impressionantes. Tudo isso diz muito sobre mim eo que eu valorizo ??como faz sobre Clojure ou outros Lisps.

Existem bibliotecas para CL e esquema que não existem em Clojure ou Java. Há pessoas que não gostam de como Clojure usa muita sintaxe como [] e {} e quer usar parênteses em todos os lugares. Se você quiser OOP CLOS-estilo ou lotes de estruturas de dados mutáveis, outro Lisp é indiscutivelmente melhor. A JVM é pesado bagagem, talvez demasiado pesado e demasiado para algumas pessoas. Um monte de vazamentos de Java em Clojure (por projeto), o que ofende a sensibilidade de algumas pessoas. O STM e estruturas de dados imutáveis ??têm custos que fazem certas coisas (por exemplo, processamento de números) mais lento ou menos elegante. Clojure é novo e ainda áspera em determinadas áreas, ainda rapidamente mudando e evoluindo em outros. Clojure ainda tem que passar no teste do tempo, enquanto outros Lisps já tem. Clojure não é um "padrão" e algumas pessoas acham uma linguagem definida por uma implementação de ser desagradável. E assim por diante. Nenhuma dessas coisas importa para mim, mas eles podem para você.

Este é quase inteiramente subjetivo. Qual a linguagem que você deve usar depende do que você já sabe, o que você está disposto a aprender, quais bibliotecas você deseja usar, o que os editores e ferramentas que você está confortável, o que falhas idioma que você está disposto a viver e trabalhar ao redor e o que falhas você não pode tolerar, e que ajuda você a fazer o seu trabalho mais rápido, mais barato, mais divertida, ou conseguir o que seus objetivos são.

Basicamente, o que faz você se sentir quente e fuzzy. Saiba todos eles e, em seguida, fazer uma escolha informada com base em seus próprios gostos, e use a que você mais gosta. Eles são tudo de bom.

Quando? Tanto quanto possível. Por quê? Imutáveis ??Estruturas de Dados - eles são realmente tão bom. Há uma abundância de outras razões também.

Clojure deve ser usado quando

Você precisa trabalhar com código Java existente.
você trabalhar com pessoas que são alérgicas a lisp ( "patrão, eu gostaria de usar uma biblioteca java concorrência chamado clojue vs. gostaria de re-escrever este no esquema" [1]
será a programação para um sistema multi-processador.

Esquema seria melhor quando:

você precisa provar o seu código está correto. Clojures (chamá-java) dificulta, mas não impede isso.
você está trabalhando com pessoas que são alérgicas a java.
você está desenvolvendo uma plataforma sem (novo o suficiente) JVM

[1] sim este é um mau mau mau razão. tal é o mundo em que vivemos ...

ABCL (Armed Urso Common Lisp) e um vários de implementações Scheme (KAWA, SISC , ...) também estão em execução no JVM.

Geralmente Lisp Comum está disponível em diferentes 'sabores' - ABCL é um deles. Outros compilação para C, para código nativo, têm ambientes de desenvolvimento extensivo ou extensões especializadas como línguas de lógica ou bases de dados.

Clojure OTOH é um novo dialeto Lisp com ênfase em programação funcional preguiçoso e programação concorrente. Seu autor (Rich Hickey) é um desenvolvedor de software muito experiente (ele também escreveu Java e .net as interfaces para Lisp Comum) e fez um excelente trabalho com Clojure. Mesmo que haja algum hype em torno da linguagem, vale a pena verificar para fora -. É definitivamente um dos melhores dialetos Lisp desenvolvidos nos últimos anos (em comparação a dizer newLISP ou Arc)

Há um lote de razões, algumas mencionado acima. Minha opinião é a seguinte:

As bibliotecas pré-existentes. Esta é como um benefício. Eu só não posso elogiar este suficiente recurso.
A linguagem é mais adaptada à hardware disponível atualmente (Multi-core) e do desenvolvimento paradigmas em uso hoje. É muito mais fácil raciocinar sobre a concorrência. Os aspectos funcionais são mais agradáveis ??também. Você pode fazer programação funcional em Lisp, obviamente, mas é muito fácil de quebrar o paradigma sem saber, sem querer e sem querer.
Cross. Eu corro idênticos programas no Linux, Windows, eo Mac. Há de lote de Lisps nativas que funcionam em todas as plataformas, mas suporte para todos os recursos sobre tudo plataformas é um irregular pouco e você sempre tem que estar em alerta para as coisas que estão faltando em um plataforma ou o outro. Da mesma forma, o bibliotecas que você precisa nem sempre são consistentemente apoiado através plataformas. ABCL e alguns dos implementações Esquema JVM tem esse apoio consistente, bem como, mas eu ainda preferem Clojure por causa de ponto 2.
A natureza da língua comunidade. vamos enfrentá-lo, um monte de o tempo a comunidade Common Lisp é apenas desagradável para lidar com eles. Isso é não é o caso com Clojure em tudo. É fácil obter ajuda útil, sem a condescendência e mesquinhez que muitas vezes vem com uma resposta do comunidade Lisp comum. Como eu tenho Aprendi por mim mesmo várias vezes, não há nenhuma pergunta tão estúpida que você não vai ter um educado e prestativo resposta da comunidade Clojure.

Se eu tivesse que encontrar uma coisa que reclamar, seria suporte IDE. Talvez seja uma questão de aprender novos hábitos, mas ainda é mais fácil para mim lidar com a mecânica de desenvolvimento Java do Clojure. Eu tentei, e usar, Clojure Box, enclojure em NetBeas, La Clojure no IntelliJ IDEA, e anti-horário em Eclipse. Todos eles trabalham muito bem se você está trabalhando principalmente a partir do REPL, mas para a compilação e execução de arquivos de classe, todos eles ainda sinto um desajeitado pouco.

Um subconjunto de Clojure também pode compilar a javascript

Clojure é executado na JVM (e na CLR), então não há isso.

O projeto de Clojure está preocupado com acomodar vários estilos de programação concorrente com segurança, deliberadamente tornando difícil erroneamente escrever o perigoso, instável e código de simultaneidade tolerante muitas vezes quebrado em outras línguas. Se o seu domínio do problema envolve programação concorrente, conjunto de ferramentas integradas para gerenciar a simultaneidade de Clojure pode ser um ajuste melhor do que a aplicação específica ou bibliotecas menor denominador comum disponível em outros Lisps e esquemas.

Uma das grandes coisas sobre Clojure é o grande número de bibliotecas que você pode usar com ele. Você tem o poder de Java com a expressividade do Lisp, e que é uma combinação mauzão. Clojure é mais adequado para o desenvolvimento do mundo real, porque foi feito para o desenvolvimento do mundo real. Com Clojure, você tem bibliotecas impressionantes, características modernas impressionantes, e uma comunidade incrível de votos, like-minded pessoas.

Eu teria que dizer que Clojure é uma linguagem melhor, a toda a volta. Essa é uma afirmação altamente argumentativa de fazer, então eu gostaria de salientar aqui que esta é apenas a minha opinião honesta.

rochas Clojure.

Eu estou sempre tentando aprender novas línguas, por isso estou interessado em aprender Clojure. Mas, não são SBCL e algumas outras implementações Lisp comum muito, muito mais rápido do que Clojure? não que você precisa de muito mais do que 4 processadores (e uma tarefa razoavelmente paralelizável) para compensar a diferença de desempenho entre um aplicativo Clojure e até mesmo uma versão single-threaded SBCL do mesmo aplicativo?

Como regra geral, eu tendem a favorecer Clojure sobre outras línguas nos casos em que qualquer um destes caber a conta: (1). O modelo de domínio tendem a olhar muito recursiva e / ou gráfico-like. (2). Há a possibilidade de aproveitar um ambiente multi-JVM núcleo (por exemplo, elástico Beanstalk) (3). Há uma barreira difusa entre dados e código (pense calculadora RPN onde nós podem ser operadores ou números)

Estes podem soar um pouco artificial, mas um monte de meu trabalho envolve lidar com gráficos e árvores de informação, se ele está olhando para as redes sociais, algum tipo de otimização baseado em constrangido, ou a construção de relacionamento semântico. Acho que a minha outra língua favorita, Ruby, não pode me dar o mix de expressividade e poder de computação cru em comparação com Clojure, particularmente quando se trata de quantitativos, recursivo, do tipo concorrente resolução de problemas.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow