[Programming-Languages] Perché le lingue funzionali?


Answers

Non penso che ci sia qualche domanda sull'approccio funzionale alla programmazione "in presa", perché è stato utilizzato (come uno stile di programmazione) per circa 40 anni. Ogni volta che un programmatore OO scrive un codice pulito che favorisce oggetti immutabili, quel codice prende in prestito concetti funzionali.

Tuttavia, i linguaggi che applicano uno stile funzionale stanno ottenendo un sacco di inchiostro virtuale in questi giorni e se quelle lingue diventeranno dominanti in futuro è una domanda aperta. Il mio stesso sospetto è che i linguaggi ibridi e multi-paradigma come Scala o OCaml probabilmente domineranno i linguaggi funzionali "puristi" nello stesso modo in cui il linguaggio OO puro (Smalltalk, Beta, ecc.) Ha influenzato la programmazione mainstream ma non ha finito come le notazioni più usate.

Infine, non posso fare a meno di sottolineare che i tuoi commenti su FP sono molto paralleli alle osservazioni che ho ascoltato dai programmatori procedurali non molti anni fa:

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

Proprio come le interfacce utente grafiche e il "codice come modello del business" erano concetti che hanno aiutato OO a diventare più ampiamente apprezzati, credo che un maggiore uso di immutabilità e parallelismo (massiccio) più semplice aiuterà più programmatori a vedere i vantaggi offerti dall'approccio funzionale . Ma per quanto abbiamo appreso negli ultimi 50 anni circa che compongono l'intera storia della programmazione dei computer digitali, penso che abbiamo ancora molto da imparare. Tra vent'anni, i programmatori guarderanno con stupore alla natura primitiva degli strumenti che stiamo attualmente utilizzando, inclusi gli ormai popolari linguaggi OO e FP.

Question

Vedo molto parlare qui di linguaggi e cose funzionali. Perché dovresti usare uno su una lingua "tradizionale"? Cosa fanno meglio? In cosa stanno peggio? Qual è l'applicazione di programmazione funzionale ideale?




Mi sembra che quelle persone che non hanno mai imparato Lisp o Scheme come studente universitario ora lo stanno scoprendo. Come con molte cose in questo campo, c'è una tendenza a fare pubblicità ea creare grandi aspettative ...

Passerà.

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

Ciò che ne conseguirà credo sia più capacità di linguaggio incrociato, ad esempio implementando le cose in un linguaggio funzionale e dando quindi accesso a queste cose in altre lingue.




Le cose si sono spostate in una direzione funzionale per un po '. I due nuovi fantastici ragazzini degli ultimi anni, Ruby e Python, sono entrambi radicalmente più vicini ai linguaggi funzionali rispetto a ciò che li ha preceduti, al punto che alcuni Lisper hanno iniziato a supportare l'uno o l'altro come "abbastanza vicino".

E con l'hardware massivamente parallelo che mette la pressione evolutiva su tutti - e i linguaggi funzionali nel posto migliore per affrontare i cambiamenti - non è il salto più lungo di una volta, nel pensare che Haskell o F # saranno la prossima grande cosa.




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

JavaScript è un linguaggio funzionale. Dato che sempre più persone fanno cose più avanzate con JS, in particolare sfruttando i punti migliori di jQuery, Dojo e altri framework, FP sarà introdotto dalla back-door dello sviluppatore web.

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

Saluti, PS




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

FP rende alcuni compiti relativamente semplici (rispetto ai linguaggi non FP). I linguaggi Nessuno-FP stanno già iniziando a prendere le idee dalla FP, quindi sospetto che questa tendenza continuerà e vedremo più di una fusione che dovrebbe aiutare le persone a fare il salto da FP a più facile.




Sta prendendo piede perché è lo strumento migliore per controllare la complessità. Vedere:
- diapositive 109-116 di Simon Peyton-Jones parlano di "A Taste of Haskell"
- "The Next Mainstream Programming Language: A Game Developer's Perspective" di Tim Sweeney




Una caratteristica chiave in 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. La ragione principale per farlo è che le chiamate successive a una funzione produrranno lo stesso risultato. Puoi scrivere codice funzionale in qualsiasi linguaggio che supporti le funzioni di prima classe, ma ci sono alcune lingue, come Haskell, che non ti permettono di cambiare stato. In effetti, non dovresti fare alcun effetto collaterale (come stampare del testo) - il che sembra che potrebbe essere completamente inutile.

Haskell impiega invece un diverso approccio all'IO: monadi. Questi sono oggetti che contengono l'operazione IO desiderata che deve essere eseguita dal primo livello 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 numero di potenziali bug, poiché ogni componente è completamente isolato. Inoltre, l'utilizzo delle funzioni di ricorsione e di prima classe consente di ottenere semplici prove di correttezza che in genere rispecchiano la struttura del codice.




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

Anche se, questo è vero, diversi strumenti possono essere usati per risolvere diversi problemi. Il funzionale consente solo un'ulteriore astrazione di livello (superiore?) Che consente di eseguire i nostri lavori in modo più efficace se utilizzati correttamente.




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

Pro:

  • F # farà parte della prossima versione di Visual Studio
  • Microsoft sta costruendo comunità da qualche tempo: evangelisti, libri, consulenti che lavorano con clienti di alto profilo, esposizione significativa alle conferenze MS.
  • F # è il linguaggio di prima classe .Net ed è il primo linguaggio funzionale che ha fondamenta davvero grandiose (non che io dica che Lisp, Haskell, Erlang, Scala, OCaml non hanno molte librerie, non sono così complete come .Net è)
  • Forte supporto per il parallelismo

Contra:

  • F # è molto difficile da avviare anche se si sta bene con C # e .Net - almeno per me :(
  • sarà probabilmente difficile trovare buoni sviluppatori F #

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




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

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

- Miyamoto Musashi, "Un libro di cinque anelli"




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

  1. I modi OO non sono sempre stati "normali". Lo standard di questo decennio era il concetto marginale dell'ultimo decennio.

  2. La programmazione funzionale è matematica. Paul Graham su Lisp (sostituto di programmazione funzionale per Lisp):

Quindi la breve spiegazione del perché questa lingua degli anni '50 non è obsoleta è che non era la tecnologia ma la matematica, e la matematica non diventa obsoleta. La cosa giusta per confrontare Lisp con non è l'hardware degli anni '50, ma, per dire, l'algoritmo Quicksort, che è stato scoperto nel 1960 ed è ancora l'ordinamento generale più veloce.




Anche se non lavori mai in una lingua funzionale professionalmente, 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 per non impararlo.

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




Sono d'accordo con il primo punto, ma i tempi cambiano. Le aziende risponderanno, anche se sono in ritardo, se vedono che c'è un vantaggio. La vita è dinamica

Stavano insegnando 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.

Sono d'accordo che la maggior parte delle app "esporre database relazionali sul web" continuerà a lungo in questo senso. Java EE, .NET, RoR e PHP hanno sviluppato alcune ottime soluzioni a questo problema.

Hai colpito qualcosa di importante: potrebbe essere il problema che non può essere risolto facilmente con altri mezzi che amplificheranno la programmazione funzionale. Cosa sarebbe quello?

L'enorme hardware multicore e il cloud computing li spingeranno?




La mia opinione è che si accorga ora che Microsoft l'ha spinta molto più in là 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 imparato, sarà un altro strumento che ci aiuterà a diventare più produttivi come programmatori.




Oltre alle altre risposte, lanciare la soluzione in termini puramente funzionali costringe a capire meglio il problema. Al contrario, pensando in uno stile funzionale si svilupperanno migliori * capacità di problem solving.

* O perché il paradigma funzionale è migliore o perché offrirà un ulteriore angolo di attacco.






Links