Qual è la tua opinione più forte contro la programmazione funzionale? [chiuso]

25

La programmazione funzionale è uno dei più antichi paradigmi di programmazione. Tuttavia non è molto utilizzato nel settore rispetto ai paradigmi più popolari. Ma è stato ampiamente enfatizzato nel mondo accademico.

Qual è la tua opinione più forte contro la programmazione funzionale?

functional-programming paradigms

— Jonas
fonte

5

LINQ? Delegati .NET? DSL come Mathematica?

— Jon Harrop,

5

Per inciso, il termine "programmazione funzionale" viene utilizzato da persone diverse per indicare cose diverse, quindi è necessario chiarire quale significato si sta utilizzando.

— Jon Harrop,

2

Non troverai mai e poi mai persone da codificare sulla tua base di codice funzionale. Non è una grande decisione aziendale, limitare il tuo pool di talenti.

— Patrick Hughes,

52

Il problema è che il codice più comune coinvolge intrinsecamente lo stato: app, giochi, interfaccia utente e così via. Non ci sono problemi con alcune parti di un'app puramente funzionali; infatti la maggior parte delle app potrebbe trarre vantaggio in almeno un'area. Ma forzare il paradigma in tutto il luogo sembra controintuitivo.

— Nota per se stessi: pensa a un nome
fonte

19

Assolutamente. La pura programmazione funzionale NON è adatta per applicazioni molto orientate allo stato. Ecco perché mi piacciono i linguaggi ibridi che possono fare entrambi. Usa paradigmi funzionali per problemi funzionali, paradigmi imperativi per problemi imperativi.

— Matt Olenik,

8

Concordato! Lo stato è una parte essenziale della programmazione. Questo è il motivo per cui anche Haskell, in qualche modo il più puro dei linguaggi FP, consente l'uso dello stato e dell'IO: applica semplicemente una distinzione tra codice IO / codice di stato mutabile e codice puro, che è molto utile per i test e per facilità di comprensione .

— Bill,

8

Ecco perché amo Haskell. Incoraggia a minimizzare quel codice con stato. In OO ho l'obiettivo di scrivere codice riutilizzabile, facile da capire e facile da testare. Il più delle volte finisco con il codice che non scriverei molto diversamente in Haskell.

— LennyProgrammers,

4

"applica semplicemente una distinzione tra codice IO / codice di stato mutabile e codice puro, che è molto utile per i test". Non è nemmeno possibile stampare messaggi di debug senza aggirare il sistema dei tipi o introdurre monad creep.

— Jon Harrop,

2

Presumibilmente un programma di pura funzione lascerebbe il mondo completamente invariato eseguendolo?

— Martin Beckett,

24

Il problema con la programmazione funzionale non è la stessa programmazione funzionale: è la maggior parte delle persone che lo fanno e (peggio) la maggior parte delle persone che progettano linguaggi in cui farlo.

Il problema deriva dal fatto che, nonostante siano molto intelligenti (a volte addirittura geniali), troppe persone sono un po 'troppo fanatiche per la purezza, la perfezione e per applicare la propria (spesso piuttosto ristretta) visione del mondo e programmare sul lingua e tutti quelli che la usano.

Uno dei risultati è l'incapacità di scendere a compromessi. Ciò porta (tra le altre cose) a circa 10.000 lingue e dialetti che sono abbastanza diversi da infastidire, ma solo raramente abbastanza diversi perché uno abbia un vantaggio davvero significativo rispetto agli altri. Molti guardano anche al mondo reale e decidono che dal momento che non si adatta molto bene al modello funzionale, è fondamentalmente solo sbagliato e meglio ignorato.

L'incapacità di scendere a compromessi ha anche portato a parecchie lingue che sono assolutamente belle per un tipo specifico di problema (o alcuni tipi specifici di problemi) ma fanno davvero schifo per molti altri. Parte di ciò è probabilmente causata dal modello funzionale stesso, ma molto di più sembra (almeno per me) essere causato dal tipo di personalità di base che è attratto da quest'area per cominciare.

Ciò porta a una serie di problemi. Innanzitutto, l'apprendimento della "programmazione funzionale" ha principalmente un valore filosofico. Con la maggior parte degli altri tipi di lingue, conoscere una lingua di un particolare genere è di grande aiuto nell'apprendimento di un'altra. Se il mio progetto usa la lingua XI di solito posso assumere qualcuno che conosca la lingua Y (ma non X) in modo abbastanza sicuro. Con i linguaggi funzionali, è molto meno vero. Potresti conoscere Erlang abbastanza bene, ma trovare comunque monadi Haskell completamente estranei e incomprensibili.

Accoppia il numero di lingue con la limitata portabilità del talento tra loro e ottieni una brutta situazione: è quasi impossibile per una lingua o un dialetto formare la "massa critica" necessaria per renderla ragionevolmente generale. Questo sta lentamente cambiando, ma è ancora come se Linux diventasse il sistema operativo desktop dominante - ogni anno, le persone escogitano argomentazioni convincenti che alla fine questo sarà l' anno - e proprio come le persone che hanno predetto che ogni anno ormai da decenni, si sbaglieranno ancora una volta. Questo non vuol dire che (uno dei due) non può mai accadere - solo che le persone che guardano le previsioni e pensano "no, non quest'anno" sono state quelle che avevano ragione finora.

— Jerry Coffin
fonte

4

Forse ci sarebbe più crossover tra i linguaggi funzionali se ci fossero più linguaggi funzionali.

— Barry Brown,

5

Non puoi essere "funzionale" senza quella purezza. Una volta oltrepassato il limite, l'intero concetto cade a pezzi e si finisce con un linguaggio disordinato, parallelo e standard senza alcun vantaggio.

— Patrick Hughes,

7

Quindi il tuo primo problema è che i linguaggi funzionali non sono abbastanza diversi da avere un vantaggio l'uno sull'altro, e il tuo secondo problema è che sono troppo diversi per passare facilmente?

— Tikhon Jelvis l'

2

Per me, questa risposta sembra un rant. Il tuo argomento sarebbe molto più avvincente se dovessi dare alcuni esempi.

— Benjamin Hodgson,

1

...roughly 10,000 languages and dialects that are enough different to annoy but only rarely enough different for one to have a truly significant advantage over the others...

No, sembra che tutti questi lang procedurali. Java, Scala, Kotlin, C ++, C #, Groovy, Cheddar, ES6, Ceylon, Python, l'elenco potrebbe continuare all'infinito: sono solo noiose iterazioni di C che non risolvono i veri problemi. Questa è la mia opinione vaga per completare questa risposta vaga: D

— cat

17

Penso che il motivo per cui la programmazione funzionale non sia usata molto ampiamente sia perché ti ostacola troppo. È difficile dare uno sguardo serio, ad esempio, a Lisp o Haskell, senza dire "l'intera lingua è una grande inversione di astrazione". Quando si stabiliscono astrazioni di base che il programmatore non riesce a superare quando necessario, si stabiliscono cose che la lingua semplicemente non può fare, e più la lingua è funzionale, più tende ad avere.

Prendi Haskell, per esempio. In nome della purezza funzionale, ti viene richiesto di utilizzare inversioni di astrazione da rompicapo che nessuno comprende per gestire lo stato e l'I / O, le due parti fondamentali di qualsiasi programma informatico che interagisce con qualsiasi cosa! Invecchia velocemente.

— Mason Wheeler
fonte

9

+1, anche se a volte mi sento allo stesso modo quando programmo in lingue imperative di alto livello. Ad esempio, perché fsck devo creare una singola classe di metodo che implementa un'interfaccia a metodo singolo in Java invece di usare semplicemente un puntatore a funzione come farei in C?

— dsimcha,

14

Direi che non è che "non si può andare sotto" quelle astrazioni, è più che richiede solo un sacco di lavoro. Siamo abituati a raccogliere una banana e mangiarla in una lingua imperativa; Haskell (per esempio) ti fa compilare per primo un modulo di 20 pagine perché dà la priorità a garantire che nessuna banana venga misteriosamente mangiata quando non stai guardando. Il che aiuta a ragionare sulle banane, ma a volte hai solo fame.

— j_random_hacker,

4

@dsimcha: questa è una peculiarità di Java piuttosto che una tendenza nei linguaggi imperativi di alto livello. In effetti, i linguaggi di alto livello hanno probabilmente maggiori probabilità di avere la funzione come oggetto di prima classe.

— Muhammad Alkarouri,

3

La necessità per le monadi di Haskell non deriva dalla purezza funzionale ma dal fatto che gli effetti collaterali e la valutazione pigra sono due grandi sapori che NON hanno un ottimo sapore insieme. Le monadi impongono una valutazione sequenziale. (Davvero, dovrebbero essere chiamati Costruttori di Calcoli o qualcosa del genere. 'Monade' è un nome schifoso per chiunque non sia un teorico di categoria.) E puoi felicemente fare FP senza (usare consapevolmente) monadi!

— Frank Shearar,

4

Una cosa da notare: date queste "inversioni di astrazione", il linguaggio potrebbe essere più limitato, ma il compilatore e il runtime hanno più garanzie sul codice e possono fare di più. Questo è proprio come la garbage collection - in un linguaggio gc, non puoi semplicemente malloc space (che potrebbe essere utile), ma in cambio il runtime può gestire tutta la tua memoria per te, potenzialmente più efficiente di quanto potresti manualmente. È lo stesso con la purezza funzionale.

— Tikhon Jelvis l'

8

Con tutto il rispetto, penso che la tua domanda sia mal posta. La programmazione funzionale è uno strumento, o meglio un insieme di strumenti utili per risolvere determinati tipi di problemi. Avere un'opinione al riguardo ha senso solo nel contesto di un problema o un'applicazione specifici. Avere un'opinione contraria in generale, è come avere un'opinione contro pinze o chiavi inglesi.

— Dima
fonte

4

Questo è un punto logicamente valido, ma può essere risolto affrontando "per il tipo di problemi di programmazione che si incontrano frequentemente" sull'ultima frase della domanda del PO. (Non importa che i singoli lettori incontrino problemi diversi, a condizione che descrivano ciò che sono.)

— j_random_hacker

4

Anche se lo avessi dominato, potrei non essere incline a usare un linguaggio funzionale per un prodotto commerciale per la semplice ragione che non sono ampiamente capiti e se mi aspettassi che il business crescesse sarei preoccupato della capacità di trovare altri sviluppatori capaci di mantenerlo o estenderlo nel tempo.

Non è inconcepibile, e probabilmente otterresti uno standard più elevato di sviluppatore perché un laureato in javaschool senza reali capacità di hacking non saprebbe da dove iniziare un progetto di quel tipo, ma il pool limitato di sviluppatori capaci sarebbe sicuramente una considerazione necessaria dal punto di vista aziendale.

— glenatron
fonte

2

Time To Market

Difficile liberarsi di un panorama IT completo di codice procedurale e mantra.

— Coda di Jé
fonte

1

I programmi funzionali sono spesso più facili da testare. E sono più brevi. Quindi non sono d'accordo. Penso che tu risponda ad un'altra domanda "Qual è la tua opinione più forte contro il passaggio alla programmazione funzionale?".

— Jonas,

paulgraham.com/avg.html

— Giobbe

2

prima di tutto non accetto nessuno degli argomenti riguardanti la programmazione e il fp. guarda la monade dello stato in haskell e troverai una serie di nuovi modi interessanti per valutare l'impatto dello stato sul tuo codice.

se dovessi fare una discussione significativa contro il fp, sarebbe che imparare un linguaggio funzionale serio come haskell è come imparare a guidare un'auto di formula uno ... esaltante ed educativo, ma purtroppo inutile per la codifica industriale di tutti i giorni perché, in media , i tuoi colleghi stanno guidando i camrys e sono abbastanza felici di farlo. è ancora estremamente difficile trovare lavoro in un ambiente compatibile con la FP e non vedo questo cambiamento a meno che uno non sia disposto a mettersi in proprio o cercare alcuni dei noti professionisti della FP.

suppongo che la mia risposta mi mostri come un fanboy di fp. suggerisco di dare un vero e proprio linguaggio fp come haskell a un giro serio prima di preoccuparsi di trovare motivi per cui non dovresti.

— Brad Clawsie
fonte

6

Penso che il tuo primo paragrafo descriva esattamente cosa c'è di sbagliato nella mentalità FP. Non vogliamo "nuovi modi interessanti per valutare l'impatto dello stato sul nostro codice". Che cosa vuol dire, anche?!? Vogliamo solo che lo stato sia lì e facilmente accessibile perché ne abbiamo bisogno per fare davvero le cose.

— Mason Wheeler,

2

La Camry I drive ha i suoi problemi, ma non richiede che io controlli costantemente sotto il cofano per perdite di spazio . Haskell è più simile a un linguaggio che assomiglia a un'auto da F1, ma in realtà non può fare alti regimi per un periodo di tempo prolungato. :-P

— j_random_hacker

1

@Mason Wheeler: "Non vogliamo nuovi modi interessanti per valutare l'impatto dello stato sul nostro codice". Invece, preferiamo trascorrere una settimana a rintracciare un bug molto brutto a causa di un effetto collaterale indesiderato (parlo per esperienza personale).

— Giorgio,

@brad clawsie: penso che l'intera questione del controllo degli effetti collaterali in FP possa servire a rendere la codifica molto più produttiva: ci vuole più tempo per scrivere ma meno tempo per risolvere. Sfortunatamente bisogna prima impegnarsi abbastanza nell'apprendimento, e molti programmatori non hanno questo pensiero a lungo termine: le cose devono essere fatte rapidamente. Non c'è tempo per farlo correttamente la prima volta, ma c'è sempre tempo per eseguire il debug e correggerlo in seguito. :-)

— Giorgio,

@Mason Wheeler: da un punto di vista funzionale, avere uno stato condiviso è utile solo per scopi di ottimizzazione: la copia dei valori in giro richiede troppo tempo e memoria, quindi condividi un oggetto dati per evitare copie non necessarie. Ma far rispettare uno stato condiviso fin dall'inizio è una specie di ottimizzazione prematura.

— Giorgio,

2

Sono un grande fan e sostenitore della programmazione funzionale. Ma ecco i miei punti:

facile da imparare
I linguaggi di programmazione come Python e Ruby (e molte altre lingue) sono facili da imparare. La programmazione funzionale avanzata, con linguaggi come Haskell, Agda, Coq, ATS, ecc., È piuttosto difficile da imparare. Alcuni usano il termine "programmazione matematica strutturata". È facile se hai familiarità con la teoria delle categorie e la matematica astratta, ma un bel po 'di lavoro se non hai idea di cosa siano, ad esempio, le "monadi".
programmare con un linguaggio di scripting può significare maggiore produttività.
In alcune situazioni l'uso di linguaggi di scripting come python e ruby può portare a una maggiore produttività. Ciò significa prototipazione rapida e incollaggio di diversi pacchetti o librerie. Anche l'uso di linguaggi dinamici (ad es. Programmazione orientata agli oggetti dinamici) può essere una buona cosa in questo contesto. Di solito la tipizzazione statica è migliore, ma lo scripting con tipi dinamici può avere un effetto positivo.
considerazioni commerciali La
programmazione è solo un piccolo sottoinsieme di progetti software di successo. Il software deve funzionare, gli utenti devono essere felici e questo non dipende necessariamente dal linguaggio di programmazione utilizzato. I manager devono pensare ai vantaggi e ai rischi durante la valutazione di nuove tecnologie e linguaggi di programmazione. I nuovi programmatori possono imparare rapidamente il nuovo linguaggio di programmazione? C'è esperienza in azienda con la tecnologia? C'è un rischio e sarà difficile discutere con l'alta direzione?

Nel contesto aziendale, la programmazione funzionale può essere utilizzata in sistemi che si aggiungono ai componenti software principali, ad esempio componenti che non sono così mission-critical. Ad esempio una banca che difficilmente cambierà il software principale, ma aggiungerà nuove parti (GUI, software di monitoraggio, ecc.) In un nuovo linguaggio di programmazione. (Forse ci sono delle eccezioni, ma questa è la mia esperienza con le banche.)

Inoltre, la programmazione funzionale è molto utile quando la verifica formale è un vantaggio o un must.

— mrsteve
fonte

3

"facile da imparare": non trovo la padronanza di Haskell più difficile della padronanza del C ++ moderno. Penso che tendiamo a considerare duro ciò che non conosciamo.

— Giorgio,

1

Non sono contrario al FP come paradigma utile, ma sono contrario al solo paradigma disponibile in un linguaggio di programmazione.

Offre vantaggi nel risolvere molti problemi. Tuttavia, FP può ed è stato applicato in linguaggi procedurali come C.

— Huperniketes
fonte

Concordo con la prima frase, in disaccordo con la seconda. Fondamentalmente non puoi fare FP senza garbage collection.

— dsimcha,

Non è necessario che il sistema di runtime di una lingua manchi di una gestione della memoria trasparente (con garbage collection) per adattarsi all'etichetta "procedurale", quindi è ironico che tu abbia formulato la tua seconda frase in quel modo. BASIC è una di queste lingue.

— Huperniketes,

"Fondamentalmente non puoi fare FP senza garbage collection." - Perché?

— quant_dev,

+1 La programmazione funzionale al livello più elementare è la programmazione senza stato. Non penso che ci sia un linguaggio che non possa farlo in una certa misura. Ho scritto funzioni in C, C ++, Java, assembly, C #, anche Basic. Tutto ciò che serve è che la funzione non abbia effetti collaterali o mantenga lo stato tra le chiamate.

— Michael K,

D'altra parte, se la tua lingua è completamente pura, il compilatore ha più margine di manovra nelle sue ottimizzazioni. Inoltre, il codice diventa più facile da testare e ragionare su. Essere funzionale tutto non dare alcuni vantaggi rispetto un approccio ibrido; se vuoi che la maggior parte del tuo codice sia apolide comunque, puoi anche andare un po 'oltre e ottenere i benefici aggiunti.

— Tikhon Jelvis l'

1

(e di gran lunga il più importante) La forza lavoro del programmatore non è addestrata in tali lingue o stili
Molti evangelisti funzionali escono come a-hole o fruitcakes a causa del modo in cui cercano di vendere funzionali. A nessuno piace un buco, e nessuno lancerà soldi dietro una torta di frutta. Intendiamoci, mi piacciono molto le cose funzionali e mi piacerebbe inserirle, ma so che sul posto di lavoro sarei l'unica persona che potrebbe svilupparlo senza spendere soldi per la formazione (vendita dura) e quasi tutto il bene riferimenti discorsi al lettore.

Funzionale arriverà quando avremo centinaia di core e colpirà la realizzazione che i blocchi non si ridimensionano. Quindi il parallelismo dei dati nidificati sarà l'unico modo per cercare programmi "big iron", ed eccelle funzionalmente.

— subito
fonte

0

FP è fantastico in ambito accademico perché è bello scrivere brevi programmi, ignorando le prestazioni. Non c'è alcuna cospirazione contro di essa nel mondo reale. Anche per esempio l'implementazione di alcune cose (ordinamento radix per esempio) sembra un dolore totale in FP. Oh e il codice generato è IMHExperience sloooooooooooooooooooow.

— NoSenseEtAl
fonte

4

Sì, è palesemente falso. Il codice Haskell è di solito alla pari con C e Java, e molto più veloce di Python e degli amici. Di solito è anche banale parallelizzare, dando potenzialmente ancora più velocità.

— Tikhon Jelvis l'

0

Alcuni hanno una curva di apprendimento piuttosto ripida, che richiede molto tempo (soprattutto se vieni da OOP; ti beccherai la testa un paio di volte prima di ottenere il cambio di paradigma).

Anche se ho iniziato a ottenere la programmazione funzionale (proveniente da Java e andando a Clojure), lo trovo ancora piuttosto difficile. La comunità non sembra scrivere codice espressivo come Java.

Sembra che ci sia una piccola perdita di espressività e un piccolo aumento della complessità.

— Belun
fonte

Penso che le persone senza una precedente esperienza di programmazione direbbero che OOP ha una curva di apprendimento più ripida rispetto a FP, poiché FP è più vicino alla matematica. Non capisco cosa intendi con "La community non sembra scrivere codice espressivo come Java", che senso hai?

— Jonas,

Non ho mai sentito parlare di linguaggio funzionale che perde espressività. Ma poi non ho mai usato un linguaggio meno espressivo di Java, quindi potrei avere una diversa definizione di "espressivo".

— glenatron,

@Jonas - per una semplice cosa: abbreviare i nomi di funzioni, variabili, ecc ... voglio dire, perché non nominare semplicemente le cose per quello che sono o dovrebbero fare? perché "pmap"?

— Belun,

1

@Belun: questo non ha nulla a che fare con la programmazione funzionale. È necessario fare riferimento a un linguaggio di programmazione specifico. Mappa è una funzione comune in molti linguaggi di programmazione funzionale e ha un buon nome . pmapa cui ti riferisci potrebbe essere una variante parallela.

— Jonas,

ho detto "la comunità non sembra scrivere". significa che è ciò che ho vissuto e si riferisce alla comunità che ho visto. non deve applicarsi a tutti, anche se ne dubito. ha a che fare con la programmazione funzionale, è come il suo stile

— Belun,

0

Anche se ho poca esperienza con i linguaggi di programmazione funzionale (conosco alcuni Haskell e Lisp) trovo il paradigma FP molto potente e spesso più elegante di altri paradigmi. Vorrei avere l'opportunità di lavorare su un progetto serio usando FP.

L'unica area in cui nutro seri dubbi sull'efficacia di FP è nel modo in cui può gestire strutture di dati complesse che non possono essere definite induttivamente, ad esempio i grafici. Ad esempio, se devo implementare un algoritmo che funziona su un grafico di grandi dimensioni, possibilmente camminando attraverso il grafico e apportando piccole modifiche locali, mi chiedo se un approccio FP può abbinare un approccio imperativo in cui il programma può spostarsi dal nodo a nodo usando i puntatori.

— Giorgio
fonte