Scelta di un linguaggio di programmazione funzionale [chiuso]

Se vuoi imparare la programmazione funzionale, potresti essere meglio informato prima di usare Haskell, quindi utilizzare la lingua che preferisci. È possibile apprendere la programmazione funzionale utilizzando gli altri linguaggi, ma consentono comunque il codice imperativo e orientato agli oggetti. Se scrivi un vero programma in Haskell, imparerai la programmazione funzionale più velocemente perché gli altri paradigmi non saranno disponibili per il ripiegamento.

Dopo aver scritto il tuo programma Haskell, avrai a disposizione strumenti come monadi e tecniche come la codifica point-free per portarti nella lingua che preferisci. I concetti sembrano mappare particolarmente bene Scheme.

In realtà, se sei in grado di implementare un sistema ragionevolmente complesso in Scheme, saresti piuttosto desiderabile nelle aziende in cui vorresti probabilmente lavorare. All'inizio della mia carriera mi sono imbattuto in alcuni studenti che avevano svolto una discreta quantità di lavoro in Scheme, e l'unica volta in cui si trattava di uno svantaggio era quando non erano in grado di spiegare il loro lavoro o non lo capivano abbastanza bene da implementare i dati di base strutture e algoritmi entro un ragionevole lasso di tempo. Lascio sempre che i candidati rispondano a tali domande nella loro lingua preferita; Mi sono imbattuto in alcune persone che pensavano che fossero le migliori a Scheme, che è riuscito a lottare un bel po 'con cose che dovrebbero essere facili, come aggiungere un elemento a una lista collegata, il che mi ha confuso.

Ma se si riuscisse a "ottenere" Scheme abbastanza bene da scrivere anche un'app web media, sarebbe un buon punto di vendita per la maggior parte delle società di software più serie.

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

Il college non riguarda la praticità. Si tratta di creare un ambiente sicuro da 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é tu voglia limitare solo 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 meglio sui tuoi attuali capricci. Quindi torna ad un'altra delle tue opzioni e prova ad 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 è ancora necessario 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 nessuno di essi, ma ogni escursione in quelle lingue mi ha avvantaggiato in tutte le altre lingue in cui lavoro professionalmente (C #, Java, Ruby, e occasionalmente Boo, Perl e Python). Curiosity ti costruirà una carriera più duratura e soddisfacente di ogni altra cosa.

Mi sono immerso in Haskell per un po ', ma la conclusione cui sono giunto è stata un po' troppo accademica. È stato molto difficile fare qualcosa di pratico. In un linguaggio puramente funzionale, cose come IO non si adattano perfettamente al modello, quindi devi occuparti delle monadi. Ho deciso che avrei dovuto dedicare una quantità enorme di tempo per essere appena competente, quindi sono andato avanti.

Ho fatto Scheme al college. Potrebbe sembrare banale, ma tutti i parenti sono davvero fastidiosi / fastidiosi. Difficile tornare a quello dopo aver usato lingue come Python.

Recentemente ho esplorato F #. È funzionale, ma può anche essere imperativo e orientato agli oggetti quando lo si desidera. Questo, insieme alla possibilità di utilizzare qualsiasi libreria .NET, rende possibile combinare facilmente le tue parti funzionali pure con cose più pratiche come GUI, IO e networking. Puoi ottenere una versione standalone di F #.

link

Ho valutato tutti i principali linguaggi funzionali un anno o due indietro, dal punto di vista di un linguaggio di programmazione funzionale pratico e generico.

Alla fine ho scelto Clojure , che si è successivamente dimostrato una scelta eccellente.

In generale, i motivi principali erano:

• Ecosistema di libreria : per un linguaggio utile, è necessario accedere a buone librerie. Essere sulla JVM significa avere un facile accesso alla più grande libreria open source e all'ecosistema di strumenti, quindi andare per un linguaggio JVM è stato un gioco da ragazzi da una prospettiva pragmatica. Anche Scala ha ottenuto un punteggio elevato qui.

• Macro-metaprogramming - Questo aspetto di Lisp mi ha sempre affascinato, soprattutto perché prevedevo di fare un bel po 'di generazione di codice. Ho molto apprezzato gli argomenti del saggio breve di Paul Graham " Battere le medie ". I vari Lisps hanno ottenuto un punteggio elevato qui.

• Le prestazioni erano "abbastanza buone" - Clojure è sempre compilato e ottiene i vantaggi dell'ottimizzatore JIT JIT e dell'eccellente GC. Come sempre, c'è un sovraccarico nell'uso di un linguaggio funzionale, ma con Clojure è stato chiaro che ognuno può avvicinarsi alla velocità di Java con un po 'di impegno (Clojure supporta le primitive Java e la digitazione statica facoltativa per quelle situazioni in cui è necessario). La mia stima è che Clojure è ballpark 2-5x più lento di quello che potresti ottenere con codice Java o C ++ ottimizzato, che è coerente con quello che vedi nel benchmark non elaborati , e nel tempo mi aspetto che il divario si riduca ulteriormente. Inoltre, è abbastanza semplice scrivere solo un codice particolarmente sensibile alle prestazioni in puro Java e chiamarlo da Clojure.

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

• Design della lingua - Clojure è IMO un design linguistico molto ben congegnato. Gli esempi includono i simboli vettoriali [] e map {} oltre alle parentesi Lisp regolari, l'uso di strutture di dati persistenti immutabili, il supporto della pigrizia attraverso la lingua tramite l'astrazione di sequenza e la fornitura al programmatore di una varietà di funzioni ortogonali per risolvere diversi problemi . Vedi l'arte dell'astrazione e semplice reso facile .

• Comunità - sempre soggettivo, ma mi è piaciuto ciò che ho visto nella comunità di Clojure. L'atteggiamento è stato molto utile, costruttivo e pragmatico. C'è una strong enfasi sul "fare le cose", forse riflettendo il fatto che molte persone Clojure (incluso lo stesso Rich Hickey) provengono da uno scenario di costruzione di sistemi aziendali complessi. Anche il fatto che la comunità di Clojure abbia forti legami con la comunità Java è stato importante per convincermi che Clojure non avrebbe corso il rischio di rimanere bloccato in una "nicchia".

Se dovessi nominare un paio di aspetti secondari minori di Clojure, questi sarebbero:

• Dattilografia dinamica - spesso questo è un vantaggio in termini di produttività, ma in media penso che lo scambierei per un controllo e un'inferenza più forti. Principalmente questo viene attenuato dall'avere una buona suite di test automatizzata, ma se ti piacciono i tuoi tipi convalidati staticamente dal compilatore, allora 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 ci sono molti esperimenti, alcune librerie e strumenti sono ancora immaturi , e ci sono occasionali rotture di cambiamenti tra le versioni principali di Clojure che devi tenere d'occhio.

Nel complesso però, 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 Common Lisp. Se ti piacciono molte cose su Scheme, ma non ti piace la sua natura accademica, prova Common Lisp. Secondo l' indice TIOBE , è il 13 ° schema più popolare della lingua in posizione 26.

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