In quali casi è meglio usare Clojure? [chiuso]

https://stackoverflow.com/questions/1800896

05-07-2019
|

Domanda

Sviluppo in Lisp e in Scheme, ma stavo leggendo di Clojure e poi voglio sapere, in quali casi è meglio usarlo che usare Lisp o Scheme? Grazie

Soluzione

" Clojure funziona sulla JVM " significa che hai a disposizione l'intera cornucopia delle librerie Java. Puoi creare graziose GUI in Swing, utilizzare il client Web di Apache o il codice del server, collegare un solutore Sudoku già pronto ... qualunque cosa ti piaccia.

Un altro grande vantaggio di Clojure è il suo supporto di concorrenza molto raffinato, con circa 3 gusti diversi. Se hai un compito ad alta intensità di calcolo, parallelizzabile, Clojure può renderlo semplice. Bene, più facile.

Aggiornamento: un altro argomento. Clojure è piuttosto funzionale, quindi è un vantaggio se vuoi forzarti a pensare e scrivere in modo funzionale.

Altri suggerimenti

A questa domanda è impossibile rispondere. Dovresti usare Clojure quasi il 100% delle volte rispetto a CL e Scheme, è quello che direi. Ma ciò non significa che dovresti ascoltarmi. Altri possono argomentare bene che è vero il contrario.

Per me, la sintassi e i nomi delle funzioni in Clojure sono esteticamente gradevoli. Alcune librerie Java hanno un valore inestimabile per quello che faccio per il munging dei dati, la programmazione web e le cose della GUI. La programmazione funzionale è stimolante e divertente. I difetti di Clojure non sono importanti e sono compensati dai suoi benefici ai miei occhi. Alcuni difetti intollerabili in altre Lisps sono "riparati" in Clojure, perché è nuovo e può ignorare la retrocompatibilità. Ha un approccio romanzo e probabilmente potente alla concorrenza. La comunità Clojure è vibrante, accogliente e fantastica. Tutto ciò dice tanto su di me e su ciò che apprezzo quanto su Clojure o altre Lisps.

Esistono librerie per CL e Scheme che non esistono in Clojure o Java. Ci sono persone a cui non piace il modo in cui Clojure usa troppa sintassi come [] e {} e vogliono usare le parentesi ovunque. Se vuoi OOP in stile CLOS o molte strutture di dati mutabili, un altro Lisp è senza dubbio migliore. La JVM è pesante, forse troppo pesante e troppo bagaglio per alcune persone. Molta perdita di Java in Clojure (in base alla progettazione) e questo offende la sensibilità di alcune persone. L'STM e le strutture di dati immutabili hanno costi generali che rendono alcune cose (ad esempio il crunching dei numeri) più lente o meno eleganti. Il clojure è nuovo e ancora grezzo in alcune aree, in rapido cambiamento e in continua evoluzione in altre. Clojure deve ancora superare la prova del tempo, mentre altri Lisp lo hanno già fatto. Clojure non è uno "standard" e alcune persone trovano poco attraente un linguaggio definito da un'implementazione. E così via. Nessuna di queste cose è importante per me, ma possono per te.

Questo è quasi interamente soggettivo. La lingua che dovresti usare dipende da ciò che già conosci, da cosa sei disposto a imparare, da quali librerie vuoi usare, con quali editor e strumenti ti senti a tuo agio, con quali difetti linguistici sei disposto a convivere e a lavorare e quali difetti non puoi tollerare e cosa ti aiuta a portare a termine il tuo lavoro più velocemente, in modo più economico, più divertente o raggiungendo gli obiettivi prefissati.

Fondamentalmente, qualunque cosa ti faccia sentire caldo e confuso. Imparali tutti e poi fai una scelta informata in base ai tuoi gusti e usa quello che ti piace di più. Sono tutti buoni.

Quando? Per quanto possibile. Perché? Strutture di dati immutabili: sono davvero così buone. Ci sono molte anche altre ragioni .

Clojure dovrebbe essere usato quando

devi lavorare con il codice java esistente.
lavori con persone allergiche a lisp ("capo, vorrei utilizzare una libreria di concorrenza java chiamata clojue vs. Vorrei riscriverlo nello schema" [1]
programmerai per un sistema multiprocessore.

Lo schema sarebbe migliore quando:

devi dimostrare che il tuo codice è corretto. Clojures (chiama a Java) ostacola ma non impedisce questo.
stai lavorando con persone allergiche a java.
stai sviluppando per una piattaforma senza JVM (abbastanza nuova)

[1] sì, questa è una cattiva, cattiva, cattiva ragione. tale è il mondo in cui viviamo ...

ABCL (Armed Bear Common Lisp) e diverse implementazioni di Scheme (KAWA, SISC , ...) sono in esecuzione anche su JVM.

Lisp generalmente comune è disponibile in diversi "gusti" - ABCL è uno di questi. Altre compilazioni in C, in codice nativo, hanno ampi ambienti di sviluppo o estensioni specializzate come linguaggi logici o database.

Clojure OTOH è un nuovo dialetto Lisp con enfasi sulla programmazione funzionale pigra e sulla programmazione concorrente. Il suo autore (Rich Hickey) è uno sviluppatore di software di grande esperienza (ha anche scritto interfacce Java e .net per Common Lisp) e ha fatto un ottimo lavoro con Clojure. Anche se c'è un po 'di clamore nella lingua, vale la pena dare un'occhiata: è sicuramente uno dei migliori dialetti Lisp sviluppati negli ultimi anni (rispetto a dire Newlisp o Arc).

Ci sono molte ragioni, alcune sopra menzionate. La mia opinione è:

Le librerie preesistenti. Questo è tale un vantaggio. Non posso elogiare abbastanza questa funzione.
La lingua è più adattata a hardware attualmente disponibile (multi-core) e lo sviluppo paradigmi in uso oggi. È molto più facile ragionare sulla concorrenza. Anche gli aspetti funzionali sono più belli. Puoi fare una programmazione funzionale in Lisp, ovviamente, ma è molto facile rompere il paradigma inconsapevolmente, inconsapevolmente e involontariamente.
Cross platform. Corro identico programmi su Linux, Windows e Mac. Ci sono molti Lisp nativi che attraversano piattaforme, ma supporto per tutte le funzionalità su tutti le piattaforme sono un po 'imprevedibili e tu costantemente essere in allerta per cose che mancano in uno piattaforma o l'altro. Analogamente, la le librerie di cui hai bisogno non sono sempre costantemente supportato in tutto piattaforme. ABCL e alcuni dei Le implementazioni dello schema JVM hanno questo supporto costante anche, ma io preferisco ancora Clojure a causa di punto 2.
La natura della lingua Comunità. Ammettiamolo, un sacco di il tempo della comunità Common Lisp è solo brutto da affrontare. Questo è non è affatto il caso di Clojure. È facile ottenere un aiuto utile senza la condiscendenza e la meschinità che spesso viene fornito con una risposta dal Comunità Lisp comune. Come ho imparato per me stesso più volte, non c'è dubbio così stupido che non sarai educato e disponibile risposta della comunità Clojure.

Se dovessi trovare una cosa di cui lamentarmi, sarebbe il supporto IDE. Forse è una questione di apprendimento di nuove abitudini, ma per me è ancora più facile gestire la meccanica dello sviluppo Java che Clojure. Ho provato e utilizzo Clojure Box, incanto su NetBeas, La Clojure su Intellij IDEA e antiorario su Eclipse. Funzionano tutti bene se si lavora principalmente con REPL, ma per la compilazione e l'esecuzione di file di classe, si sentono ancora un po 'goffi.

Un sottoinsieme di Clojure può anche essere compilato in javascript

Clojure funziona su JVM (e su CLR), quindi esiste.

Il progetto di Clojure si preoccupa di accogliere in sicurezza diversi stili di programmazione concorrente, rendendo deliberatamente difficile scrivere erroneamente il codice pericoloso, traballante e spesso tollerante alla concorrenza in altre lingue. Se il tuo dominio problematico implica una programmazione concorrente, la gamma di strumenti integrati di Clojure per la gestione della concorrenza potrebbe adattarsi meglio delle librerie specifiche di implementazione o dal minimo comune disponibili in altri Lisps e schemi.

Una delle cose migliori di Clojure è la pletora di librerie che puoi usare con essa. Hai il potere di Java con l'espressività di Lisp, e questa è una combinazione tosta. Clojure è più adatto allo sviluppo del mondo reale, perché è stato creato per lo sviluppo del mondo reale. Con Clojure hai librerie fantastiche, fantastiche funzionalità moderne e un'incredibile comunità di persone utili e affini.

Dovrei dire che Clojure è una lingua migliore, tutto intorno. Questa è un'affermazione molto argomentativa da fare, quindi sottolineerò qui che questa è solo la mia opinione onesta.

Rocce di clojure.

Cerco sempre di imparare nuove lingue, quindi sono interessato a imparare Clojure. Ma SBCL e alcune altre implementazioni di Common Lisp non sono molto, molto più veloci di Clojure? Non avresti bisogno di più di 4 processori (e un'attività ragionevolmente parallelizzabile) per compensare la differenza di prestazioni tra un'app Clojure e persino una versione SBCL a thread singolo della stessa app?

Come regola generale, tendo a favorire Clojure rispetto ad altre lingue nei casi in cui uno di questi si adatta al conto: (1). Il modello di dominio tende ad apparire molto ricorsivo e / o grafico. (2). C'è un'opportunità per sfruttare un ambiente JVM multi-core (ad es. Elastic Beanstalk) (3). C'è una barriera fuzzy tra dati e codice (pensa al calcolatore RPN in cui i nodi possono essere operatori o numeri)

Questi potrebbero sembrare un po 'forzati, ma gran parte del mio lavoro prevede la gestione di grafici e alberi di informazioni, sia che si tratti di social network, una sorta di ottimizzazione basata su vincoli o di costruzione di relazioni semantiche. Trovo che il mio altro linguaggio preferito, Ruby, non possa darmi il mix di espressività e potenza di calcolo pura rispetto a Clojure, in particolare quando si tratta di risolvere problemi quantitativi, ricorsivi e di tipo concorrente.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow