Cosa ha innescato la popolarità delle funzioni lambda nei moderni linguaggi di programmazione mainstream?

Negli ultimi anni le funzioni anonime (funzioni AKA lambda) sono diventate un costrutto linguistico molto popolare e quasi tutti i principali linguaggi di programmazione mainstream li hanno introdotti o sono previsti per introdurli in una prossima revisione dello standard.

Tuttavia, le funzioni anonime sono un concetto molto antico e molto noto in Matematica e Informatica (inventato dal matematico Alonzo Church intorno al 1936 e utilizzato dal linguaggio di programmazione Lisp dal 1958, vedi ad esempio qui ).

Quindi perché i linguaggi di programmazione tradizionali di oggi (molti dei quali originati da 15 a 20 anni fa) non supportavano le funzioni lambda sin dall'inizio e le hanno introdotte solo in seguito?

E cosa ha innescato l'adozione massiccia di funzioni anonime negli ultimi anni? C'è qualche evento specifico, nuovo requisito o tecnica di programmazione che ha iniziato questo fenomeno?

NOTA IMPORTANTE

Il focus di questa domanda è l'introduzione di funzioni anonime nei linguaggi moderni, principali (e quindi, forse con alcune eccezioni, non funzionali). Si noti inoltre che in Smalltalk sono presenti funzioni anonime (blocchi), che non è un linguaggio funzionale, e che le funzioni con nomi normali sono presenti da molto tempo anche in linguaggi procedurali come C e Pascal.

Per favore, non generalizzare troppo le tue risposte parlando di "l'adozione del paradigma funzionale e dei suoi benefici", perché questo non è l'argomento della domanda.

C'è sicuramente una tendenza evidente verso la programmazione funzionale, o almeno alcuni aspetti di essa. Alcune delle lingue popolari che ad un certo punto hanno adottato funzioni anonime sono C ++ ( C ++ 11 ), PHP ( PHP 5.3.0 ), C # ( C # v2.0 ), Delphi (dal 2009), Obiettivo C ( blocchi ) mentre Java 8 porterà il supporto per lambdas nella lingua . E ci sono lingue popolari che generalmente non sono considerate funzionali ma supportano funzioni anonime dall'inizio, o almeno all'inizio, l'esempio brillante è JavaScript.

Come per tutte le tendenze, cercare di cercare un singolo evento che li abbia stimolati è probabilmente una perdita di tempo, di solito è una combinazione di fattori, molti dei quali non sono quantificabili. Practical Common Lisp , pubblicato nel 2005, potrebbe aver avuto un ruolo importante nel portare nuova attenzione a Lisp come linguaggio pratico , poiché per un po 'di tempo Lisp era principalmente una lingua che avresti incontrato in un ambiente accademico o mercati di nicchia molto specifici. La popolarità di JavaScript potrebbe anche aver giocato un ruolo importante nel portare nuova attenzione alle funzioni anonime, come spiega munificent nella sua risposta .

Oltre all'adozione di concetti funzionali da linguaggi multiuso, c'è anche un notevole spostamento verso linguaggi funzionali (o principalmente funzionali). Lingue come Erlang (1986), Haskell (1990), OCaml (1996), Scala (2003), F # (2005), Clojure (2007) e persino lingue specifiche del dominio come R (1993) sembrano aver guadagnato un forte seguito fortemente dopo che furono introdotti. La tendenza generale ha portato nuova attenzione ai linguaggi funzionali più vecchi, come Scheme (1975) e ovviamente Common Lisp.

Penso che il singolo evento più importante sia l'adozione della programmazione funzionale nel settore. Non ho assolutamente idea del perché non fosse così, ma mi sembra che ad un certo punto all'inizio e alla metà degli anni '90 la programmazione funzionale abbia iniziato a trovare il suo posto nel settore, a partire (forse) dalla proliferazione di Erlang in telecomunicazioni e adozione di Haskell nella progettazione aerospaziale e hardware .

Joel Spolsky ha scritto un post sul blog molto interessante, The Perils of JavaSchools , dove discute contro la (allora) tendenza delle università per favorire Java rispetto ad altre lingue, forse più difficili da imparare. Sebbene il post sul blog abbia poco a che fare con la programmazione funzionale, identifica un problema chiave:

Qui sta il dibattito. Anni di lamentele da parte di studenti pigri della CS come me, combinati con le lamentele dell'industria su come pochi laureati in CS si stanno laureando dalle università americane, hanno preso un tributo e nell'ultimo decennio un gran numero di scuole altrimenti perfettamente buone sono diventate Java al 100%. È alla moda, i reclutatori che usano "grep" per valutare i curriculum sembrano apprezzarlo e, soprattutto, non c'è nulla di abbastanza difficile in Java per eliminare davvero i programmatori senza la parte del cervello che fa puntatori o ricorsioni, quindi il i tassi di abbandono sono più bassi e i dipartimenti di informatica hanno più studenti e budget più grandi, e tutto va bene.

Ricordo ancora quanto odiavo Lisp, quando l'ho incontrata per la prima volta durante gli anni del college. È sicuramente un'amante severa, e non è una lingua in cui puoi essere immediatamente produttivo (beh, almeno non potrei). Rispetto a Lisp, Haskell (per esempio) è molto più amichevole, puoi essere produttivo senza troppi sforzi e senza sentirti un completo idiota, e questo potrebbe anche essere un fattore importante nel passaggio alla programmazione funzionale.

Tutto sommato, questa è una buona cosa. Numerosi linguaggi multiuso stanno adottando concetti di paradigma che prima potrebbero sembrare arcani alla maggior parte dei loro utenti e il divario tra i paradigmi principali si sta restringendo.

Domande correlate:

• Programmazione funzionale in aumento?
• Perché la programmazione funzionale non è più popolare nel settore? Adesso ci riesce?
• Perché la programmazione funzionale non ha ancora preso il controllo?

Ulteriori letture:

• Perché i linguaggi di programmazione funzionale, in particolare Common Lisp e il dialetto Lisp Clojure, stanno tornando in popolarità?
• Programmazione funzionale: cosa ha causato l'aumento della popolarità della programmazione funzionale?
• Il tuo linguaggio di programmazione può farlo?
• Perché la programmazione funzionale? Perché Haskell?

Penso che sia interessante quanto la popolarità della programmazione funzionale abbia parallelamente la crescita e la proliferazione di Javascript. Javascript ha molte caratteristiche radicali lungo lo spettro di programmazione funzionale che al momento della sua creazione (1995) non erano molto popolari tra i linguaggi di programmazione tradizionali (C ++ / Java). È stato iniettato improvvisamente nel mainstream come l'unico linguaggio di programmazione web sul lato client. Improvvisamente molti programmatori dovevano semplicemente conoscere Javascript e quindi dovevi conoscere qualcosa delle funzionalità del linguaggio di programmazione funzionale.

Mi chiedo quanto sarebbero popolari i linguaggi / caratteristiche funzionali se non fosse stato per l'improvvisa ascesa di Javascript.

I gestori di eventi JavaScript e DOM hanno significato che milioni di programmatori dovevano imparare almeno un po 'sulle funzioni di prima classe per poter fare qualsiasi interattività sul web.

Da lì, è un passaggio relativamente breve per le funzioni anonime . Poiché JavaScript non si chiude this, ti incoraggia fortemente anche a conoscere le chiusure. E poi sei d'oro: capisci le funzioni anonime di prima classe che si chiudono al di sopra degli ambiti lessicali.

Una volta che ti senti a tuo agio, lo vuoi in ogni lingua che usi.

Non è certo l' unico fattore, ma sottolineerò la popolarità di Ruby. Non dire questo è più importante di una qualsiasi delle sei risposte già alla lavagna, ma penso che siano successe molte cose contemporaneamente e che sia utile elencarle tutte.

Ruby non è un linguaggio funzionale e i suoi lambda, pungoli e blocchi sembrano goffi quando hai usato qualcosa come ML, ma il fatto è che ha reso popolare l'idea di mappatura e riduzione a una generazione di giovani programmatori che fuggono da Java e PHP per hipper pascoli. Le lambda in diverse lingue sembrano essere mosse difensive più di ogni altra cosa ("Restate in giro! Abbiamo anche quelle !!)

Ma la sintassi del blocco e il modo in cui si sono integrati con .each, .map, .reduce e così via hanno reso popolare l'idea di una funzione anonima anche se è davvero un costrutto sintattico che si comporta come una coroutine. E la facile conversione in un proc via e lo rende un farmaco gateway per la programmazione funzionale.

Sostengo che i programmatori di Ruby on Rails che scrivono JavaScript erano già pronti a fare le cose in uno stile funzionale leggero. Abbinalo al blogging programmatore, all'invenzione di Reddit, hacker News e Stack Overflow nello stesso momento e le idee si diffondono più velocemente su Internet rispetto ai giorni dei Newsgroup.

TL; DR: Ruby, Rails, JavaScript, blogging e Reddit / Hacker News / Stack Overflow hanno spinto le idee funzionali su un mercato di massa, quindi tutti le volevano nelle lingue esistenti per prevenire ulteriori defezioni.

Come ha sottolineato Yannis , ci sono una serie di fattori che hanno influenzato l'adozione di funzioni di alto livello in lingue che prima erano prive. Uno degli elementi importanti su cui ha solo leggermente accennato è la proliferazione di processori multi-core e, con ciò, il desiderio di un'elaborazione più parallela e simultanea.

La mappa / filtro / riduzione dello stile di programmazione funzionale è molto amichevole alla parallelizzazione, consentendo al programmatore di utilizzare facilmente più core, senza scrivere alcun codice di threading esplicito.

Come osserva Giorgio, la programmazione funzionale offre molto di più che funzioni di alto livello. Le funzioni, oltre a una mappa / filtro / riduzione del modello di programmazione e l' immutabilità sono il nucleo della programmazione funzionale. Insieme, queste cose costituiscono potenti strumenti di programmazione parallela e concorrente. Per fortuna, molte lingue supportano già alcune nozioni di immutabilità e, anche se non lo fanno, i programmatori possono considerare le cose come immutabili, consentendo alle librerie e al compilatore di creare e gestire operazioni asincrone o parallele.

L'aggiunta di funzioni di alto livello a una lingua è un passaggio importante per semplificare la programmazione concorrente.

Aggiornare

Aggiungerò un paio di esempi più dettagliati per rispondere alle preoccupazioni che Loki ha notato.

Considera il seguente codice C # che attraversa una raccolta di widget, creando un nuovo elenco di prezzi dei widget.

List<float> widgetPrices;
    float salesTax = RetrieveLocalSalesTax();
foreach( Widget w in widgets ) {
    widgetPrices.Add( CalculateWidgetPrice( w, salesTax ) );
}

Per una vasta raccolta di widget o un metodo CalculateWidgetPrice (Widget) ad alta intensità computazionale, questo ciclo non farebbe buon uso di tutti i core disponibili. Per eseguire i calcoli dei prezzi su diversi core, il programmatore dovrebbe creare e gestire esplicitamente thread, passando il lavoro e raccogliendo i risultati insieme.

Prendi in considerazione una soluzione una volta aggiunte le funzioni di ordine superiore a C #:

var widgetPrices = widgets.Select( w=> CalculateWidgetPrice( w, salesTax ) );

Il ciclo foreach è stato spostato nel metodo Select, nascondendone i dettagli di implementazione. Tutto ciò che rimane al programmatore è dire Seleziona quale funzione applicare a ciascun elemento. Ciò consentirebbe all'implementazione Select di eseguire i calcoli in parallelo, gestendo tutti i problemi di sincronizzazione e gestione dei thread senza il coinvolgimento del programmatore.

Ma, ovviamente, Select non fa il suo lavoro in parallelo. È qui che entra in gioco l'immutabilità. L'implementazione di Select non sa che la funzione fornita (CalculateWidgets sopra) non ha effetti collaterali. La funzione potrebbe cambiare lo stato del programma al di fuori della vista di Select e della sua sincronizzazione, rompendo tutto. Ad esempio, in questo caso il valore di salesTax potrebbe essere modificato per errore. I linguaggi funzionali puri forniscono immutabilità, quindi la funzione Seleziona (mappa) può sapere con certezza che nessuno stato sta cambiando.

C # risolve questo problema fornendo PLINQ in alternativa a Linq. Sembrerebbe che:

var widgetPrices = widgets.AsParallel().Select(w => CalculateWidgetPrice( w, salesTax) );

Il che fa pieno uso di tutti i core del tuo sistema senza una gestione esplicita di quei core.

Sono d'accordo con molte delle risposte qui, ma la cosa interessante è che quando ho saputo delle lambda e ci sono saltato sopra, non è stato per nessuno dei motivi che altri hanno menzionato.

In molti casi, le funzioni lambda semplicemente migliorano la leggibilità del codice. Prima di lambdas quando chiamavi un metodo che accettava un puntatore a funzione (o funzione, o delegato), dovevi definire il corpo di quella funzione da qualche altra parte, quindi quando avevi un costrutto "foreach", il tuo lettore avrebbe dovuto passare a un altro parte del codice per vedere esattamente cosa stavi pianificando di fare con ogni elemento.

Se il corpo della funzione che elabora gli elementi è solo poche righe, utilizzerei una funzione anonima perché ora quando leggi il codice, la funzionalità rimane invariata, ma il lettore non deve saltare avanti e indietro, l'intera implementazione è proprio lì di fronte a lui.

Molte delle tecniche di programmazione funzionale e parallelizzazione potrebbero essere realizzate senza funzioni anonime; dichiarane uno normale e passa un riferimento a quello ogni volta che è necessario. Ma con lambda la facilità di scrittura del codice e la facilità di lettura del codice sono notevolmente migliorate.

Essendo stato coinvolto un po 'nella storia recente qui, credo che un fattore sia stato l'aggiunta di generici a Java e .NET. Ciò porta naturalmente a Func < , > e ad altre astrazioni computazionali fortemente tipizzate (Task < >, Async < > ecc.)

Nel mondo .NET abbiamo aggiunto queste funzionalità proprio per supportare FP. Ciò ha innescato una serie a cascata di lavoro linguistico relativo alla programmazione funzionale, in particolare C # 3.0, LINQ, Rx e F #. Quella progressione ha influenzato anche altri ecosistemi e continua ancora oggi in C #, F # e TypeScript.

Aiuta anche Haskell a lavorare in MSR, ovviamente :)

Naturalmente c'erano anche molte altre influenze (certamente JS) e questi passaggi erano a loro volta influenzati da molte altre cose - ma l'aggiunta di generici a questi linguaggi aiutò a rompere la rigida ortodossia OO della fine degli anni '90 in gran parte del mondo del software e aiutò ad aprire la porta per FP.

Don Syme

ps F # era il 2003, non il 2005, sebbene diremmo che non ha raggiunto la 1.0 fino al 2005. Abbiamo anche realizzato un prototipo Haskell.NET nel 2001-02.

Questa non vuole essere una risposta seria, ma la domanda mi ha ricordato un interessante post umoristico di James Iry: una storia breve, incompleta e per lo più sbagliata dei linguaggi di programmazione che include la seguente frase:

"I lambda sono relegati in una relativa oscurità fino a quando Java non li rende popolari senza averli."

Da quello che vedo, la maggior parte delle risposte si concentra sulla spiegazione del perché la programmazione funzionale in generale è tornata ed è entrata nel mainstream. Ho pensato che questo non rispondesse davvero alla domanda sulle funzioni anonime in particolare e sul perché improvvisamente diventarono così popolari.

Ciò che ha davvero guadagnato la popolarità, sono le chiusure . Poiché nella maggior parte dei casi le chiusure sono funzioni a eliminazione diretta passate variabili, ha ovviamente senso utilizzare una sintassi delle funzioni anonima per queste. E infatti in alcune lingue è l'unico modo per creare la chiusura.

Perché le chiusure hanno guadagnato popolarità? Perché sono utili nella programmazione guidata dagli eventi, durante la creazione di funzioni di callback . Attualmente è il modo di scrivere il codice client JavaScript (in realtà è il modo di scrivere qualsiasi codice GUI). Attualmente è anche il modo di scrivere codice back-end altamente efficiente e codice di sistema, poiché il codice scritto nel paradigma basato sugli eventi è generalmente asincrono e non bloccante . Per il back-end questo è diventato popolare come soluzione al problema C10K .

Penso che il motivo sia la crescente prevalenza della programmazione concorrente e distribuita, in cui il nucleo della programmazione orientata agli oggetti (incapsulando lo stato mutevole con gli oggetti) non si applica più. Nel caso di un sistema distribuito, perché non v'è alcun stato condiviso (e software astrazioni di tale nozione perde) e nel caso di un sistema concorrente, perché correttamente sincronizzazione accesso allo stato condiviso è stato dimostrato ingombrante e soggetto ad errori. Cioè, uno dei principali vantaggi della programmazione orientata agli oggetti non si applica più a molti programmi, rendendo il paradigma orientato agli oggetti molto meno utile di prima.

Al contrario, il paradigma funzionale non utilizza lo stato mutabile. Qualsiasi esperienza acquisita con paradigmi e schemi funzionali è quindi più immediatamente trasferibile al calcolo simultaneo e distribuito. E piuttosto che reinventare la ruota, l'industria ora prende in prestito quegli schemi e le caratteristiche del linguaggio per rispondere alle sue necessità.

Se potessi aggiungere i miei 0,02 €, anche se sarei d'accordo con l'importanza dell'introduzione di JavaScript nel concetto, penso che più della programmazione concorrente darei la colpa alla moda attuale della programmazione asincrona. Quando si effettuano chiamate asincrone (necessarie con le pagine Web), le funzioni anonime semplici sono così ovviamente utili, che ogni programmatore web (cioè ogni programmatore) ha dovuto acquisire familiarità con il concetto.

Un altro esempio molto antico di qualcosa di simile a funzioni anonime / lambdas è la chiamata per nome in Algol 60. Si noti tuttavia che la chiamata per nome è più vicina al passaggio di macro come parametri che al passaggio di funzioni vere, ed è più fragile / difficile da capire di conseguenza.

Qui la discendenza al meglio delle mie conoscenze.

• 2005: Javascript ha di recente portato la programmazione di ordine superiore con lambdas di nuovo nel mainstream. In particolare librerie come underscore.js e jquery . Una delle prime di queste librerie era prototype.js che precede jquery di circa un anno. Prototype si basa sul modulo Enumerable di Ruby, che ci porta a ...
• 1996: il modulo Enumerable di Ruby ovviamente prende ispirazione dal framework di raccolta di Smalltalk. Come è stato menzionato da Matz in molte interviste, che ci porta a ...
• 1980: Smalltalk utilizza molta programmazione di ordine superiore e fornisce un'API di raccolta che fa un uso intensivo della programmazione di ordine superiore (ad esempio, la classe Iterable di GNU Smalltalk ). Nel codice idiomatico Smalltalk non troverai alcun loop ma solo enumerazioni di alto ordine. Sfortunatamente quando Java, quando il framework di raccolta di Smalltalk fu portato su Java nel 1998, le enumerazioni di ordine superiore furono lasciate fuori. Ecco come la programmazione di ordine superiore è stata gradualmente eliminata dal mainstream per i prossimi dieci anni a venire! Smalltalk ha molti antenati, ma rilevante per la domanda di OP è LISP, che ci porta a ...
• 1958: LISP, ovviamente, ha al centro la programmazione di ordine superiore.

Le funzioni anonime sono utili perché nominare le cose è difficile e se si utilizza una funzione solo una volta, non è necessario un nome.

Le funzioni Lambda sono diventate mainstream solo di recente perché fino a poco tempo fa, la maggior parte delle lingue non supportava le chiusure.

Vorrei suggerire che Javascript ha spinto questo mainstream. È un linguaggio universale che non ha modo di esprimere il parallelismo e le funzioni anonime facilitano l'uso dei modelli di callback. Inoltre hanno contribuito lingue popolari come Ruby e Haskell.