Perché i linguaggi funzionali?[Chiuso]

https://stackoverflow.com/questions/36504

09-06-2019
|

Domanda

Vedo molti discorsi qui su linguaggi funzionali e cose del genere.Perché dovresti usarne uno invece di un linguaggio "tradizionale"?Cosa fanno meglio?In cosa sono peggio?Qual è l'applicazione di programmazione funzionale ideale?

Soluzione

I linguaggi funzionali utilizzano un paradigma diverso rispetto ai linguaggi imperativi e orientati agli oggetti.Usano funzioni prive di effetti collaterali come elemento fondamentale del linguaggio.Ciò consente molte cose e rende molte cose più difficili (o nella maggior parte dei casi diverse da ciò 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, ciò può rendere il codice più leggibile.

Tradizionalmente, uno dei grandi svantaggi della programmazione funzionale era anche la mancanza di effetti collaterali.È molto difficile scrivere software utile senza IO, ma l'IO è difficile da implementare senza effetti collaterali nelle funzioni.Quindi la maggior parte delle persone non ha mai ottenuto di più dalla programmazione funzionale che calcolando un singolo output da un singolo input.Nei moderni linguaggi a paradigma misto come F# o Scala questo è più semplice.

Molti linguaggi moderni contengono elementi tratti dai linguaggi di programmazione funzionale.C# 3.0 ha molte funzionalità di programmazione funzionale e puoi eseguire programmazione funzionale anche 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 programmazione normale perché stiamo ottenendo sempre più computer multiprocessore;e le lingue stanno diventando più accessibili.

Altri suggerimenti

Non penso che ci siano dubbi sul fatto che l'approccio funzionale alla programmazione stia "prendendo piede", perché è in uso (come stile di programmazione) da 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 imporre uno stile funzionale sta ricevendo molto inchiostro virtuale in questi giorni, e se questi linguaggi diventeranno dominanti in futuro è una questione aperta.Il mio sospetto è che linguaggi ibridi e multiparadigma come Scala O OCamlprobabilmente dominerà sui linguaggi funzionali "puristi" nello stesso modo in cui il linguaggio OO puro (Smalltalk, Beta, ecc.) ha influenzato la programmazione tradizionale ma non è diventato la notazione più utilizzata.

Infine, non posso trattenermi dal sottolineare che i tuoi commenti su FP sono molto paralleli alle osservazioni che ho sentito dai programmatori procedurali non molti anni fa:

Il (mitico, IMHO) programmatore "medio" non lo capisce.
Non è ampiamente insegnato.
Qualsiasi programma con cui puoi scrivere può essere scritto in un altro modo con le tecniche attuali.

Proprio come le interfacce utente grafiche e il "codice come modello di business" sono stati concetti che hanno aiutato l'OO a diventare più ampiamente apprezzato, credo che un maggiore utilizzo dell'immutabilità e del parallelismo più semplice (massiccio) aiuterà un numero maggiore di programmatori a vedere i vantaggi offerti dall'approccio funzionale. .Ma per quanto abbiamo imparato in negli ultimi 50 anni circa che costituiscono l’intera storia della programmazione dei computer digitali, 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, Compreso gli ormai popolari linguaggi OO e FP.

Il vantaggio principale per me è il suo intrinseco parallelismo, soprattutto perché ora ci stiamo allontanando da più MHz e verso sempre più core.

Non penso 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 generici lo faranno. crescere per includere costrutti più funzionali.

Anche se non lavori mai professionalmente con un linguaggio funzionale, comprendere la programmazione funzionale ti renderà uno sviluppatore migliore.Ti darà una nuova prospettiva sul tuo codice e sulla programmazione in generale.

Io dico che non c'è motivo di non impararlo.

Penso che i linguaggi che fanno un buon lavoro nel mescolare stile funzionale e imperativo siano i più interessanti e abbiano maggiori probabilità di successo.

Sono sempre scettico riguardo alla Next Big Thing.Molte volte la Next Big 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 tecnologie imperfette, tutte di enorme successo perché percepite come capaci di risolvere i problemi del giorno o come quasi identiche a standard consolidati, o entrambe le cose.La programmazione funzionale può davvero essere eccezionale, ma ciò non significa che verrà adottata.

Ma io Potere dirti perché le persone lo sono eccitato sulla programmazione funzionale:moltissimi 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) producendo al tempo stesso codice più resistente ai cambiamenti e con meno bug.Queste persone pensano alla programmazione funzionale come a un'arma segreta;un buon esempio di questa mentalità è quello di Paul Graham Battere le medie.Oh, e la sua domanda?Applicazioni web per l'e-commerce.

Dall'inizio del 2006 si è parlato anche di programmazione funzionale e parallelismo.Dal momento che alla gente piace Simon Peyton Jones mi preoccupo del parallelismo di tanto in tanto almeno dal 1984, non trattengo il fiato finché i linguaggi funzionali non risolvono il problema multicore.Ma questo spiega alcune delle voci aggiuntive in questo momento.

In generale, le università americane stanno facendo un pessimo lavoro nell’insegnare la programmazione funzionale.C'è un forte nucleo di supporto per insegnare la programmazione introduttiva utilizzando Scheme, e anche Haskell gode di un certo supporto lì, ma c'è molto poco in termini di insegnamento di tecniche avanzate per programmatori funzionali.Ho tenuto un corso del genere ad Harvard e lo farò di nuovo questa primavera al Tufts.Benjamin Pierce ha tenuto un corso del genere alla 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 idea di quello che sta succedendo in Australasia.

Non vedo nessuno menzionare l'elefante nella stanza qui, quindi penso che dipenda da me :)

JavaScript è un linguaggio funzionale.Poiché sempre più persone fanno cose più avanzate con JS, in particolare sfruttando i punti più fini di jQuery, Dojo e altri framework, FP verrà introdotto dalla backdoor dello sviluppatore web.

Insieme alle chiusure, FP rende il codice JS davvero leggero, ma comunque leggibile.

Saluti, ps

La maggior parte delle applicazioni sono sufficientemente semplici da poter essere risolte nei normali metodi 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 (sostituire la programmazione funzionale per Lisp):

Quindi la breve spiegazione del perché questa lingua degli anni '50 non è obsoleta è che non era tecnologia ma matematica e matematica non diventa stantio.La cosa giusta con cui confrontare LISP non è hardware degli anni '50, ma, diciamo, l'algoritmo QuickSort, che è stato scoperto nel 1960 ed è ancora il tipo più veloce per lo scopo generale.

Scommetto che non sapevi che stavi programmando in modo funzionale quando usavi:

Formule di Excel
Compositore al quarzo
JavaScript
Logo (grafica tartaruga)
LINQ
SQL
Sottoscritto.js (o lodash), d3

Il programmatore aziendale medio, ad es.La maggior parte delle persone con cui lavoro, non lo capirà e la maggior parte degli ambienti di lavoro non ti permetterà di programmare

Quella però è solo questione di tempo.Il tuo programmatore aziendale medio impara qualunque sia l'attuale Big Thing.15 anni fa non capivano l'OOP.SE FP prende piede, i tuoi "programmatori aziendali medi" seguiranno.

Non è veramente insegnato nelle università (o è al giorno d'oggi?)

Varia molto.Nella mia università, SML è la prima lingua con cui gli studenti vengono introdotti.Credo che il MIT insegni LISP come corso del primo anno.Questi due esempi potrebbero non essere rappresentativi, ovviamente, ma credo che la maggior parte delle università offra almeno alcuni corsi opzionali sul FP, anche se non lo rendono una parte obbligatoria del curriculum.

La maggior parte delle applicazioni sono abbastanza semplici da essere risolte in modi normali OO

Ma non è proprio una questione di "abbastanza semplice".Ci sarebbe una soluzione più semplice (o più leggibile, robusto, elegante, performante) in FP?Molte cose sono "abbastanza semplici da essere risolte in Java", ma richiedono comunque un'enorme quantità di codice.

In ogni caso, tenete presente che i sostenitori del FP sostengono che si tratti della Next Big Thing ormai da diversi decenni.Forse hanno ragione, ma tieni presente che non lo avevano quando fecero la stessa affermazione 5, 10 o 15 anni fa.

Una cosa che conta sicuramente a loro favore, però, è che recentemente C# ha preso una brusca virata verso FP, al punto che sta praticamente trasformando una generazione di programmatori in programmatori FP, senza che nemmeno se ne accorgano.Ciò potrebbe aprire la strada alla “rivoluzione” del FP.Forse.;)

L'uomo non può comprendere la perfezione e le imperfezioni dell'arte che ha scelto se non riesce a vedere il valore delle altre arti.Seguire le regole consente solo lo sviluppo fino a un certo punto della tecnica e poi lo studente e l'artista devono imparare di più e cercare oltre.Ha senso studiare altre arti oltre a quelle della strategia.

Chi non ha imparato qualcosa di più su se stesso osservando le attività degli altri?Per imparare la spada studia la chitarra.Per imparare il primo studio del commercio.Studiare semplicemente la spada ti renderà di mentalità ristretta e non ti permetterà di crescere verso l'esterno.

-- Miyamoto Musashi, "Il libro dei cinque anelli"

Una caratteristica fondamentale di un linguaggio funzionale è il concetto di funzioni di prima classe.L'idea è che puoi 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 linguaggio che supporti funzioni di prima classe, ma ci sono alcuni linguaggi, come Haskell, che non ti consentono di cambiare stato.In effetti, non dovresti avere alcun effetto collaterale (come la stampa di testo), il che sembra che potrebbe essere completamente inutile.

Haskell utilizza invece un approccio diverso all'IO:monadi.Questi sono oggetti che contengono l'operazione IO desiderata che deve essere eseguita dal livello superiore dell'interprete.A qualsiasi altro livello sono semplicemente oggetti nel sistema.

Quali vantaggi offre la programmazione funzionale?La programmazione funzionale consente di codificare con meno potenziali bug perché ogni componente è completamente isolato.Inoltre, l'uso della ricorsione e delle funzioni di prima classe consente semplici prove di correttezza che tipicamente rispecchiano la struttura del codice.

Non penso che le persone più realistiche pensino che la programmazione funzionale prenderà piede (diventerà il paradigma principale come OO).Dopotutto, la maggior parte dei problemi aziendali non sono problemi di matematica ma regole imperative 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 concise della matematica sottostante dell'universo.La gente dice che imparare la programmazione funzionale ti renderà un programmatore migliore.Questo è ovviamente altamente soggettivo.Personalmente non penso che sia del tutto vero neanche questo.

Ti rende un essere senziente migliore.

Devo essere ottuso, ma ancora non capisco.Esistono esempi reali di piccole app scritte in un linguaggio funzionale come F# in cui puoi guardare il codice sorgente e vedere come e perché è meglio utilizzare un approccio del genere rispetto, ad esempio, a 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.Allora era molto comune sentire parlare 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 verificherà indipendentemente dal fatto che le persone addestrate nelle tecnologie precedenti ritengano o meno che il cambiamento non sia necessario.Pensi che il passaggio a OO sia stato positivo nonostante tutte le persone che all'epoca erano contrarie?

F# potrebbe prendere piede perché Microsoft lo sta spingendo.

Pro:

F# farà parte della prossima versione di Visual Studio
Microsoft sta costruendo comunità ormai da tempo: evangelisti, libri, consulenti che lavorano con clienti di alto profilo, visibilità significativa alle conferenze sulla SM.
F# è un linguaggio .Net di prima classe ed è il primo linguaggio funzionale dotato di basi davvero importanti (non che io dica che Lisp, Haskell, Erlang, Scala, OCaml non abbiano molte librerie, semplicemente non sono completi come .Net È)
Forte sostegno al parallelismo

Contro:

F# è molto difficile da avviare anche se sei bravo con C# e .Net, almeno per me :(
probabilmente sarà difficile trovare buoni sviluppatori F#

Quindi do 50:50 possibilità al Fa# di diventare importante.Altri linguaggi funzionali non ce la faranno nel prossimo futuro.

Penso che uno dei motivi sia questo alcune persone ritengono che la parte più importante per determinare se una lingua verrà accettata è quanto sia buona la lingua.Sfortunatamente, raramente le cose sono così semplici.Ad esempio, direi che il fattore più importante dietro l'accettazione di Python non è il linguaggio stesso (anche se that È 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.

Linguaggi come Clojure o F# potrebbero rappresentare l'eccezione alla regola considerando che sono basati su JVM/CLR.Di conseguenza, non ho una risposta per loro.

La maggior parte delle applicazioni può essere risolta in [inserisci la tua lingua preferita, paradigma, ecc.Qui].

Anche se questo è vero, è possibile utilizzare strumenti diversi per risolvere problemi diversi.Funzionale consente semplicemente un altro livello di astrazione elevato (superiore?) che consente di svolgere il nostro lavoro in modo più efficace se utilizzato correttamente.

Mi sembra che quelle persone che non hanno mai imparato Lisp o Scheme da universitari lo stiano scoprendo.Come per molte cose in questo campo, c'è la tendenza a esagerare e a creare grandi aspettative...

Passerà.

La programmazione funzionale è fantastica.Tuttavia, non conquisterà il mondo.C, C++, Java, C#, ecc. Saranno ancora in circolazione.

Penso che ciò che ne verrà fuori sarà una maggiore capacità interlinguistica, ad esempio implementare cose in un linguaggio funzionale e quindi dare accesso a quelle cose in altre lingue.

Quando si legge "Il prossimo linguaggio di programmazione mainstream:A Game Developer's Perspective" di Tim Sweeney, Epic Games, il mio primo pensiero è stato: devo imparare Haskell.

PPT

Versione HTML di Google

Le cose si stanno muovendo in una direzione funzionale da un po’.I due nuovi fantastici ragazzi degli ultimi anni, Ruby e Python, sono entrambi radicalmente più vicini ai linguaggi funzionali rispetto a quelli che li hanno preceduti, al punto che alcuni Lisper hanno iniziato a sostenere l'uno o l'altro come "abbastanza vicino".

E con l'hardware estremamente parallelo che esercita una pressione evolutiva su tutti - e i linguaggi funzionali nel posto migliore per affrontare i cambiamenti - non è un passo così lontano come una volta pensare che Haskell o F # saranno la prossima grande novità.

Hai seguito l'evoluzione dei linguaggi di programmazione ultimamente?Ogni nuova versione di tutti i linguaggi di programmazione tradizionali sembra prendere in prestito sempre più funzionalità dalla programmazione funzionale.

Chiusure, funzioni anonime, funzioni di passaggio e restituzione come valori erano caratteristiche esotiche note solo agli hacker Lisp e ML.Ma gradualmente C#, Delphi, Python, Perl, Javascript hanno aggiunto il supporto per le chiusure.Non è possibile che qualsiasi linguaggio emergente venga preso sul serio senza una conclusione.
Diversi linguaggi, in particolare Python, C# e Ruby, hanno il supporto nativo per la comprensione delle liste e i generatori di liste.
Il machine learning è stato il pioniere della programmazione generica nel 1973, ma il supporto per i generici ("polimorfismo parametrico") è diventato uno standard di settore solo negli ultimi 5 anni circa.Se ricordo bene, Fortran supportava i generici nel 2003, seguito da Java 2004, C# nel 2005, Delphi nel 2008.(So che C++ supporta i modelli dal 1979, ma il 90% delle discussioni sull'STL di C++ inizia con "qui ci sono demoni".)

Cosa rende queste funzionalità attraenti per i programmatori?Dovrebbe essere chiaramente ovvio: aiuta i programmatori a scrivere codice più breve.Tutte le lingue in futuro sosterranno, come minimo, la chiusura se vogliono rimanere competitive.A questo proposito, la programmazione funzionale è già diventata mainstream.

La maggior parte delle applicazioni sono abbastanza semplici da essere risolte in modi normali OO

Chi dice che non è possibile utilizzare la programmazione funzionale anche per cose semplici?Non tutti i programmi funzionali devono essere compilatori, dimostratori di teoremi o commutatori di telecomunicazioni massivamente paralleli.Utilizzo regolarmente F# per script usa e getta ad hoc oltre ai miei progetti più complicati.

Sta prendendo piede perché è lo strumento migliore in circolazione per controllare la complessità.Vedere:
- diapositive 109-116 del discorso di Simon Peyton-Jones "A Taste of Haskell"
- "Il prossimo linguaggio di programmazione mainstream:La prospettiva di uno sviluppatore di giochi" di Tim Sweeney

Guardare Perché la programmazione funzionale è importante

Sono d’accordo con il primo punto, ma i tempi cambiano.Le aziende risponderanno, anche se l’avranno adottata in ritardo, se vedranno che c’è un vantaggio da ottenere.La vita è dinamica.

Alla fine degli anni '90 insegnavano Haskell e ML a Stanford.Sono sicuro che posti come la Carnegie Mellon, il MIT, Stanford e altre buone scuole lo stanno presentando agli studenti.

Sono d'accordo sul fatto che la maggior parte delle app "esporre database relazionali sul Web" continuerà in questo senso per molto tempo.Java EE, .NET, RoR e PHP hanno sviluppato alcune soluzioni piuttosto valide a questo problema.

Hai centrato qualcosa di importante:Potrebbe essere il problema che non può essere risolto facilmente con altri mezzi che migliorerà la programmazione funzionale.Cosa sarebbe quello?

Il massiccio hardware multicore e il cloud computing li spingeranno avanti?

Perché FP presenta vantaggi significativi in termini di produttività, affidabilità e manutenibilità.Many-core potrebbe essere un'app killer che finalmente convince le grandi aziende a passare nonostante grandi volumi di codice legacy. Inoltre, anche i grandi linguaggi commerciali come C# stanno assumendo un sapore funzionale distinto come risultato di preoccupazioni su molti-core - semplicemente effetti collaterali 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 l'OOP (che è altrettanto misterioso e strano, se non di più).

Inoltre, la maggior parte delle università insegna FP, molte addirittura lo insegnano come primo corso di programmazione.

Wow, questa è una discussione interessante.I miei pensieri su questo:

FP rende alcuni compiti relativamente semplici (rispetto a nessun linguaggio FP).Le lingue non-FP stanno già iniziando a prendere idee da FP, quindi sospetto che questa tendenza continuerà e vedremo più di una fusione che dovrebbe aiutare le persone a rendere più facile il salto verso FP.

Non so se prenderà piede o meno, ma dalle mie indagini quasi sicuramente vale la pena imparare un linguaggio funzionale e ti renderà un programmatore migliore.La sola comprensione della trasparenza referenziale rende molte decisioni di progettazione molto più semplici e sui programmi risultanti molto più facile ragionare.Fondamentalmente, se si verifica un problema, tende a trattarsi solo di un problema con l'output di una singola funzione, piuttosto che di un problema con uno stato incoerente, che potrebbe essere stato causato da una qualsiasi delle centinaia di classi/metodi/funzioni in un linguaggio imparativo con effetti collaterali.

La natura senza stato di FP si associa in modo più naturale alla natura senza stato del web, e quindi i linguaggi funzionali si prestano più facilmente a webapp più eleganti e RESTFUL.Contrasta con i framework JAVA e .NET che devono ricorrere a HACK orribilmente brutti come le chiavi 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, quanto più l'applicazione è stateless, tanto più facilmente potrà prestarsi all'elaborazione parallela.Terribilmente importante per il web, se il tuo sito web diventa popolare.Non è sempre semplice aggiungere semplicemente più hardware a un sito per ottenere prestazioni migliori.

La mia opinione è che prenderà piede ora che Microsoft lo ha spinto molto più in là nel mainstream.Per me è interessante per quello che può fare per noi, perché è una nuova sfida e per le opportunità di lavoro che offre per il futuro.

Una volta padroneggiato, sarà un altro strumento che ci aiuterà 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 i tipi (o almeno la maggior parte).

È interessante notare che si passa metà del tempo a scrivere nomi di tipi durante la programmazione di Java, ma Java non è di gran lunga sicuro.Anche se potresti non scrivere mai tipi in un programma Haskell (tranne che come una sorta di documentazione controllata dal compilatore) e il codice è sicuro al 100%.

Oltre alle altre risposte, esprimere la soluzione in termini puramente funzionali costringe 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.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow