La programmazione funzionale è un paradigma dichiarativo. Uno dei punti di forza di FP è che gli effetti collaterali sono evitati. Si dice che per alcuni problemi FP non è una buona scelta.
Per quali problemi comuni non è funzionale programmare una buona vestibilità?
Applicazioni di natura molto statica. I videogiochi sono un buon esempio perché modellano il mondo reale. Ha molto più senso pensare di modificare lo stato del mondo invece di ricostruire dallo stato precedente ogni volta che qualcosa cambia.
Un esempio concreto cambierebbe la salute di un mostro dopo che è stato sparato. È molto più sensato cambiare semplicemente 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 costituiscono praticamente tutto in un mondo di gioco, e farlo in modo puramente funzionale non è molto intuitivo. Immagino che ci possano essere delle penalità significative per le prestazioni, almeno se lo fai 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 funzionale / imperativo ibrido sarebbe un eccellente adattamento per quei casi.)
La programmazione embedded in tempo reale riguarda gli effetti collaterali. Interagendo con gli io, i timer, le porte seriali e parallele analogiche e digitali, tutto ciò che è interessante è chiamato chiamando le funzioni con effetti collaterali.
Direi che la programmazione GUI non è adatta alla programmazione funzionale. Le GUI sono in genere molto stateful ed è molto più semplice modellarle / gestirle usando lo stato piuttosto che usare un effetto collaterale gratuito. È certamente possibile utilizzare un linguaggio di programmazione funzionale per le GUI ... ma probabilmente non è una buona idea.
Come notato in un'altra risposta, i giochi sono spesso più facili da gestire in base allo stato del monitoraggio, e mentre puoi scrivere un gioco in un linguaggio funzionale, è spesso più facile ed efficiente farlo in un " "stateful" (cioè un linguaggio orientato agli oggetti).
Applicazioni aziendali basate sui dati. L'interfaccia utente e le operazioni di dati semplici non hanno bisogno di FP.
Non puoi facilmente eliminare qualsiasi problema impostato per non adatto alla programmazione funzionale di per sé.
Molto dipende dalla lingua utilizzata per la programmazione funzionale e le sue caratteristiche.
Un esempio è il già citato Erlang per i sistemi embedded in tempo reale.
Anche la pienezza dello stato non è un buon criterio per la programmazione funzionale, ci sono diversi modi efficaci implementati nei linguaggi di programmazione funzionale per affrontare questo problema.
Gli effetti collaterali sono spesso citati anche rispetto alla programmazione funzionale. Ogni programma che non è totalmente solipsistico ha effetti collaterali. Quindi ogni linguaggio FP del mondo reale ha un modo per affrontarlo, è solo questione di quanto elegantemente incapsulare gli effetti collaterali del mondo.
Non è necessario alcun effetto collaterale arbitrario come le variabili globali.
Ma ci sono serie di problemi che rendono più facile accedere alla programmazione funzionale perché non distorcono il tuo modo familiare di guardare il problema. Ma una volta che riesci a pensare in modo funzionale, sempre più set di problemi sono aperti a meno effetti collaterali.
Anche quando si programma C è sempre una buona idea ridurre gli effetti collaterali arbitrari come le variabili globali il più possibile.
Leggi altre domande sui tag functional-programming paradigms