Per quali problemi comuni la programmazione funzionale non è adatta? [chiuso]

22

La programmazione funzionale è un paradigma dichiarativo. Uno dei punti di forza di FP è che si evitano gli effetti collaterali. Si dice che per alcuni problemi FP non sia adatto.

Per quali problemi comuni la programmazione funzionale non è adatta?

functional-programming  paradigms 
— Jonas
fonte
Meno male! Per un momento ho pensato che avessi detto "è un paradigma difettoso ". Poi sono tornato e ho controllato.
— Marco C
1
Penso che sia più preciso affermare che gli effetti collaterali sono isolati (in Haskell comunque) che evitati. Le monadi consentono cambiamenti di stato e uno è persino chiamato "Stato".
— Larry Coleman,
Come ha spiegato Larry Coleman, non è vero che la programmazione funzionale evita gli effetti collaterali, ma che ne scoraggia il loro uso e, in alcune lingue, li isola chiaramente. Leggi ad esempio la Sezione 7 di research.microsoft.com/en-us/um/people/simonpj/papers/…
— Giorgio,

Risposte:

17

Applicazioni di natura molto stateful. I videogiochi sono un buon esempio perché modellano il mondo reale. Ha molto più senso pensare a modificare lo stato del mondo invece di ricostruire dallo stato precedente ogni volta che qualcosa cambia.

Un esempio concreto potrebbe cambiare la salute di un mostro dopo che è stato colpito. È molto più sensato semplicemente modificare la sua salute piuttosto che sostituirla con un mostro completamente nuovo che è lo stesso in tutti i modi tranne che ora ha meno salute. Questo tipo di cambiamenti compongono praticamente tutto in un mondo di gioco e farlo in modo puro e funzionale non è molto intuitivo. Immagino che potrebbero esserci alcune penalità di prestazione significative, almeno se lo stai facendo in un linguaggio puramente funzionale.

(Come nota a margine, alcuni problemi nei giochi sono molto adatti alla programmazione funzionale, come l'intelligenza artificiale. Un linguaggio ibrido funzionale / imperativo si adatterebbe perfettamente a questi casi.)

— Matt Olenik
fonte
9
L'articolo I prossimi linguaggi di programmazione mainstream: la prospettiva di uno sviluppatore di giochi sostiene un pl, in particolare per lo sviluppo del gioco, in cui il comportamento puramente funzionale è l'impostazione predefinita e il cambiamento di stato viene tracciato attraverso i tipi, per evitare bug. Quindi non tutti credono che il paradigma funzionale sia intrinsecamente inadatto alla programmazione dei giochi.
— sepp2k,
1
@ sepp2k, grazie per il link. Sono contento di vedere la prospettiva discussa da qualcuno che ha realizzato giochi reali.
— Matt Olenik,
3
@ sepp2k aspetta, mi sono perso qualcosa? Dopo aver letto la presentazione più da vicino, sembra che Sweeney stia sostenendo che la maggior parte del motore principale deve essere scritta con un codice puramente funzionale e che la maggior parte della logica di gioco deve essere scritta in modo imperativo (o almeno permetterlo) e utilizzare STM per aiutare con la concorrenza . Questo mi sembra molto ragionevole.
— Matt Olenik,
@Matt: No, hai ragione, dice che la parte logica del gioco conterrà uno stato mutabile. Tuttavia, ciò non impedisce alla lingua di tracciare la mutabilità attraverso i tipi (che egli propone nella sezione "riflessioni"). Naturalmente "tracciare lo stato attraverso i tipi" non equivale a "funzionale", quindi avrei potuto formulare un po 'troppo ottimisticamente il mio commento precedente.
— sepp2k,
@ sepp2k giusto, capisco cosa intendi.
— Matt Olenik,
17

La programmazione integrata in tempo reale è interamente incentrata sugli effetti collaterali. Interagendo con io, timer, porte seriali e parallele digitali e analogici, tutto ciò che è interessante viene chiamato chiamando funzioni con effetti collaterali.

— AShelly
fonte
3
Bene, se intendi semplicemente l'interfaccia hardware, dubito che qualcosa di diverso da C / C ++ sia una buona scelta. Tuttavia sullo strato in cima a quelle lingue come Erlang è usato a volte, specialmente nei sistemi di telecomunicazione. Erlang è un linguaggio funzionale progettato per sistemi embedded real-time critici e tolleranti ai guasti.
— Jonas,
@Jonas: Erlang potrebbe minimizzare la mutazione ma è fortemente dipendente da IO per trasmettere messaggi che è, ovviamente, un effetto collaterale.
— Jon Harrop,
11

Direi che la programmazione della GUI non è adatta alla programmazione funzionale. Le GUI sono generalmente molto stateful, ed è molto più facile modellarle / gestirle usando state piuttosto che usare un effetto collaterale gratuito. È certamente possibile usare un linguaggio di programmazione funzionale per le GUI ... ma probabilmente non è una buona idea.

Come indicato in un'altra risposta, i giochi sono spesso più facili da gestire monitorando lo stato e mentre è possibile scrivere un gioco in un linguaggio funzionale, è spesso più facile ed efficiente farlo in un linguaggio "stateful" (ovvero orientato agli oggetti linguaggio).

— mipadi
fonte
-1: Stai parlando di purezza e ignorando l'uso di funzioni di prima classe, ad esempio i callback nel codice GUI sono molto più facili con i linguaggi FP impuri che con i linguaggi OOP.
— Jon Harrop,
4
@Jon Harrop: le funzioni di prima classe non sono esclusive dei linguaggi di programmazione funzionale. Continuo a sostenere che lo stile FP non è adatto alle GUI.
— mipadi,
1
Dipende da chi chiedi. Per la maggior parte dei programmatori funzionali, le funzioni di prima classe sono la definizione stessa della programmazione funzionale.
— Jon Harrop,
@Jon Harrop: la maggior parte dei programmatori funzionali direbbe che la programmazione funzionale è un metodo per descrivere i programmi come composizione e valutazione delle funzioni matematiche. Le funzioni di prima classe sono una parte importante di questo paradigma, ma le funzioni di prima classe da sole non fanno un linguaggio di programmazione funzionale (o programma funzionale). Il paradigma di programmazione funzionale si impegna a ridurre al minimo l'uso di strutture dati statali e mutabili, e persino i linguaggi FP impuri incoraggiano questo stile. FP parla tanto di uno stile di programmazione quanto di caratteristiche individuali come le funzioni di prima classe, e ...
— mipadi,
... Non trovo che questo paradigma sia particolarmente suscettibile alla programmazione della GUI - i linguaggi orientati agli oggetti si adattano meglio alle GUI, in generale.
— mipadi,
5

Applicazioni aziendali basate sui dati. L'interfaccia utente e le semplici operazioni sui dati non richiedono FP.

— Branimir
fonte
2
E qualsiasi altra applicazione data / view, davvero. La maggior parte dei giochi riguarda lo stato e il suo cambiamento, quindi non si traduce bene in uno stile funzionale.
— Jon Purdy,
18
Veramente? Ho sempre pensato che FP sarebbe stato particolarmente utile per questo. Non è il 99% di quello che fanno quelle app selezionando, aggregando e proiettando dati? Questo è fondamentalmente filter, reducee map. In alcuni passi sort, partition, groupBy. Dopotutto, il linguaggio di programmazione più utilizzato per scrivere tali applicazioni è Excel, che è un linguaggio funzionale.
— Jörg W Mittag,
3
Le applicazioni aziendali basate sui dati e le applicazioni con semplici operazioni sui dati sembrano un'ottima soluzione per FP e ho sentito che FP è popolare per queste cose. Ad esempio, vedi il programmatore funzionale Adventures a Wall Street
— Jonas,
1
-1: Hai elencato alcune applicazioni in cui FP eccelle.
— Jon Harrop,
2

Non è possibile eliminare facilmente qualsiasi problema impostato per non adatto alla programmazione funzionale in sé.

Molto dipende dal linguaggio effettivo utilizzato per la programmazione funzionale e dalle sue caratteristiche.

Un esempio è il già citato Erlang per i sistemi embedded in tempo reale.

La pienezza statale non è inoltre un buon criterio contro la programmazione funzionale, ci sono diversi modi di successo implementati nei linguaggi di programmazione funzionale per far fronte a questo.

Gli effetti collaterali sono spesso citati anche contro la programmazione funzionale. Ogni programma che non è totalmente solipsistico ha effetti collaterali. Quindi ogni linguaggio FP del mondo reale ha un modo per affrontarlo, è solo una questione di quanto elegantemente incapsulare gli effetti collaterali del mondo.

Non sono assolutamente necessari effetti collaterali arbitrari come le variabili globali.

Ma ci sono serie di problemi che rendono più facile entrare nella programmazione funzionale perché non distorcono il tuo modo familiare di vedere il problema. Ma una volta che riesci a pensare che funzionale, sempre più insiemi di problemi sono aperti a meno effetti collaterali.

Anche durante la programmazione di C è sempre una buona idea ridurre il più possibile gli effetti collaterali arbitrari come le variabili globali.

— Peer Stritzinger
fonte
Le applicazioni complete come quelle della GUI sono in realtà difficili da fare in modo funzionale o hai qualche consiglio?
— Jonas,
Se hai una sorta di astrazione di processo / thread (ad esempio come in Erlang) puoi passare il tuo stato in un processo.
— Peer Stritzinger,
3
Le applicazioni della GUI sono generalmente costruite attorno a un loop di eventi. Puoi scrivere un loop di eventi abbastanza bene in un linguaggio funzionale. Se è più complicato, probabilmente aggiungerai alcuni thread / processi per l'elaborazione in background. Ma se hai qualche tipo di astrazione di processo / thread (ad esempio come in Erlang) puoi facilmente passare il tuo stato in un processo. Anche le continuazioni potrebbero tornare utili. Penso che si stia solo abituando a fare le cose in modo funzionale per avere persino un controllo sulla GUI. Uno dei motivi per cui la programmazione della GUI è considerata difficile oggi è che la maggior parte dei toolkit non sono destinati all'uso funzionale.
— Peer Stritzinger,
1
@Jonas: in Haskell, useresti la monade IO, la monade statale o una combinazione.
— Larry Coleman,
1
@Jonas: dipende dalla tua definizione di utile. L'esempio di wikibook usa wxHaskell, mentre Real World Haskell usa gtk2hs. Non ho provato neanche perché la mia app Haskell è basata sulla riga di comando.
— Larry Coleman,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.