Vedo un sacco di discorsi qui su linguaggi e cose funzionali. Perché dovresti usarne uno su una lingua "tradizionale"? Cosa fanno meglio? A cosa stanno peggio? Qual è l'applicazione di programmazione funzionale ideale?
Risposte:
I linguaggi funzionali usano un paradigma diverso rispetto ai linguaggi imperativi e orientati agli oggetti. Usano le funzioni prive di effetti collaterali come elemento base nella lingua. Ciò consente molte cose e rende molte più difficili (o nella maggior parte dei casi diverse da quelle a cui le persone sono abituate).
Uno dei maggiori vantaggi della programmazione funzionale è che l'ordine di esecuzione delle funzioni prive di effetti collaterali non è importante. Ad esempio, in Erlang questo viene utilizzato per abilitare la concorrenza in modo molto trasparente. E poiché le funzioni nei linguaggi funzionali si comportano in modo molto simile alle funzioni matematiche, è facile tradurle in linguaggi funzionali. In alcuni casi, questo può rendere il codice più leggibile.
Tradizionalmente, uno dei maggiori svantaggi della programmazione funzionale era anche la mancanza di effetti collaterali. È molto difficile scrivere un software utile senza IO, ma IO è difficile da implementare senza effetti collaterali nelle funzioni. Quindi la maggior parte delle persone non ha mai ottenuto di più dalla programmazione funzionale rispetto al calcolo di un singolo output da un singolo input. Nei moderni linguaggi a paradigma misto come F # o Scala è più facile.
Molti linguaggi moderni hanno elementi da linguaggi di programmazione funzionali. C # 3.0 ha molte funzionalità di programmazione funzionale e puoi fare anche la programmazione funzionale in Python. Penso che le ragioni della popolarità della programmazione funzionale siano principalmente dovute a due ragioni: la concorrenza sta diventando un vero problema nella normale programmazione perché stiamo ottenendo sempre più computer multiprocessore; e le lingue stanno diventando più accessibili.
Non credo che ci siano dubbi sull'approccio funzionale alla programmazione "catturare", perché è stato in uso (come uno stile di programmazione) per circa 40 anni. Ogni volta che un programmatore OO scrive codice pulito che favorisce oggetti immutabili, quel codice prende in prestito concetti funzionali.
Tuttavia, le lingue che impongono uno stile funzionale stanno ricevendo un sacco di inchiostro virtuale al giorno d'oggi e se tali lingue diventeranno dominanti in futuro è una domanda aperta. Il mio sospetto è che i linguaggi ibridi multi-paradigma come Scala o OCaml probabilmente domineranno sui linguaggi funzionali "puristi" allo stesso modo in cui il linguaggio OO puro (Smalltalk, Beta, ecc.) Ha influenzato la programmazione tradizionale ma non è terminato come le notazioni più utilizzate.
Infine, non posso resistere nel sottolineare che i tuoi commenti su FP sono molto paralleli alle osservazioni che ho sentito dai programmatori procedurali non molti anni fa:
Proprio come le interfacce utente grafiche e il "codice come modello di business" sono stati concetti che hanno aiutato OO a diventare più ampiamente apprezzato, credo che un maggiore uso dell'immutabilità e un parallelismo più semplice (massiccio) aiuteranno più programmatori a vedere i vantaggi offerti dall'approccio funzionale . Ma per quanto abbiamo imparato negli ultimi 50 anni che compongono l'intera storia della programmazione digitale, penso che abbiamo ancora molto da imparare. Tra vent'anni, i programmatori guarderanno indietro con stupore alla natura primitiva degli strumenti che stiamo attualmente utilizzando, inclusi i linguaggi OO e FP ormai popolari.
Il vantaggio principale per me è il suo intrinseco parallelismo, soprattutto perché ora ci stiamo allontanando da più MHz e verso sempre più core.
Non credo che diventerà il prossimo paradigma di programmazione e sostituirà completamente i metodi di tipo OO, ma penso che arriveremo al punto in cui dovremo scrivere parte del nostro codice in un linguaggio funzionale, oppure i nostri linguaggi per scopi generali crescere per includere costrutti più funzionali.
Anche se non lavori mai in un linguaggio funzionale in modo professionale, capire la programmazione funzionale ti renderà uno sviluppatore migliore. Ti darà una nuova prospettiva sul tuo codice e sulla programmazione in generale.
Dico che non c'è motivo di non impararlo.
Penso che le lingue che fanno un buon lavoro nel mescolare lo stile funzionale e quello imperativo siano le più interessanti e le probabilità che abbiano successo.
Sono sempre scettico riguardo alla prossima grande cosa. Molte volte Next Next Thing è un puro incidente della storia, essere lì nel posto giusto al momento giusto, indipendentemente dal fatto che la tecnologia sia buona o meno. Esempi: C ++, Tcl / Tk, Perl. Tutte le tecnologie imperfette, tutte di grande successo perché sono state percepite o per risolvere i problemi del giorno o per essere quasi identiche a standard radicati, o entrambi. La programmazione funzionale può essere davvero eccezionale, ma ciò non significa che verrà adottata.
Ma posso dirti perché le persone sono entusiaste della programmazione funzionale: molti, molti programmatori hanno avuto una sorta di "esperienza di conversione" in cui scoprono che l'uso di un linguaggio funzionale li rende due volte più produttivi (o forse dieci volte più produttivi) durante la produzione codice che è più resistente alle modifiche e presenta meno bug. Queste persone pensano alla programmazione funzionale come un'arma segreta; un buon esempio di questa mentalità è Beating the Averages di Paul Graham . Oh, e la sua applicazione? App Web e-commerce.
Dall'inizio del 2006 si è registrato anche un certo ronzio nella programmazione funzionale e nel parallelismo. Dato che persone come Simon Peyton Jones si sono preoccupate del parallelismo, almeno dal 1984, non trattengo il respiro finché i linguaggi funzionali non risolvono il problema multicore. Ma spiega alcune delle novità in questo momento.
In generale, le università americane stanno facendo un pessimo lavoro insegnando la programmazione funzionale. C'è un forte nucleo di supporto per insegnare la programmazione introduttiva usando Scheme , e Haskell gode anche di un po 'di supporto lì, ma c'è molto poco nel modo di insegnare tecniche avanzate per programmatore funzionale. Ho tenuto un corso del genere ad Harvard e lo farò di nuovo questa primavera a Tufts. Benjamin Pierce ha tenuto un corso del genere a Penn. Non so se Paul Hudak abbia fatto qualcosa a Yale. Le università europee stanno facendo un lavoro molto migliore; ad esempio, la programmazione funzionale è enfatizzata in luoghi importanti in Danimarca, Paesi Bassi, Svezia e Regno Unito. Ho meno senso di ciò che sta accadendo in Australasia.
Non vedo nessuno menzionare l'elefante nella stanza qui, quindi penso che dipenda da me :)
JavaScript è un linguaggio funzionale. Man mano che sempre più persone fanno cose più avanzate con JS, in particolare sfruttando i punti più sottili di jQuery, Dojo e altri framework, FP sarà introdotto dal back-door dello sviluppatore web.
In combinazione con le chiusure, FP rende il codice JS davvero leggero, ma ancora leggibile.
Saluti, PS
La maggior parte delle applicazioni sono abbastanza semplici da essere risolte in normali modalità OO
I modi OO non sono sempre stati "normali". Lo standard di questo decennio era il concetto emarginato dell'ultimo decennio.
La programmazione funzionale è matematica. Paul Graham su Lisp (sostituto della programmazione funzionale per Lisp):
Quindi la breve spiegazione del perché questa lingua degli anni '50 non è obsoleta è che non si trattava di tecnologia ma di matematica e la matematica non diventa stantia. La cosa giusta per confrontare Lisp non è l'hardware degli anni '50, ma, diciamo, l'algoritmo Quicksort, che è stato scoperto nel 1960 ed è ancora il più veloce ordinamento per scopi generici.
Scommetto che non sapevi che eri una programmazione funzionale quando hai usato:
Il programmatore aziendale medio, ad esempio la maggior parte delle persone con cui lavoro, non lo capirà e la maggior parte degli ambienti di lavoro non ti permetterà di programmarlo
Quella è solo una questione di tempo. Il tuo programmatore aziendale medio impara qualunque cosa sia l'attuale Grande Cosa. 15 anni fa, non capivano OOP. Se FP prende piede, seguiranno i tuoi "programmatori aziendali medi".
Non è davvero insegnato nelle università (o è al giorno d'oggi?)
Varia molto. Nella mia università, SML è la prima lingua a cui vengono introdotti gli studenti. Credo che il MIT insegna a LISP come corso del primo anno. Questi due esempi potrebbero non essere rappresentativi, ovviamente, ma credo che la maggior parte delle università offra come minimo alcuni corsi opzionali su FP, anche se non ne fanno una parte obbligatoria del curriculum.
La maggior parte delle applicazioni sono abbastanza semplici da essere risolte in normali modalità OO
In realtà non è una questione di "abbastanza semplice". Una soluzione sarebbe più semplice (o più leggibile, robusta, elegante, performante) in FP? Molte cose sono "abbastanza semplici da essere risolte in Java", ma richiede ancora una quantità di codice formidabile.
In ogni caso, tieni presente che i sostenitori di FP hanno affermato che era la prossima grande cosa da diversi decenni ormai. Forse hanno ragione, ma tieni presente che non lo erano quando hanno fatto la stessa affermazione 5, 10 o 15 anni fa.
Una cosa che conta sicuramente a loro favore, tuttavia, è che recentemente C # ha preso una brusca svolta verso FP, nella misura in cui sta praticamente trasformando una generazione di programmatori in programmatori FP, senza che nemmeno se ne accorgano . Ciò potrebbe aprire la strada alla "rivoluzione" del PQ. Può essere. ;)
L'uomo non può capire la perfezione e le imperfezioni della sua arte scelta se non riesce a vedere il valore in altre arti. Seguire le regole consente lo sviluppo fino a un certo punto della tecnica e quindi lo studente e l'artista devono imparare di più e cercare di più. Ha senso studiare altre arti così come quelle di strategia.
Chi non ha imparato qualcosa in più su se stesso guardando le attività degli altri? Per imparare la spada studia la chitarra. Per imparare il pugno studiare il commercio. Studiare semplicemente la spada ti renderà di mentalità ristretta e non ti permetterà di crescere verso l'esterno.
- Miyamoto Musashi, "Un libro di cinque anelli"
Una caratteristica chiave in un linguaggio funzionale è il concetto di funzioni di prima classe. L'idea è che è possibile passare funzioni come parametri ad altre funzioni e restituirle come valori.
La programmazione funzionale prevede la scrittura di codice che non cambia stato. Il motivo principale per farlo è che le chiamate successive a una funzione produrranno lo stesso risultato. Puoi scrivere codice funzionale in qualsiasi lingua che supporti funzioni di prima classe, ma ci sono alcune lingue, come Haskell, che non ti consentono di cambiare stato. In effetti, non dovresti assolutamente creare effetti collaterali (come stampare il testo), il che sembra che potrebbe essere completamente inutile.
Haskell utilizza invece un approccio diverso all'IO: le monadi. Questi sono oggetti che contengono l'operazione IO desiderata che deve essere eseguita dal livello superiore dell'interprete. Ad ogni altro livello sono semplicemente oggetti nel sistema.
Quali vantaggi offre la programmazione funzionale? La programmazione funzionale consente la codifica con un minor potenziale di bug perché ogni componente è completamente isolato. Inoltre, l'uso della ricorsione e delle funzioni di prima classe consentono semplici prove di correttezza che tipicamente rispecchiano la struttura del codice.
Non credo che la maggior parte delle persone realistiche pensi che la programmazione funzionale prenderà piede (diventa il paradigma principale come OO). Dopotutto, la maggior parte dei problemi aziendali non sono piuttosto problemi matematici, ma regole imperative pelose per spostare i dati e visualizzarli in vari modi, il che significa che non è adatto al puro paradigma di programmazione funzionale (la curva di apprendimento della monade supera di gran lunga OO).
OTOH, la programmazione funzionale è ciò che rende divertente la programmazione. Ti fa apprezzare la bellezza intrinseca e senza tempo delle espressioni succinte della matematica sottostante dell'universo. Le persone dicono che l'apprendimento della programmazione funzionale ti renderà un programmatore migliore. Questo è ovviamente altamente soggettivo. Personalmente non penso che sia del tutto vero.
Ti rende un essere senziente migliore.
Devo essere denso, ma ancora non capisco. Esistono esempi concreti di piccole app scritte in un linguaggio funzionale come F # in cui puoi guardare il codice sorgente e vedere come e perché è meglio usare un approccio del genere, ad esempio C #?
Vorrei sottolineare che tutto ciò che hai detto sui linguaggi funzionali, la maggior parte delle persone diceva sui linguaggi orientati agli oggetti circa 20 anni fa. All'epoca era molto comune sapere di OO:
* The average corporate programmer, e.g. most of the people I work with, will not understand it and most work environments will not let you program in it
* It's not really taught at universities (or is it nowadays?)
* Most applications are simple enough to be solved in normal IMPERATIVE ways
Il cambiamento deve venire da qualche parte. Un cambiamento significativo e importante si realizzerà indipendentemente dal fatto che le persone addestrate nelle tecnologie precedenti ritengano che il cambiamento non sia necessario. Pensi che il cambiamento a OO sia stato buono nonostante tutte le persone che erano contrarie al momento?
F # potrebbe attecchire perché Microsoft lo sta spingendo.
Pro:
Contra:
Quindi, do 50:50 possibilità a F # di diventare importante. Altri linguaggi funzionali non ce la faranno nel prossimo futuro.
Penso che uno dei motivi sia che alcune persone ritengono che la parte più importante del fatto che una lingua venga accettata sia quanto sia buona la lingua . Sfortunatamente, le cose raramente sono così semplici. Ad esempio, direi che il principale fattore alla base dell'accettazione di Python non è il linguaggio stesso (anche se è piuttosto importante). Il motivo principale per cui Python è così popolare è la sua enorme libreria standard e la comunità ancora più grande di librerie di terze parti.
Lingue come Clojure o F # possono essere l'eccezione alla regola su questo considerando che sono costruite su JVM / CLR. Di conseguenza, non ho una risposta per loro.
La maggior parte delle applicazioni può essere risolta in [inserire qui la lingua, il paradigma, ecc. Preferiti].
Anche se questo è vero, è possibile utilizzare diversi strumenti per risolvere problemi diversi. Funzionale consente solo un'altra astrazione di alto livello (superiore?) Che consente di svolgere i nostri lavori in modo più efficace se utilizzato correttamente.
Mi sembra che le persone che non hanno mai imparato Lisp o Scheme come studente universitario lo stiano scoprendo. Come per molte cose in questo campo, c'è la tendenza a fare pubblicità e creare grandi aspettative ...
Passerà.
La programmazione funzionale è fantastica. Tuttavia, non conquisterà il mondo. C, C ++, Java, C #, ecc. Saranno ancora disponibili.
Ciò che ne verrà fuori penso che sia una maggiore capacità linguistica, ad esempio implementare cose in un linguaggio funzionale e quindi dare accesso a tali contenuti in altre lingue.
Quando ho letto "Il prossimo linguaggio di programmazione mainstream: una prospettiva per sviluppatori di giochi" di Tim Sweeney, Epic Games, il mio primo pensiero è stato: ho imparato Haskell.
Le cose si sono mosse in una direzione funzionale per un po '. I due nuovi fantastici ragazzi degli ultimi anni, Ruby e Python, sono entrambi radicalmente più vicini ai linguaggi funzionali rispetto a ciò che li ha preceduti - tanto che alcuni Lisper hanno iniziato a sostenere l'uno o l'altro come "abbastanza vicini".
E con l'hardware enormemente parallelo che esercita una pressione evolutiva su tutti - e sui linguaggi funzionali nel posto migliore per affrontare i cambiamenti - non è un grande salto come una volta pensare che Haskell o F # saranno la prossima grande novità.
Hai seguito l'evoluzione dei linguaggi di programmazione di recente? Ogni nuova versione di tutti i linguaggi di programmazione tradizionali sembra prendere in prestito sempre più funzioni dalla programmazione funzionale.
Chiusure, funzioni anonime, funzioni di passaggio e restituzione come valori utilizzati come elementi esotici noti solo agli hacker Lisp e ML. Ma gradualmente, C #, Delphi, Python, Perl, Javascript hanno aggiunto il supporto per le chiusure. Non è possibile prendere sul serio alcuna lingua emergente senza chiusure.
Diverse lingue, in particolare Python, C # e Ruby hanno il supporto nativo per la comprensione e la generazione di elenchi.
ML ha aperto la strada alla programmazione generica nel 1973, ma il supporto per i generici ("polimorfismo parametrico") è diventato uno standard industriale solo negli ultimi 5 anni circa. Se ricordo bene, Fortran ha supportato generics nel 2003, seguito da Java 2004, C # nel 2005, Delphi nel 2008. (So che C ++ supporta modelli dal 1979, ma il 90% delle discussioni sull'STL di C ++ inizia con "qui ci sono i demoni" .)
Cosa rende queste funzionalità interessanti per i programmatori? Dovrebbe essere chiaramente ovvio: aiuta i programmatori a scrivere codice più breve . Tutte le lingue in futuro supporteranno - come minimo - chiusure se vogliono rimanere competitive. A questo proposito, la programmazione funzionale è già nel mainstream.
La maggior parte delle applicazioni sono abbastanza semplici da essere risolte in normali modalità OO
Chi dice che non può usare la programmazione funzionale anche per cose semplici? Non tutti i programmi funzionali devono essere un compilatore, un teorema prover o un commutatore di telecomunicazioni fortemente parallelo. Uso regolarmente F # per script usa e getta ad hoc oltre ai miei progetti più complicati.
Sta prendendo piede perché è lo strumento migliore per controllare la complessità. Vedi:
- slide 109-116 di Simon Peyton-Jones talk "A Taste of Haskell"
- "Il prossimo linguaggio di programmazione mainstream: una prospettiva per sviluppatori di giochi" di Tim Sweeney
Sono d'accordo con il primo punto, ma i tempi cambiano. Le corporazioni risponderanno, anche se in ritardo, se vedono che c'è un vantaggio da avere. La vita è dinamica
Insegnavano Haskell e ML a Stanford alla fine degli anni '90. Sono sicuro che luoghi come Carnegie Mellon, MIT, Stanford e altre buone scuole lo stanno presentando agli studenti.
Concordo sul fatto che la maggior parte delle app "esporre database relazionali sul web" continuerà a lungo in tale ottica. Java EE, .NET, RoR e PHP hanno sviluppato alcune soluzioni piuttosto valide a questo problema.
Hai riscontrato qualcosa di importante: potrebbe essere il problema che non può essere risolto facilmente con altri mezzi che aumenterà la programmazione funzionale. Cosa sarebbe quello?
Il massiccio hardware multicore e il cloud computing li spingono avanti?
Perché FP ha notevoli vantaggi in termini di produttività, affidabilità e manutenibilità. Many-core potrebbe essere un'app killer che alla fine consente alle grandi aziende di cambiare nonostante grandi volumi di codice legacy.Inoltre, anche i grandi linguaggi commerciali come C # stanno assumendo un sapore funzionale distinto a causa di preoccupazioni di molti core - effetti collaterali semplicemente non si adattano bene alla concorrenza e al parallelismo.
Non sono d'accordo sul fatto che i programmatori "normali" non lo capiranno. Lo faranno, proprio come alla fine hanno capito OOP (che è altrettanto misterioso e strano, se non di più).
Inoltre, la maggior parte delle università insegna FP, molti addirittura lo insegnano come il primo corso di programmazione.
Caspita - questa è una discussione interessante. I miei pensieri su questo:
FP rende alcuni compiti relativamente semplici (rispetto alle lingue nessuna-FP). Nessuna delle lingue del PQ sta già iniziando a prendere idee dal PQ, quindi sospetto che questa tendenza continuerà e vedremo più di una fusione che dovrebbe aiutare le persone a facilitare il passaggio al PQ.
Non so se accadrà o meno, ma dalle mie indagini, quasi sicuramente vale la pena imparare un linguaggio funzionale e ti renderà un programmatore migliore. La semplice comprensione della trasparenza referenziale rende molto più facili le decisioni di progettazione e i programmi risultanti sono molto più facili da ragionare. Fondamentalmente, se si verifica un problema, tende a essere solo un problema con l'output di una singola funzione, piuttosto che un problema con uno stato incoerente, che potrebbe essere stato causato da una qualsiasi delle centinaia di classi / metodi / funzioni in un linguaggio imparziale con effetti collaterali.
La natura apolide di FP si associa più naturalmente alla natura apolide del web, e quindi i linguaggi funzionali si prestano più facilmente a webapp più eleganti e RESTFUL. Contrasto con i framework JAVA e .NET che devono ricorrere a HACK orribilmente orribili come i tasti VIEWSTATE e SESSION per mantenere lo stato dell'applicazione e mantenere l'astrazione (occasionalmente abbastanza permeabile) di un linguaggio imperativo con stato, su una piattaforma funzionale essenzialmente senza stato come il web.
Inoltre, maggiore è l'apolidia dell'applicazione, più facilmente può prestarsi all'elaborazione parallela. Terribilmente importante per il Web, se il tuo sito Web diventa popolare. Non è sempre semplice aggiungere più hardware a un sito per ottenere prestazioni migliori.
La mia opinione è che prenderà piede ora che Microsoft lo ha spinto molto più avanti nel mainstream. Per me è attraente per quello che può fare per noi, perché è una nuova sfida e per le opportunità di lavoro che risente per il futuro.
Una volta padroneggiato sarà un altro strumento per aiutarci ulteriormente a renderci più produttivi come programmatori.
Un punto mancato nella discussione è che i migliori sistemi di tipi si trovano nei linguaggi FP contemporanei. Inoltre, i compilatori possono dedurre automaticamente tutti (o almeno la maggior parte) tipi.
È interessante che uno passi la metà del tempo a scrivere nomi di tipi durante la programmazione di Java, ma Java non è di gran lunga sicuro. Mentre non puoi mai scrivere tipi in un programma Haskell (tranne che come una specie di documentazione verificata dal compilatore) e il codice è sicuro al 100%.
Oltre alle altre risposte, lanciare la soluzione in termini puramente funzionali obbliga a comprendere meglio il problema. Al contrario, pensare in uno stile funzionale svilupperà * migliori capacità di problem solving.
* O perché il paradigma funzionale è migliore o perché offrirà un ulteriore angolo di attacco.