Perché l'attuale entusiasmo per la programmazione funzionale? [chiuso]

Una delle principali innovazioni in FP che ha portato alla "esplosione" di interesse è la monade.

Nel gennaio del 1992, Philip Wadler scrisse un documento intitolato L'essenza della programmazione funzionale che ha introdotto le monadi nella programmazione funzionale come modo per gestire l'IO.

Il problema principale con i linguaggi di programmazione puri, pigri e funzionali era l'utilità nel trattare con IO. È uno dei membri della "Squadra Awkward" in programmazione, perché "la pigrizia e gli effetti collaterali sono, da un punto di vista pratico, incompatibili." Se vuoi usare un linguaggio pigro, deve essere praticamente un linguaggio puramente funzionale; se vuoi usare gli effetti collaterali, è meglio usare un linguaggio rigoroso. " Riferimento

Il problema con IO prima delle monadi era che mantenere la purezza non era possibile per i programmi che erano effettivamente utili per qualcosa. Per IO, intendiamo qualsiasi cosa che riguarda il cambiamento di stato, incluso ottenere input e output dall'utente o dall'ambiente. Nella pura programmazione funzionale, tutto è immutabile, per consentire pigrizia e purezza (privo di effetti collaterali).

In che modo le monadi risolvono il problema dell'IO? Beh, senza discutere troppo delle monadi, prendono fondamentalmente il "Mondo" (l'ambiente di runtime) come input per la monade e producono un nuovo "Mondo" come output, e il risultato: tipo IO a = Mondo - > (un mondo).

FP è quindi entrato sempre più nel mainstream, perché il problema più grande, IO (e altri) è stato risolto. Come sapete, anche l'integrazione nelle lingue OO esistenti è avvenuta. LINQ è monade, per esempio, attraverso e attraverso.

Per ulteriori informazioni, consiglio di leggere le monadi e gli articoli a cui si fa riferimento nella mia risposta.

Uno dei maggiori problemi nella programmazione di linguaggi tradizionali come C, Java, C #, assemblatore, ecc. è che si dispone di una sequenza difficile di passaggi da eseguire per eseguire un determinato compito perché è necessario aver preparato prima tutte le dipendenze e le loro dipendenze in precedenza

Un esempio: per fare A, devi avere B e C presenti, e B dipende da D ed E, dando come risultato

• D
• E
• C
• B
• A

perché devi preparare gli ingredienti prima di poterli usare.

I linguaggi funzionali, specialmente quelli pigri, capovolgono questo. Affermando che A ha bisogno di B e C e lascia che sia il runtime del linguaggio a capire quando ottenere B e C (che a sua volta richiede D ed E) che vengono tutti valutati quando necessario per valutare A, è possibile creare molto piccoli e concisi elementi costitutivi, che si traducono in programmi piccoli e concisi. I linguaggi pigri consentono inoltre di utilizzare liste infinite in quanto vengono calcolati solo gli elementi effettivamente utilizzati e senza dover memorizzare l'intera infrastruttura in memoria prima di poterla utilizzare.

Il trucco davvero bello, è che questo meccanismo automatico "oh, ho bisogno di un B e di un C" è scalabile perché non ci sono restrizioni - come nel programma sequenziale - su dove e quando questo la valutazione può avvenire, quindi può accadere contemporaneamente e anche su processori o computer diversi.

Quella è la ragione per cui i linguaggi funzionali sono interessanti - perché il meccanismo "cosa fare quando" viene preso in carico dal sistema di runtime in opposizione al programmatore che deve eseguirlo manualmente. Questa è una differenza importante in quanto la raccolta automatica dei dati inutili era per Java a C, e uno dei motivi principali per cui è più facile scrivere software multi-threaded robusto e scalabile in Java rispetto a C. È ancora più facile scrivere robusti, software multithreading scalabile in lingue funzionali ...

Nei tardi anni '80 / primi anni '90 i computer sono diventati abbastanza potenti per l'OOP in stile Smalltalk. Al giorno d'oggi i computer sono abbastanza potenti per FP. FP sta programmando a un livello più alto e quindi spesso - mentre è più piacevole programmarlo - non il modo più efficiente di risolvere un certo problema. Ma i computer sono così veloci che non ti interessa.

Il prorgamming multi-core può essere più semplice con linguaggi di programmazione puramente funzionali poiché si è costretti a isolare il codice che cambia stato.

Anche i bordi del linguaggio di programmazione sono offuscati oggi. Non devi rinunciare a un paradigma se vuoi usarne un altro. Puoi fare FP nelle lingue più diffuse, quindi la barriera di accesso è bassa.

La necessità di oggi per l'elaborazione distribuita.

FP usa le funzioni come blocchi di costruzione, che non hanno stato, quindi invocarli n con gli stessi parametri dovrebbe restituire sempre lo stesso valore, non hanno effetti collaterali.

Pertanto, è possibile inviare la stessa funzione a un gruppo di macchine per eseguire e fare il lavoro in parallelo.

Nel paradigma OO, questo è un po 'più difficile, perché i blocchi costitutivi sono oggetti, che sono quasi per definizione di stato. Se invochi più volte lo stesso metodo, devi stare attento a sincronizzare i dati interni, per evitare il danneggiamento dei dati. Mentre è ancora possibile, il paradigma FP funziona meglio dell'OO in alcuni scenari in cui il calcolo deve essere distribuito.

L'avvento di FP (e NoSQL in una certa misura) arriva dopo le storie di sorprendenti risultati di elaborazione in centinaia di migliaia di computer che lavorano in parallelo e quanto sia facile.

Ma probabilmente questa è solo una nicchia il tipo di applicazioni che hanno bisogno di questo tipo di installazione. Per molte, molte altre applicazioni / sistemi, procedurali e OO funzionano bene.

Quindi tutto sta per espandere i nostri orizzonti di programmazione e riprendere questi concetti che una volta pensavamo non sarebbero andati oltre il mondo accademico.

Ho imparato a programmare in Lisp anni fa, e allora non sapevo che fosse anche FP. Ormai ho dimenticato quasi tutto, ma certamente mi aiuta a capire i concetti come la ricorsione molto facilmente.

Ci stiamo muovendo verso un'epoca in cui l'elaborazione multi-core non è solo qualcosa fatto nelle stanze posteriori dei laboratori di scienze o su hardware specializzato. Ora viene fatto con processori commodity. La programmazione funzionale, almeno per la maggior parte delle varianti a cui sono stato esposto, generalmente tenta di spingere una vista su unità computazionali prive di effetti collaterali. Questo è il paradigma per eccellenza del lavoro multi-core in quanto non è necessario mantenere lo stato misto tra i processori.

Questa è solo una delle ragioni, ma un buon motivo per vedere la programmazione funzionale prendere piede.

Penso che la risposta principale a questa domanda sia "esposizione".

La programmazione funzionale non è una novità, mi è stato insegnato Haskell all'università circa 12 anni fa e l'ho adorato. Ma raramente ho usato la lingua nel mio lavoro professionale.

Recentemente ci sono state un certo numero di lingue che hanno guadagnato trazione nel flusso principale che usano un approccio multi-paradigma; F # , JavaScript è un ottimo esempio.

JavaScript in particolare, specialmente se usato con un linguaggio di framework in stile funzionale come jQuery o Prototype , sta diventando un linguaggio quotidiano per molte persone a causa di tutto il lavoro sui siti Web dinamici moderni. Questa esposizione allo stile funzionale rende le persone consapevoli del potere che concede, specialmente quando si è in grado di tornare a uno stile imperativo a volontà.

Una volta che le persone sono esposte, provano varianti più complete di linguaggi funzionali e iniziano a usarle per le attività quotidiane.

Con F # che diventa un linguaggio di prima classe in Visual Studio 2010 e jQuery (e altri) sta diventando così importante, sta diventando realistico usare questi linguaggi, piuttosto che qualcosa di oscuro con cui giocare o fare programmi isolati.

Ricorda che il codice deve essere gestibile: una massa critica di sviluppatori deve utilizzare e supportare le lingue affinché le aziende possano sentirsi sicure nell'utilizzarle.

In questo talk Anders Hejlsberg spiega la sua opinione sull'argomento.

[EDIT]

Mi dispiace, il link era sbagliato. Ora punta al posto giusto.

Riassunto estremamente breve di alcuni punti della conversazione di un'ora:

I linguaggi funzionali consentono uno stile di programmazione più dichiarativo rispetto ai linguaggi procedurali, quindi i programmi scritti in FL di solito si concentrano maggiormente su che invece di come . Grazie alla loro elegante struttura matematica, i FL sono anche più facili da ottimizzare e trasformare da compilatori, il che consente anche una facile meta-programmazione e la costruzione di DSL incorporati. Tutto questo insieme rende i programmi funzio- nali più concisi e autodocumentanti dei programmi procedurali.

Inoltre, di fronte alla grande era del prossimo futuro, i linguaggi di programmazione devono essere in grado di utilizzare multi-threading / elaborazione in modi diversi. Il multi-threading su macchine a core singolo era in effetti un meccanismo di condivisione del tempo, e l'architettura dei sistemi lo rifletteva. La multi-threading su macchine manycore sarà molto diversa. I linguaggi funzionali sono particolarmente adatti per la parallelizzazione, dal momento che per lo più evitano lo stato, quindi non è necessario preoccuparsi tanto dell'integrità dei dati mutabili condivisi (perché tendono a non esserci dati mutabili condivisi).

Penso che abbia a che fare con la stretta correlazione tra il paradigma della programmazione funzionale e la programmazione per il web.

Ruby on Rails ha messo in risalto l'intero approccio alla programmazione funzionale poiché offriva un percorso molto rapido verso un'applicazione web funzionale (eh heh). C'è un'interessante discussione su SO su questo, e una risposta particolare spicca:

Functional programming matches web apps very well. The web app recieves a HTTP request and produces a HTML result. This could be considered a function from requests to pages.

Compare with desktop apps, where we typically have a long running process, a stateful UI and dataflow in several directions. This is more suited to OO which is concerned about objects with state and message passing.

Dato che la programmazione funzionale è in circolazione da secoli, mi chiedo perché non vedo molti annunci di lavoro alla ricerca di sviluppatori Lisp per progetti di greenfield web.

La programmazione funzionale mi dà lo stesso senso di " wow, questo è nuovo " come quando ho iniziato a dilettarmi con gli oggetti anni fa.

Mi rendo conto che FP non è un concetto nuovo di gran lunga, ma nessuno dei due era OO quando ha avuto la sua vera occasione negli anni '90 quando "tutti" improvvisamente si sono liberati della programmazione procedurale. Ciò è stato in gran parte dovuto al successo tempestivo di Java e successivamente di C #.

Immagino che la stessa cosa accadrà con FP alla fine, una volta che il prossimo gruppo di lingue inizierà a diffondersi allo stesso modo. Proprio come hanno già, almeno in alcuni ambienti, con linguaggi come Scala e F #.

Here's my questions: 1. What has contributed to the recent FP enthusiasm? Is is merely boredom with OO, or has something changed to make FP more needed than before? 2. Is this indicative of a FP future? Or is this a fad, like object orient databases?

Altri hanno dato una buona ragione tecnica.

Penso che la ragione principale per cui FP sta guadagnando la trazione tra i tipi di sviluppatori e gestori medi è la promessa di consentire un uso migliore delle CPU multi-core. Da tutto ciò che ho letto FP consente una programmazione parallela più semplice (non facile).

Sarà il futuro uso diffuso se la promessa è reale e viene soddisfatta.

Penso che sia una combinazione di due tendenze:

1. Funzioni funzionali aggiunte alle lingue tradizionali (ad es. C #).
2. Nuovi linguaggi funzionali creati.

Probabilmente c'è un limite naturale alla prima tendenza, ma suppongo che qualsiasi nuova lingua dovrà supportare la programmazione funzionale, almeno come opzione, per essere presa sul serio.

Un tempo le persone scrivevano programmi da eseguire sul desktop usando le API native del sistema operativo, e quelle API erano (generalmente) scritte in C, quindi per la maggior parte se si voleva scrivere un programma per il nativo API, hai scritto quel programma in C.

Penso che la nuova innovazione negli ultimi 10 anni sia dovuta a una varietà di API da sfruttare, in particolare per cose come lo sviluppo web in cui le API della piattaforma sono irrilevanti (dal momento che la costruzione di una pagina Web implica fondamentalmente manipolazione delle stringhe). Dal momento che non stai codificando direttamente sull'API Win32 o sull'API POSIX, ciò dà alle persone la libertà di provare le lingue funzionali.

È nutriente e elegante e solletica il tuo cervello. Va bene.

È anche, IMHO, un classico carrozzone. Una soluzione alla ricerca di un problema.

È come se tutte quelle aziende startup fondate da ingegneri abbagliati con un'idea preferita, che bruciano brillantemente per un po ', ma sono tranquillamente superate dalle aziende fondate nel fornire ciò che è necessario.

Questa è la nuova idea che mi piacerebbe vedere decollo, programmazione basata sulle necessità, non programmazione basata sull'idea. Forse suona banale, ma penso che in realtà possa essere piuttosto creativo e accattivante.

Sicuramente a causa di F #, anche se a volte è difficile stabilire quale sia la causa e qual è l'effetto.