Direi che uno dei motivi per cui la programmazione funzionale non è più prevalente è la mancanza di basi di conoscenza. La mia esperienza è che le aziende sono molto avverse al rischio in termini di implementazione di tecnologie che non sono main stream e preferiscono investire in framework sperimentati e veri (java, c ++, c #). È solo quando è necessario un business (come in Ericsson) che vengano considerati nuovi paradigmi. Ma anche nel caso di Ericsson ho sentito che la direzione richiedeva che c ++ venisse usato e Joe Armstrong fu costretto a codificare le chiamate di erlang in c ++ !! Questo dovrebbe mostrare come le corporazioni riluttanti devono implementare nuove tecnologie!

Perché il più grande problema nello sviluppo del software in questi giorni è la capacità di gestire la complessità. Questo non è l'obiettivo della maggior parte dei linguaggi di programmazione funzionali. In quanto tali, le lingue che fanno fanno di una priorità (vale a dire le lingue OOP più popolari) tendono a rubare solo alcune delle caratteristiche più interessanti che escono dai linguaggi funzionali più accademici e quindi rimangono in cima.

La programmazione funzionale sta sicuramente iniziando a prendere piede - lentamente ma sicuramente.

Ad esempio, l'avvio che sto creando utilizza un linguaggio funzionale (Clojure) come linguaggio di sviluppo principale per i seguenti motivi:

• Produttività - l'apprendimento di FP è difficile, ma una volta che ci si apprende è molto difficile da battere in termini di potenza ed espressività. Probabilmente sto scrivendo circa 1/10 del numero di linee per implementare qualsiasi dato elemento di funzionalità rispetto a quello che avrei avuto in C # o in Java

• Affidabilità : le funzioni pure sono molto più facili da ragionare e test rispetto agli oggetti stateful. Quindi puoi scrivere test migliori e convalidare la correttezza del tuo codice molto più facilmente.

• Concurrency - i linguaggi funzionali enfatizzano l'immutabilità, che offre enormi vantaggi per le applicazioni concorrenti rispetto alla necessità di eseguire efficacemente su più core. E che piaccia o no, girare su più core è il futuro. Vedi link per una spiegazione brillante del perché è così importante

• Composibilità / modularità - i linguaggi funzionali sembrano prestarsi a collegare i componenti insieme più facilmente rispetto ai sistemi OO complessi. Non ho ancora capito tutte le ragioni per questo, ma parte di esso deriva dal fatto che non hai tutta la "complessità incidentale" che i modelli OO trascinano con loro. Il discorso su Radical Simplicity di Stuart Halloway esplora queste idee in modo molto più approfondito.

EDIT : in risposta al commento di Despertar, un esempio della "complessità accidentale" dei sistemi OOP che limita la modularità sono i problemi con la clonazione profonda rispetto alla clonazione superficiale: non è possibile comporre oggetti insieme e passarli in giro come strutture composite senza un'analisi molto attenta della semantica della clonazione e della mutazione. In casi piccoli questo è gestibile, ma in sistemi complessi diventa rapidamente un problema significativo. Questo problema non esisterà in primo luogo se ti affidi a strutture dati funzionali pure.

Mancanza dell'app killer

Ehi, questo qui sembra fresco. (dig dig dig dig

Penso che la maggior parte dei linguaggi di programmazione prosperasse avendo una "killer app" - qualcosa di irresistibile che era esclusivo del linguaggio (o visto in quel modo). Questo non vuol dire che tutta l'adozione fosse quella , ma che ha portato la lingua ad un'accettazione più ampia.

Ecco la mia visione non troppo accurata di quale nicchia abbia guidato l'adozione di alcune delle lingue che abbiamo oggi:

• C: funziona ovunque (era la fine degli anni '70 e '80)
• C ++: framework GUI (primi anni '90)
• Java: applet e servlet (alla fine degli anni '90)
• Obiettivo-C: app iOS (prima di quelle OS X)
• Ruby: Rails
• C #: ASP.NET, WinForms
• PHP: Wordpress, ecc.
• Javascript: AJAX, in particolare tramite i framework
• lua: script di gioco, in particolare WoW

A parte questo, molte lingue proprietarie sono arrivate attraverso potenti organizzazioni di vendita (Oracle e, in misura minore, le lingue di Microsoft), creando efficacemente la propria nicchia.

Una nota molto importante su questa lista: la "nicchia" della lingua, come indicato dall'app killer, diventa sempre più specifica con il passare dei decenni. Nota l'ultimo della lista: Game scripting , in particolare. Sta diventando sempre più difficile per le lingue attirare l'attenzione a causa dell'elenco di cose che sono già state fatte abbastanza bene da un'altra lingua.

Quindi, quello che qualsiasi linguaggio funzionale deve veramente decollare è una nicchia. In realtà, non ci sono ancora grandi linguaggi funzionali, ma ce ne sono molti in nicchie più piccole:

• Emacs Lisp: utilizzo costante dagli anni '80 in Emacs dagli sviluppatori. ( Quasi mai usato altrove.)
• Erlang: Ovunque tu voglia molti agenti concorrenti.
• Schema: istruzione
• APL / J / K: Finance (Chiamiamole funzionali, nell'interesse dell'argomento)
• Common Lisp: "AI" - Questo è ciò che le persone tendono a dire per cui è usato, che è una benedizione e una maledizione.

Ora, l'unica lingua principale che ritengo di aver lasciato fuori da questa discussione è Python. Python ha fatto qualcosa di molto interessante; è riuscito senza sembrare il vincitore in nessuna grande nicchia. Questo potrebbe significa che sono completamente sbagliato per la visualizzazione della popolarità della lingua in questo modo. Potrebbe anche significare che un grado abbastanza buono può diventare popolare senza un'app killer per guidare l'adozione e l'accettazione, ma è molto difficile e potrebbe richiedere molto tempo. (Perl ha una storia simile, ma è arrivata qualche anno prima e ora ha meno assorbimento.)

Da questo, posso dire quali lingue funzionali penso siano in aumento:

• Clojure: programmazione Web, esp. attraverso Heroku
• Scala: Lift (o forse Riproduci, in questi giorni) - JVM senza Java

Se mi chiedessi dove cercare i linguaggi funzionali più popolari, direi di essere alla ricerca di un linguaggio funzionale con lo sviluppo di cloud chiavi in mano (a la Heroku o GAE) o lo sviluppo di app per dispositivi mobili chiavi in mano.

Per lo stesso motivo per cui il Lisp non ha mai realmente preso piede (lascia che inizino i flamewar!). La programmazione funzionale è un paradigma molto alieno rispetto alla programmazione imperativa e orientata agli oggetti. Se, come la stragrande maggioranza degli studenti di CS, hai iniziato con C e sei passato a C ++ / Java, tendi a non voler imparare a pensare in un modo completamente ortogonale al modo in cui normalmente pensi.

Consideriamo le aziende e la programmazione.

Ci sono aziende che usano il loro software come risorsa strategica. Questo non è tipico Per la maggior parte delle aziende, l'IT è qualcosa che supporta il business reale dell'azienda. È una spesa necessaria. Sono conservatori perché sanno che per $ X possono ottenere l'IT di cui hanno bisogno, mentre se passano a qualcosa di diverso, risparmieranno meno di $ X se tutto va bene e perdono molto grande se tutto va male.

Inoltre, nelle aziende, la cosa più economica da fare è in genere ciò che hanno fatto ieri. Il cambiamento, tuttavia, è desiderabile, è costoso. Se una società dovesse passare da, ad esempio, una soluzione C # /. NET, anche a F #, avrebbero problemi. I loro programmatori (che probabilmente non sono i programmatori più acuti là fuori) dovrebbero imparare una nuova lingua, ed essere abili in entrambi, e usare entrambi frequentemente. Ci sarebbero delle routine scritte in entrambi per molto tempo. Se dovessero trasferirsi in qualcosa come Haskell, o se stessero usando C ++ / MFC in primo luogo, cambierebbero molto di più, e sarebbe molto più costoso.

Inoltre, ci sarà una fornitura di programmatori C #, e il supporto continuo di Microsoft, per molto tempo a venire. Le attuali pratiche IT possono essere contate. Non esiste lo stesso livello di supporto istituzionale o garanzia di disponibilità continua dei programmatori.

Pertanto, per la maggior parte delle aziende, apportare modifiche alla programmazione funzionale sarebbe costoso in anticipo, e si ripagherà solo se la riduzione dei costi IT è sufficiente a lungo termine, tranne che il lungo periodo è potenzialmente incerto.

Scrivi già il codice in stile funzionale, solo che non lo sai.

Quando ti viene richiesto di eseguire test unitari per il tuo codice, tendi a scrivere funzioni testabili, che non creano o dipendono da effetti collaterali, e restituisce sempre lo stesso risultato sugli stessi argomenti (le cosiddette pure funzioni). Questo è il vantaggio principale dei programmi funzionali.

Penso che i linguaggi funzionali siano troppo limitanti. Quindi, invece di sostituire le lingue imperative con linguaggi funzionali e imperativi, otterremo funzionalità funzionali. Oggigiorno quasi ogni linguaggio di programmazione ha chiusure e lambda.

Il vero problema è lo stato.

I linguaggi funzionali non hanno uno stato globale. La maggior parte dei problemi industriali richiede uno stato su larga scala (come si rappresenta un libro mastro o un insieme di transazioni) anche se alcune funzioni su piccola scala non lo richiedono effettivamente (elaborazione di un libro mastro).

Ma stiamo eseguendo il codice sulle macchine di architettura Von-Neuman che sono intrinsecamente piene di stato. Quindi non ci siamo veramente sbarazzati dello stato, i linguaggi funzionali nascondono la complessità dello stato dallo sviluppatore. Ciò significa che linguaggio / compilatore deve gestire lo stato dietro le quinte e gestirlo.

Quindi, sebbene le lingue funzionali non abbiano uno stato globale, le loro informazioni di stato vengono passate come parametri e come risultato.

So the question then becomes can the language handle the state efficiently behind the sense? Especially when the data size far exceeds the size of the architecture.

Guardandolo da Hardware Side

Il sistema operativo ha aiutato molto negli ultimi due anni a visualizzare lo spazio degli indirizzi in modo che le applicazioni non debbano preoccuparsi ufficialmente di ciò. Ma le applicazioni che non si preoccupano di cadere nella trappola del thrashing dell'hardware quando la pressione della memoria diventa intensa (l'hardware thrash rallenterà i tuoi processi fino alla scansione).

Poiché il programmatore non ha il controllo diretto sullo stato nel linguaggio funzionale, deve fare affidamento sul compilatore per gestirlo e non ho visto linguaggi funzionali che gestiscono bene questo aspetto.

Sul lato opposto della moneta, il programmatore full-state ha il controllo diretto sullo stato e può quindi compensare le condizioni di memoria insufficiente. Anche se non ho visto molti programmatori che sono abbastanza intelligenti da farlo.

Guardando dal lato dell'industria:

L'industria ha un sacco di inefficienti programmatori statali.

Ma è facile misurare i miglioramenti in questi programmi nel tempo. Lancia un team di sviluppatori al problema di poter migliorare il codice migliorando il modo in cui il programma gestisce lo stato.

Per i programmi funzionali i miglioramenti sono più difficili da misurare poiché è necessario migliorare gli strumenti che miglioreranno i programmi (stiamo solo osservando come le applicazioni gestiscono lo stato sottostante in modo efficiente qui, non il miglioramento generale del programma).

Quindi per l'industria penso che dipenda dalla capacità di misurare i miglioramenti nel codice.

Da una prospettiva di assunzione

Ci sono un sacco di programmatori stat-full disponibili per il noleggio. I programmatori funzionali sono difficili da trovare. Quindi il vostro modello di domanda e offerta base potrebbe dare il via se l'industria si scambierà con lo stile di programmazione funzionale e questo non è qualcosa che vogliono accadere (i programmatori sono abbastanza costosi così com'è).

Credo che ci sia solo una risposta reale alla tua domanda. Puoi entrare in molti motivi correlati perché questa risposta è il caso, ma quelle sono domande diverse.

Ecco qui:

• Gli architetti del software forniscono soluzioni di cui sono certi che funzioneranno.
• La maggior parte degli architetti non funziona in linguaggi funzionali.
• Una volta scelte tecnologie e lingue, le aziende trovano persone che possono lavorare con loro.

Sta prendendo piede? Tutto dipende dal fatto che le persone che hanno fiducia nell'uso di linguaggi funzionali diventino architetti e scelgano di usarlo per i progetti su cui lavorano.

Questa domanda ha premessa leggermente errata. Per i seguenti motivi:

1. La programmazione funzionale è piuttosto comune nel settore. Ma è usato solo dove sono disponibili programmatori esperti. Non ci si può aspettare che i principianti lo sappiano. Quasi tutti i grandi progetti di programmazione lo utilizzano, ma lo mantengono solo in aree gestite da programmatori esperti. I principianti si occuperanno dei moduli facili che non richiedono programmazione funzionale.
2. Data questa realtà, le aziende che assumono persone (di solito giovani provenienti dall'università) non possono davvero chiedere un'esperienza di programmazione funzionale. Chiunque in progetti che richiedono programmazione funzionale è già stato nella stessa azienda da 15 anni.
3. Le università stanno iniziando a insegnarlo, perché sanno già ora che la conoscenza della programmazione funzionale sarà molto utile in 30 anni. Il loro intervallo di tempo è tra 30 anni, non il normale semestre come nelle aziende.
4. Questi punti sono la ragione per cui le persone vengono deluse quando entrano nel mondo del lavoro e vedono che le cose che hanno imparato all'università non vengono utilizzate. Ma sono stati progettati per 30 anni, e alla fine sarà utile - è solo che le aziende stanno usando le cose semplici - le cose che possono aspettarsi che le persone sappiano.
5. Inoltre saresti arrogante se pensi che dopo pochi anni di università, conosci la programmazione funzionale abbastanza bene da usarla in progetti software reali. Inizia dalle cose semplici prima. Non hai davvero bisogno di fare il software più complesso come primo compito quando inizi a lavorare. Alla fine arriverà a cose complesse, ma ci vuole tempo.

Perché è più difficile eseguire il debug di FP.