Scelta di un linguaggio di programmazione funzionale [chiuso]

Di recente ho letto molte discussioni sui linguaggi di programmazione funzionale (quasi nell'ultimo anno, in effetti). Vorrei davvero sceglierne uno e impararlo a fondo.

Lo scorso semestre [corso], mi è stato presentato Scheme. Lo amavo. Ho adorato l'estrema semplicità della sintassi, il principio di omoiconicità , le macro ( igieniche e non igieniche), la n-arità delle procedure, ecc.

Il problema con Scheme è che è un linguaggio accademico. Non credo sia davvero utilizzato negli ambienti di produzione. Non credo neanche che sia particolarmente bello avere sul nostro curriculum. Quindi, ho cercato alternative. Ce ne sono molti e in qualche modo sembrano tutti avere un livello simile di popolarità.

Alcuni pensieri su alcuni altri linguaggi funzionali che ho ancora considerato:

• Clojure: Sembra fantastico perché può accedere al mondo Java, è orientato verso la scalabilità e la concorrenza, ma il mondo Java non è al limite in questo momento? Conosco già abbastanza bene Java, ma sarebbe saggio aggiungere ancora più energia a seconda della JVM?
• Haskell: Sembra una lingua molto apprezzata, ma da quello che ho letto, è anche più una lingua accademica.
• Lisp: È in circolazione da sempre. Sembra avere la maggior parte di ciò che mi piace di Scheme. Ha una grande comunità. Per quello che [penso di sapere], è probabilmente il linguaggio di programmazione funzionale più utilizzato nell'industria (?).
• F #: Non l'ho davvero preso in considerazione. Non sono un grande fan delle cose sulla SM. Non ho i soldi per pagare i loro software (potrei averli liberi dalle alleanze universitarie, ma sono più propenso ad andare con soluzioni guidate dalla comunità). Anche se ... immagino che sarebbe la migliore scelta orientata alla carriera.

Stasera, mi chino verso Lisp. Una settimana fa, era Haskell. Prima di allora era Clojure. L'anno scorso, stavo facendo un po 'di Schema per divertimento, non spingendolo per il motivo che conosci. Ora vorrei prendere sul serio (sull'apprendimento di uno, su come realizzare progetti reali con esso, su eventualmente eventualmente lavorare professionalmente con esso). Il mio problema è che avrei bisogno di impararli tutti in profondità prima di poterne scegliere uno.

Dal momento che vuoi un  linguaggio pratico :

Si noti che Haskell e Lisp sono utilizzati più degli altri nell'industria, sebbene vi sia stato un recente interesse per Clojure e F #.

Ma guarda cosa succede quando aggiungiamo Scheme al mix:

Hmm, non assomiglia molto a una lingua accademica ora, vero?

In realtà, il grafico sopra è probabilmente una bugia; la parola "schema" può comparire nella pubblicità desiderata in altri contesti oltre ai linguaggi di programmazione. :)

Quindi ecco un altro grafico che è probabilmente (un po ') più rappresentativo:

Se vuoi esplorare un dialetto davvero accattivante di Scheme, dai un'occhiata a Racket.

Se vuoi imparare la programmazione funzionale, potresti essere meglio servito per imparare prima Haskell, quindi usare qualunque lingua tu voglia. Puoi imparare la programmazione funzionale usando gli altri linguaggi, ma consentono comunque codice imperativo e orientato agli oggetti. Se scrivi un vero programma in Haskell, imparerai più velocemente la programmazione funzionale perché gli altri paradigmi non saranno disponibili su cui ripiegare.

Dopo aver scritto il tuo programma Haskell, avrai strumenti come monadi e tecniche come la codifica senza punti da portare nella lingua che preferisci. I concetti sembrano mappare particolarmente bene con Scheme.

In realtà, se tu fossi in grado di implementare un sistema ragionevolmente complesso in Scheme, saresti abbastanza desiderabile nelle aziende in cui probabilmente vorresti lavorare. All'inizio della mia carriera mi sono imbattuto in alcuni studenti che avevano svolto una buona dose di lavoro in Scheme e l'unica volta che era uno svantaggio era quando non erano in grado di spiegare il loro lavoro o in realtà non lo capivano abbastanza bene per implementare i dati di base strutture e algoritmi entro un ragionevole lasso di tempo. Lascio sempre ai candidati la risposta a tali domande nella loro lingua preferita; Mi sono imbattuto in alcune persone che hanno pensato di essere le migliori di Scheme che sono riuscite a lottare un po 'con cose che avrebbero dovuto essere facili, come aggiungere un elemento a un elenco collegato, il che mi ha sconcertato.

Ma se tu fossi in grado di "ottenere" Scheme abbastanza bene da scrivere anche un'app Web media, sarebbe un buon punto di vendita nella maggior parte delle società di software serie.

Se stavi intervistando in un negozio "blub" e gli sviluppatori pensassero che tu fossi strano a causa della tua competenza in Scheme o Haskell o F #, probabilmente non vorrai lavorare lì. Nella maggior parte dei casi, gli sviluppatori competenti ottengono la loro scelta di concerti, quindi non perdete "praticità" a meno che le uniche opzioni che potete immaginare nel vostro futuro siano aziendali. Lavora per essere competente, flessibile e abbattere i problemi.

Il college non riguarda la praticità. Si tratta di creare un ambiente sicuro per esplorare e imparare. Questo è, in effetti, utile, anche se finisci per scrivere software ordinario per il resto della tua carriera.

Detto questo, non vedo perché vorresti limitarti a una di quelle scelte così presto. Potresti facilmente avere un'idea di tutte e quattro le lingue in circa 4 settimane, quindi sceglierne una per concentrarti sulle maglie che meglio si adattano ai tuoi attuali capricci. Quindi torna a un'altra delle tue opzioni e prova a implementare qualcosa di simile. Passa a qualcosa di più complesso e considera di nuovo le tue opzioni. La sperimentazione è buona. A meno che tu non stia cercando di guadagnarti da vivere il mese prossimo, non devi ancora diventare uno specialista.

Ne ho scritti alcuni in Scheme, F #, Emacs Lisp e Common Lisp, e ho letto almeno un po 'di Haskell, almeno occasionalmente negli ultimi anni. Non posso dire di essere un esperto in nessuna di esse, ma ogni escursione in quelle lingue mi ha aiutato in tutte le altre lingue in cui lavoro professionalmente (C #, Java, Ruby e occasionalmente Boo, Perl e Python). La curiosità ti costruirà una carriera più duratura e appagante di ogni altra cosa.

Mi sono tuffato in Haskell per un po ', ma la conclusione a cui sono arrivato è stata che era un po' troppo accademico. È stato molto difficile fare qualcosa di pratico. In un linguaggio funzionale puro, cose come l'IO non si adattano perfettamente al modello, quindi devi affrontare le monadi. Decisi che avrei dovuto impiegare un tempo tremendo per essere a malapena competente, quindi sono passato.

Ho fatto Scheme al college. Potrebbe sembrare banale, ma tutte le parentesi sono davvero fonte di distrazione / fastidio. Difficile tornare a questo dopo aver usato lingue come Python.

Di recente ho esplorato F #. È funzionale, ma può anche essere imperativo e orientato agli oggetti quando vuoi. Questo, oltre ad essere in grado di utilizzare qualsiasi libreria .NET, rende possibile mescolare facilmente le tue parti funzionali pure con elementi più pratici come GUI, IO e rete. È possibile ottenere una versione autonoma di F #.

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=effc5bc4-c3df-4172-ad1c-bc62935861c5&displaylang=en

Ho valutato tutti i principali linguaggi funzionali uno o due anni fa, dal punto di vista della ricerca di un linguaggio di programmazione funzionale pratico e generale.

Ho finito per scegliere Clojure , che in seguito si è rivelata un'ottima scelta.

In linea di massima le ragioni principali sono state:

• Ecosistema di biblioteche : affinché una lingua sia utile, è necessario accedere a buone biblioteche. Essere su JVM significa avere un facile accesso alla più grande libreria open source ed ecosistema di strumenti, quindi scegliere un linguaggio JVM è stato un gioco da ragazzi da una prospettiva pragmatica. Anche Scala ha segnato molto qui.

• Macro-metaprogrammazione - Questo aspetto di Lisp mi ha sempre attirato, specialmente da quando ho anticipato di fare un bel po 'di generazione del codice. Ho molto apprezzato le argomentazioni fatte nel breve saggio di Paul Graham " Beating The Averages ". I vari Lisps hanno tutti segnato molto qui.

• Le prestazioni sono state "abbastanza buone" - Clojure è sempre compilato e ottiene i vantaggi dell'ottimizzatore JVM JIT e dell'eccellente GC. Come sempre, c'è un certo sovraccarico nell'uso di un linguaggio funzionale ma con Clojure era chiaro che puoi avvicinarti alla velocità di Java con un po 'di sforzo (Clojure supporta primitive Java e tipizzazione statica opzionale per quelle situazioni in cui ne hai bisogno). La mia stima è che Clojure sia il ballpark 2-5 volte più lento di quello che potresti ottenere con il codice Java o C ++ ottimizzato, il che è coerente con ciò che vedi nei benchmark errati e nel tempo mi aspetto che il divario si riduca ulteriormente. Inoltre, è abbastanza semplice scrivere codice particolarmente sensibile alle prestazioni in Java puro e chiamarlo da Clojure.

• Concorrenza : Clojure ha un approccio alla concorrenza abbastanza unico e potente, in particolare per la concorrenza altamente multi-core. È un po 'difficile da spiegare, ma questo video è eccellente per dare un assaggio dei principi. Penso che Clojure abbia attualmente la migliore risposta alla domanda delicata "come si dovrebbe gestire lo stato condiviso, concorrente e mutevole in un linguaggio di programmazione funzionale?".

• Progettazione del linguaggio - Clojure è IMO un design del linguaggio molto ben congegnato. Esempi sono avere letterali vettoriali [] e mappare {} oltre alle normali parentesi Lisp, l'uso di strutture di dati persistenti immutabili, supportare la pigrizia in tutta la lingua tramite l'astrazione della sequenza e fornire al programmatore una varietà di caratteristiche ortogonali per risolvere diversi problemi . Vedere l'arte dell'astrazione e semplificare .

• Comunità : sempre soggettiva, ma mi è piaciuto quello che ho visto nella comunità Clojure. L'atteggiamento è stato molto utile, costruttivo e pragmatico. C'è una forte enfasi sul "fare le cose", forse riflettendo il fatto che molte persone di Clojure (incluso lo stesso Rich Hickey) provengono da un background di costruzione di sistemi aziendali complessi. Il fatto che anche la comunità Clojure abbia forti legami con la comunità Java è stato importante nel convincermi che Clojure non correrebbe il rischio di rimanere bloccato in una "nicchia".

Se dovessi nominare un paio di piccoli aspetti negativi di Clojure, questi sarebbero:

• Digitazione dinamica : spesso questo è un vantaggio in termini di produttività, ma in media penso che lo scambierei con un controllo e un'inferenza più forti. Principalmente questo viene mitigato dall'avere una buona suite di test automatizzati, ma se ti piacciono i tuoi tipi validati staticamente dal compilatore, Haskell o Scala potrebbero essere più la tua tazza di tè.

• All'avanguardia - Clojure si sta sviluppando molto velocemente e c'è molta innovazione in corso - il rovescio della medaglia è che c'è molta sperimentazione, alcune librerie e strumenti sono ancora immaturi e ci sono cambiamenti occasionali tra le principali versioni di Clojure che tu bisogno di tenere d'occhio.

Nel complesso, comunque, non penso che tu possa sbagliare con Clojure se vuoi un linguaggio funzionale moderno eccellente e pragmatico!

Sembra che tu abbia fatto i compiti, quindi probabilmente lo sai già, ma Scheme è un dialetto di Lisp proprio come lo è Common Lisp. Se ti piacciono molte cose su Scheme, ma non ti piace la sua natura accademica, prova Common Lisp. Secondo l' indice TIOBE , è la tredicesima lingua più popolare rispetto allo schema nella posizione 26.

Poche delle lingue che hai menzionato appaiono nelle descrizioni dei lavori che ho visto di recente, anche se potrebbe essere solo il mio piccolo set di esempi. Personalmente imparerò Haskell, anche se non mi aspetto di usare quella lingua direttamente nel mio lavoro. I concetti di programmazione funzionale sono più preziosi per me per i progetti di programmi futuri rispetto alla commerciabilità diretta del linguaggio stesso.