Ho letto della programmazione funzionale. Recentemente ho utilizzato principalmente C # .net e mi piacerebbe conoscere un buon esempio del mondo reale in cui un linguaggio funzionale come Lisp o F # sarebbe uno strumento chiaramente superiore per ottenere un lavoro.
Trovo migliori i linguaggi funzionali perché tendono a richiedere pochissime cerimonie per la funzionalità che forniscono. Ad esempio .... prendiamo ogni numero in una lista di numeri interi aggiungendone uno al numero e poi sommandoli.
In Clojure:
(reduce + (map inc mylist))
In C # (stile funzionale):
result = mylist.Select(i => i + 1).Sum();
In C # (stile imperativo):
int sum = 0;
foreach (int i in mylist)
{
sum += (i + 1);
}
Diamo un'occhiata allo stile imperativo ... dobbiamo creare un accumulatore (somma), una variabile locale (i), e dobbiamo anche essere espliciti nel modo in cui enumeriamo il nostro ciclo. Ciò che prende una singola riga di codice, ed è estremamente leggibile in un linguaggio funzionale, si è gonfiato in 5 righe di C # e non è quasi leggibile.
Quindi, dopo aver studiato sia le lingue imperative che quelle funzionali per diversi anni, sono semplicemente arrivato alla conclusione che avrei preferito usare meno lavoro per ottenere di più. Dal passaggio a Clojure per tutti i miei progetti di hobby ho scoperto che posso improvvisamente ottenere molto di più con meno codice.
Quindi tornando alla tua domanda, non mi trovo mai a chiedere "perché dovrei usare un linguaggio funzionale?", ma invece, "perché non dovrei usare un linguaggio funzionale?". A volte è necessario pensare al problema in un modo diverso, ma trovo che il mio codice funzionale sia più conciso, elegante e leggibile del codice che sono costretto a scrivere in C #.
Per il contesto, codice in C # 8+ ore al giorno al lavoro e codice circa 1-2 ore in Clojure ogni notte.
La programmazione funzionale è comunemente usata negli accademici. Alcuni sostengono che è superiore nell'insegnamento. È anche utile per i massivi sistemi concorrenti.
La maggior parte di ciò che stai chiedendo può rispondere a diverse domande precedenti:
Usi Lisp: link
Utilizzo F #: link
Utilizzo Haskell: link
Utilizzo Erlang: link
Molti dei linguaggi funzionali sono stati progettati per l'utilizzo in sistemi high-uptime. Erlang, ad esempio, è la lingua dietro la logica della maggior parte dei nostri sistemi di telefonia cellulare (almeno quelli costruiti su nodi Ericsson). Ci si aspetta che questi sistemi forniscano livelli molto elevati di disponibilità (stiamo parlando di Nine Nines, tempo di funzionamento del 99,9999,999%, ovvero circa 30 millisecondi all'anno di tempi di fermo consentiti) e allo stesso tempo restano modulari e altamente scalabile. Lo fai con alcune delle funzionalità incorporate in molti linguaggi funzionali, come il codice hot-swappable (non è necessario ricompilare le DLL e riavviare il sistema, basta inserire il nuovo pacchetto e la prossima chiamata a quel pacchetto sarà con il nuovo codice ).
A parte questo, molte idee nel calcolo sono più facilmente espresse funzionalmente. La programmazione funzionale è intrinsecamente ricorsiva e altamente parallelizzabile, quindi le attività meglio progettate in questi modi si prestano bene ai linguaggi funzionali. La parallelizzazione in particolare sta diventando sempre più importante man mano che aumenta la potenza di una CPU aggiungendo unità di esecuzione al chip invece di aumentare gli orologi. L'elaborazione dei file e altre attività ETL sono definibili dal punto di vista funzionale e traggono enormi vantaggi dal lancio di più thread sul problema.
La programmazione funzionale è superiore su tutta la linea. Non ho trovato un caso in cui un linguaggio di programmazione funzionale, o uno stile più funzionale in un linguaggio imperativo, è una cattiva soluzione a un problema.
È semplicemente molto più facile ottenere risultati quando la lingua è più espressiva. Non si tratta di tollezza, anche se questo è un effetto collaterale, ma piuttosto di essere in grado di capire e ragionare su più del tuo programma contemporaneamente. In un linguaggio funzionale, non è sempre necessario scrivere una descrizione di come calcolare ciò che si desidera; è possibile scrivere una descrizione di ciò che effettivamente desidera.
L'uso di un linguaggio di programmazione funzionale ti incoraggia a pensare al tuo programma in termini di flusso di dati e calcolo, piuttosto che stato e mutazione. È molto più facile risolvere i problemi funzionalmente. E non risolve esattamente i problemi che i programmatori dovrebbero fare?
Leggi altre domande sui tag object-oriented lisp functional-programming f# imperative-programming