La programmazione funzionale è uno dei più vecchi paradigmi di programmazione. Tuttavia non è usato molto nel settore rispetto ai paradigmi più popolari. Ma è stato ampiamente enfatizzato nel mondo accademico.
Qual è la tua opinione più strong contro la programmazione funzionale?
Il problema è che il codice più comune riguarda intrinsecamente app, giochi, UI dello stato, ecc. Non c'è alcun problema con le parti alcune puramente funzionali; infatti la maggior parte delle app potrebbe trarre vantaggio in almeno un'area. Ma forzare il paradigma dappertutto sembra controproducente.
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 i linguaggi in cui farlo.
Il problema deriva dal fatto che, nonostante siano molto intelligenti (a volte decisamente geniali), troppe persone sono solo un po 'troppo fanatiche riguardo la purezza, la perfezione e l'applicazione della propria visione (spesso piuttosto ristretta) del mondo e programmando sulla lingua e su chiunque lo usi.
Uno dei risultati è un fallimento nel compromesso. Ciò porta (tra le altre cose) a circa 10.000 lingue e dialetti che sono abbastanza diversi da infastidire, ma solo raramente abbastanza diversi da consentire ad uno di avere un vantaggio veramente significativo rispetto agli altri. Molti guardano anche al mondo reale e decidono che, poiché non si adatta molto bene al modello funzionale, è fondamentalmente sbagliato e ignorato.
L'incapacità di scendere a compromessi ha portato anche ad alcuni linguaggi che sono assolutamente belli per un tipo specifico di problema (o alcuni tipi specifici di problemi) ma in realtà suck per molti altri. Alcuni di questi sono probabilmente causati dal modello funzionale stesso, ma molto più sembra (almeno per me) causato dal tipo di personalità di base che è attratto da quest'area per cominciare.
Questo porta a una serie di problemi. Prima di tutto, l'apprendimento della "programmazione funzionale" è per lo più di valore filosofico. Con la maggior parte degli altri tipi di linguaggi, conoscere una lingua di un particolare genere è di grande aiuto per impararne un'altra. Se il mio progetto utilizza la lingua X, di solito posso assumere qualcuno che conosce la lingua Y (ma non X) in modo abbastanza sicuro. Con i linguaggi funzionali, è molto meno vero. Potresti conoscere Erlang abbastanza bene, ma troverai le monadi Haskell completamente estranee e incomprensibili.
Accoppia il numero di lingue con la limitata portabilità del talento tra di loro e ottieni una brutta situazione: è quasi impossibile che una lingua o un dialetto formino la "massa critica" necessaria per farne un uso ragionevolmente generale. Questo sta lentamente cambiando, ma è ancora molto simile a Linux che diventa il sistema operativo desktop dominante - ogni anno le persone escogitano argomenti convincenti che finalmente questo sarà l'anno - e proprio come le persone che lo hanno predetto ogni anno ormai da decenni, si sbagliano ancora una volta. Questo non vuol dire che (nessuno 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.
Penso che il motivo per cui la programmazione funzionale non viene usata in modo molto ampio è perché si intromette troppo. È difficile dare un'occhiata seria, ad esempio, a Lisp o Haskell, senza dire "tutta questa lingua è una grande inversione di astrazione". Quando stabilisci le astrazioni di base che il codificatore non può ottenere sotto, quando necessario, stabilisci cose che la lingua semplicemente non può fare, e più la lingua è funzionale, più tende a esserlo.
Prendi Haskell, per esempio. Nel nome della purezza funzionale, ti viene richiesto di usare inversioni di astrazione rompi-cervello che nessuno comprende per gestire lo stato e l'I / O, le due parti più fondamentali di qualsiasi programma per computer che interagisce con qualsiasi cosa! Diventa vecchio velocemente
I miei pensieri sulla programmazione funzionale (e probabilmente anche su altri): è molto interessante e mi piacerebbe impararlo un giorno. Sfortunatamente, sono troppo impegnato a fare lavoro vero ora.
Con tutto il rispetto, penso che la tua domanda sia mal posta. La programmazione funzionale è uno strumento, o meglio una serie di strumenti utili per risolvere determinati tipi di problemi. Avere un'opinione a riguardo ha senso solo nel contesto di un problema o di un'applicazione specifici. Avere un'opinione contro di esso in generale, è come avere un'opinione contro le pinze o le chiavi inglesi.
Anche se l'avessi padroneggiato, potrei essere poco incline a usare un linguaggio funzionale per un prodotto commerciale per la semplice ragione che non sono ampiamente capiti e se mi aspettassi che l'azienda cresca mi preoccuperei della capacità di trovare altri sviluppatori in grado di mantenerlo o estenderlo nel tempo.
Non è inconcepibile, e probabilmente otterresti uno standard più elevato di sviluppatori perché un laureato di javaschool senza una vera abilità di hacking non saprebbe da dove iniziare su un progetto di quel tipo, ma il pool limitato di sviluppatori capaci sarebbe sicuramente una considerazione necessaria dal punto di vista del business.
Non credo che dovresti essere costretto a scrivere codice puramente funzionalmente (Haskell, anche se mi piace ancora il linguaggio.) .
Time To Market
Difficile liberare un panorama IT completo di codice procedurale e mantras.
prima di tutto non accetto nessuno degli argomenti riguardanti la programmazione di stato e fp. guarda la monade di stato in haskell e troverai una serie di nuovi modi interessanti per valutare l'impatto dello stato sul tuo codice.
se dovessi fare un argomento significativo contro fp, sarebbe che imparare un linguaggio funzionale serio come haskell è come imparare a guidare una macchina di formula uno ... esaltante ed educativo, ma purtroppo inutile per la codifica industriale quotidiana perché , in media, i tuoi colleghi stanno guidando Camry e sono abbastanza contenti di farlo. è ancora estremamente difficile trovare lavoro in un ambiente fp-friendly, e non vedo questo cambiamento se non si è disposti a mettersi in proprio o cercare qualcuno dei ben noti professionisti di fp.
Suppongo che la mia risposta mi mostri come un fanboy di fp. Suggerisco di dare un vero linguaggio fp come haskell un giro serio prima di preoccuparmi di trovare i motivi per cui non dovresti.
Sono un grande fan e difensore 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. Una programmazione funzionale avanzata, con linguaggi come Haskell, Agda, Coq, ATS, ecc. È piuttosto difficile da apprendere. Alcuni usano il termine "programmazione strutturata matematica". È facile se hai familiarità con la teoria delle categorie e la matematica astratta, ma alcuni funzionano se non hai idea di cosa siano per esempio le "monadi".
la programmazione con un linguaggio di scripting può significare più produttività.
In alcune situazioni, l'utilizzo 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 dinamica orientata agli oggetti) può essere una buona cosa in questo contesto. Generalmente la digitazione statica è migliore, ma lo scripting con tipi dinamici può avere un effetto positivo.
considerazioni aziendali
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 benefici e ai rischi nella valutazione di nuove tecnologie e linguaggi di programmazione. I nuovi programmatori possono imparare rapidamente il nuovo linguaggio di programmazione? Esiste esperienza in azienda con la tecnologia? C'è un rischio e sarà difficile discutere con il management?
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 di base, 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.
Non sono contrario a FP come utile paradigma, ma sono contrario a questo come l'unico paradigma disponibile in un linguaggio di programmazione.
Offre vantaggi nella risoluzione di molti problemi. Tuttavia FP può, ed è stato, applicato in linguaggi procedurali come C.
FP è bello in ambito accademico perché è bello scrivere bei programmi brevi, ignorando le prestazioni. Non c'è alcuna cospirazione contro di esso nel mondo reale. Inoltre, ad esempio, l'implementazione di alcune cose (ad esempio il tipo di radice) sembra un dolore totale in FP. Oh e il codice generato è IMHExperience sloooooooooooooooooooow.
Il funzionale verrà fuori quando avremo centinaia di core e realizzeremo che le serrature non si ridimensionano. Quindi i dati nidificati paralleli saranno l'unico modo per ottenere programmi "di grande ferro", e il funzionale eccelle in questo.
Alcuni hanno una curva di apprendimento abbastanza ripida, impiegando molto tempo (specialmente se vieni da OOP, ti becchi la testa un paio di volte prima di ottenere il cambio di paradigma).
Anche se ho iniziato a programmare in modo funzionale (proveniente da Java e andando su Clojure), lo trovo ancora piuttosto difficile. La comunità non sembra scrivere codice tanto espressivo quanto Java.
Sembra che ci sia una piccola perdita di espressività e un piccolo aumento di complessità.
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'unico ambito in cui nutro seri dubbi sull'efficacia della FP è il modo in cui può gestire strutture dati complesse che non possono essere definite in modo induttivo, ad es. grafici. Ad esempio, se devo implementare un algoritmo che funziona su un grafico di grandi dimensioni, magari camminando nel grafico e apportando piccole modifiche locali, mi chiedo se un approccio FP possa corrispondere a un approccio imperativo in cui il programma può passare dal nodo a nodo usando i puntatori.
Leggi altre domande sui tag functional-programming paradigms