Durante i miei quattro anni all'università abbiamo utilizzato molta programmazione funzionale in diversi linguaggi di programmazione funzionale. Ma ho anche usato molta programmazione orientata agli oggetti, e in effetti uso più linguaggi orientati agli oggetti quando faccio il mio piccolo progetto per preparare il mio primo lavoro. Ma spesso desidero codificare in un linguaggio di programmazione funzionale quando realizzo questi progetti.

Tuttavia, quando si cerca un lavoro, è molto raro vedere un lavoro in cui è richiesta la conoscenza di un linguaggio di programmazione funzionale.

Perché i linguaggi di programmazione funzionale non sono più utilizzati nel settore? Al giorno d'oggi ci sono molte notizie sui linguaggi di programmazione funzionale, quindi mi chiedo se la programmazione funzionale sta prendendo piede nel settore ora?

Direi che uno dei motivi per cui la programmazione funzionale non è più diffusa è la mancanza di base di conoscenza. La mia esperienza è che le aziende sono molto avverse al rischio in termini di implementazione di tecnologie che non sono il flusso principale e preferirebbero investire in framework collaudati (java, c ++, c #). È solo quando c'è un'esigenza aziendale (come in Ericsson) che vengono presi in considerazione nuovi paradigmi. Ma anche nel caso di Ericsson ho sentito che il management ha richiesto l'uso di c ++ e Joe Armstrong è stato costretto a codificare le chiamate in c ++ !! Questo dovrebbe mostrare come le aziende riluttanti devono implementare nuove tecnologie!

Ero un professore e, proprio come i programmatori, i professori sono sempre alla ricerca della prossima grande cosa. Quando pensano di averne trovato uno, lo rendono un carrozzone e tutti si accumulano. Dal momento che predicano agli studenti che pensano che i professori debbano essere davvero intelligenti, altrimenti perché dovrebbero essere professori, non ottengono resistenza.

La programmazione funzionale è un tale carrozzone. Sicuramente ci sono molte domande interessanti da investigare, e molti articoli per conferenze interessanti da scrivere. Non è un'idea particolarmente nuova, e puoi farlo praticamente in qualsiasi linguaggio moderno, e le idee non devono essere nuove per essere interessanti. È anche una buona abilità da avere.

Detto questo, la programmazione funzionale è solo una freccia da avere nella faretra, non l'unica, così come OOP non è l'unica.

La mia passione per il mondo accademico informatico è la mancanza di interazione pratica con l'industria per determinare ciò che realmente ha senso nel mondo reale, cioè il controllo di qualità. Se quel controllo di qualità fosse presente, potrebbe esserci un'enfasi diversa, sulla classificazione dei problemi e sulla gamma di soluzioni ad essi, con compromessi, piuttosto che solo sui più recenti vagoni.

Perché il problema più grande nello sviluppo del software in questi giorni è la capacità di gestire la complessità. Questo non è al centro della maggior parte dei linguaggi di programmazione funzionale. Come tale, le lingue che lo rendono una priorità (ovvero le lingue OOP più popolari) tendono a rubare solo alcune delle caratteristiche più interessanti che escono dai linguaggi funzionali più accademici e quindi rimanere al top.

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

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

• Produttività : apprendere FP è difficile, ma una volta capito è molto difficile battere in termini di potenza ed espressività. Probabilmente sto scrivendo circa 1/10 del numero di righe per implementare una determinata funzionalità rispetto a quello che avrei avuto bisogno in C # o Java

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

• Concorrenza : i linguaggi funzionali enfatizzano l'immutabilità, che presenta enormi vantaggi per le applicazioni simultanee rispetto alla necessità di funzionare in modo efficace su più core. E piaccia o no, correre su più core è il futuro. Vedi http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey per una spiegazione brillante del perché questo è così importante

• Composibilità / modularità : i linguaggi funzionali sembrano prestarsi a collegare i componenti più facilmente rispetto ai sistemi OO complessi. Non ho ancora capito tutte le ragioni di ciò, ma parte di ciò deriva dal fatto che non hai tutta la "complessità accidentale" che i modelli OO trascinano con sé. 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 vs. la clonazione superficiale: non è possibile comporre oggetti insieme e passarli come strutture composte senza un attenta analisi della semantica di clonazione e mutazione. In piccoli casi questo è gestibile, ma in sistemi complessi diventa rapidamente un problema significativo. Questo problema non esisterà in primo luogo se si fa affidamento su strutture di dati funzionali puri.

Mancanza di app killer

Ehi, questo qui sembra fresco. (scavare scavare)

Penso che la maggior parte dei linguaggi di programmazione abbia prosperato avendo una "app killer" - qualcosa di avvincente che era esclusivo del linguaggio (o visto in quel modo). Questo non vuol dire che tutti l'assorbimento era che l'applicazione, ma che ha spinto la lingua da un'accettazione più grande.

Ecco la mia visione non terribilmente accurata di ciò che la nicchia ha 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)
• Objective-C: app iOS (prima ancora, app OS X)
• Ruby: Rails
• C #: ASP.NET, WinForms
• PHP: Wordpress, ecc.
• Javascript: AJAX, soprattutto tramite framework
• lua: script di gioco, in particolare WoW

A parte questo, molti linguaggi proprietari sono entrati nella porta attraverso potenti organizzazioni di vendita (Oracle e, in misura minore, i linguaggi di Microsoft), creando in modo efficace la propria nicchia.

Una nota molto importante su quell'elenco: la "nicchia" del linguaggio, come indicato dall'app killer, diventa sempre più specifica col passare dei decenni. Nota l'ultimo nell'elenco: script di gioco , 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, ciò che un linguaggio funzionale deve davvero decollare è una nicchia. In realtà, non ci sono ancora enormi linguaggi funzionali, ma ce ne sono molti nelle nicchie più piccole:

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

Ora, l'unica lingua principale che sento di aver lasciato fuori da questa discussione è Python. Python ha fatto qualcosa di molto interessante; è riuscito senza sembrare il vincitore in nessuna grande nicchia. Ciò potrebbe significare che sono totalmente sbagliato nel vedere la popolarità della lingua in questo modo. Potrebbe anche significare che un linguaggio abbastanza buono può diventare popolare senza un'app killer per favorire 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 una diffusione minore).

Da ciò, posso dire quali linguaggi funzionali penso siano in aumento:

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

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

Per lo stesso motivo per cui Lisp non ha mai preso piede (che le guerre di fiamma abbiano inizio!). La programmazione funzionale è un paradigma molto alieno rispetto alla programmazione imperativa e orientata agli oggetti. Se, come la stragrande maggioranza degli studenti 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 pensi normalmente.

Consideriamo le imprese 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 vero business dell'azienda. È una spesa necessaria. Sono prudenti 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 se tutto va male.

Inoltre, nelle aziende, la cosa più economica da fare è in genere quella che hanno fatto ieri. Il cambiamento, tuttavia, è desiderabile, è costoso. Se un'azienda dovesse passare, per esempio, da una soluzione C # /. NET, anche a F #, avrebbe dei problemi. I loro programmatori (che probabilmente non sono i programmatori più acuti là fuori) dovrebbero imparare una nuova lingua, essere abili in entrambi e utilizzare entrambi frequentemente. Ci sarebbero routine scritte in entrambi per molto tempo. Se dovessero passare a qualcosa come Haskell, o se in primo luogo usassero C ++ / MFC, cambieranno molto di più, e sarebbe molto più costoso.

Inoltre, ci sarà una scorta di programmatori C # e continuerà il supporto Microsoft, per molto tempo a venire. È possibile contare sulle pratiche IT attuali. Non esiste lo stesso livello di supporto istituzionale o di garanzia della disponibilità continua dei programmatori.

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

Scrivi già il codice in stile funzionale, ma non lo conosci.

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

Penso che i linguaggi funzionali siano troppo limitanti. Quindi, invece di sostituire le lingue imperative con lingue funzionali, le lingue imperative otterranno funzionalità funzionali. Oggi quasi tutti i linguaggi di programmazione hanno chiusure e lambda.

Credo che ci sia una sola vera risposta alla tua domanda. Puoi entrare in molte ragioni correlate per cui questa risposta è il caso, ma quelle sono domande diverse.

Ecco qui:

• Gli architetti del software forniscono soluzioni di cui sono sicuri che funzioneranno.
• La maggior parte degli architetti non lavora in linguaggi funzionali.
• Una volta scelte le tecnologie e le 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 dei linguaggi funzionali stanno diventando architetti e scelgono di usarlo per i progetti su cui lavorano.

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 (elaborazione di un libro mastro).

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

Quindi, sebbene i linguaggi funzionali non abbiano uno stato globale, le loro informazioni sullo stato vengono passate come parametri e risultato.

Quindi la domanda diventa allora: la lingua può gestire lo stato in modo efficiente dietro il senso? Soprattutto quando la dimensione dei dati supera di gran lunga la dimensione dell'architettura.

Guardandolo dal lato hardware

Il sistema operativo ha aiutato molto negli ultimi due anni nella visualizzazione dello spazio degli indirizzi, quindi le applicazioni non devono ufficialmente preoccuparsene. Ma le applicazioni che non si preoccupano di cadere cadono nella trappola del thrashing dell'hardware quando la pressione della memoria diventa intensa (il thrashing dell'hardware rallenterà i processi fino a gattonare).

Dato che il programmatore non ha il controllo diretto dello stato nel linguaggio funzionale, per gestirlo devono fare affidamento sul compilatore e non ho visto linguaggi funzionali che gestiscano bene questo.

Sul lato opposto della medaglia il programmatore pieno di stato ha il controllo diretto sullo stato e può quindi compensare le condizioni di memoria insufficiente. Anche se non ho visto molti programmatori che in realtà sono abbastanza intelligenti da farlo.

Guardando dal lato dell'industria:

L'industria ha molti programmatori inefficienti pieni di stato.

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

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

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

Da una prospettiva assumente

Ci sono molti programmatori stat-full disponibili per il noleggio. I programmatori funzionali sono difficili da trovare. Quindi il tuo modello di domanda e offerta di base entrerebbe in gioco se l'industria passasse alla programmazione di stile funzionale e questo non è qualcosa che vogliono accadere (i programmatori sono abbastanza costosi come sono).

Questa domanda ha una premessa leggermente sbagliata. Per i seguenti motivi:

1. La programmazione funzionale è in realtà piuttosto comune nel settore. Ma viene utilizzato solo dove sono disponibili programmatori esperti. I principianti non possono aspettarselo. Quasi tutti i grandi progetti di programmazione lo utilizzano, ma lo tengono solo in aree gestite da programmatori esperti. I principianti si occuperanno dei moduli semplici che non richiedono una programmazione funzionale.
2. Data questa realtà, le aziende che assumono persone (di solito giovani provenienti dall'università) non possono davvero richiedere un'esperienza di programmazione funzionale. Chiunque abbia partecipato a progetti che richiedono una programmazione funzionale è già 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 tra 30 anni. Il loro intervallo di tempo è tra 30 anni, non il normale semestre come nelle aziende.
4. Questi punti sono il motivo per cui le persone rimangono deluse quando entrano nella forza lavoro e vedono che le cose che hanno imparato all'università non vengono utilizzate. Ma sono stati progettati per un periodo di 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 qualche anno di università, conosci la programmazione funzionale abbastanza bene da usarla in progetti software reali. Inizia prima dalle cose semplici. Non è davvero necessario eseguire il software più complesso come prima attività quando si inizia a lavorare. Alla fine arriverai alle cose complesse, ma ci vuole tempo.

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