La programmazione funzionale può essere utilizzata per sviluppare un'applicazione aziendale completa?

Sto appena iniziando a imparare la programmazione funzionale (FP). Vengo da un mondo OOP, in cui tutto è oggetto e la maggior parte di essi è mutevole. Faccio fatica ad avvolgere il concetto secondo cui le funzioni non hanno effetti collaterali.

Se qualcosa non è mutevole, come vengono rappresentati oggetti comuni come Employee o Person in FP.

FP può essere utilizzato per creare un'applicazione enterprise completa?

La domanda non è: FP può essere utilizzato nell'impresa? ma dovremmo usare FP in Enteprise?

Certo che puoi. È possibile sviluppare qualsiasi tipo di applicazione con qualsiasi tipo di linguaggio di programmazione, ecco perché vengono chiamati "Turing complete".

Ora, alla domanda "Dovrebbe essere usato in Enterprise?" Dipende da te o dai tuoi datori di lavoro, FP può essere davvero utile in qualche tipo di applicazione, e in effetti è usato parecchio: Haskell nel settore

Ora, potresti chiederti "Allora perché non viene usato di più?" principalmente perché altri linguaggi Imperativo / OO sono più comuni e le aziende si rifiutano di passare a un linguaggio più "esotico" perché sono utilizzate in Java o C ++.

Ho iniziato a conoscere i linguaggi FP un paio di anni fa (Haskell, Scala, Scheme) e, anche se sono ben lungi dall'essere un esperto, ho scoperto che possono rendermi estremamente produttivo, per determinati compiti più di C ++ o Java .

IMO, alcuni dei punti di forza delle lingue FP sono:

• Tendono ad essere molto concisi, eppure mantengono una chiara semantica.
• È possibile utilizzare uno stile dichiarativo e non è necessario pensare troppo ai dettagli di implementazione.
• Un sistema di tipo ricco come quello di Haskell può rilevare molti errori logici molto presto (al momento della compilazione). Per quanto ne so (non molto, in realtà), SML e Ocaml offrono vantaggi simili.

Fino ad ora, ho trovato il passaggio al paradigma FP piuttosto eccitante e non troppo difficile una volta che hai trascorso abbastanza tempo su di esso. (Ma quanto tempo ho trascorso imparando C o C ++? Abbastanza!)

Quindi penso che da un punto di vista tecnico abbia perfettamente senso sviluppare un'applicazione enterprise completa usando un linguaggio di programmazione funzionale.

Sfortunatamente questo paradigma non è mainstream: la maggior parte delle aziende tende ad adottare solo tecnologie ben collaudate, quindi rimarranno lontane da FP fino a quando non avranno prove sufficienti che funzioni effettivamente, che ci siano abbastanza sviluppatori, strumenti, librerie, framework. Pertanto è (molto) più difficile trovare un lavoro in cui è possibile eseguire la programmazione FP a tempo pieno in questo momento.

Forse la situazione attuale cambierà se l'uso crescente di processori multi-core incoraggerà a investire di più nei linguaggi FP, che sembrano essere abbastanza forti per la scrittura di software simultaneo.

Inoltre, vi è la tendenza ad introdurre alcune funzionalità FP nei linguaggi tradizionali non funzionali come C #, C ++ in modo che i programmatori possano utilizzare alcuni FP senza la necessità di un cambio di paradigma completo. Forse tra dieci anni queste lingue copriranno abbastanza funzionalità FP che il passaggio a un linguaggio puramente funzionale sarà molto più semplice.

Non penso che sia necessariamente la migliore idea. Ma dipende dalla natura dell'applicazione specifica.

Credo molto nella filosofia di Eric Evans, come descritto nel suo libro Domain-Driven Design , secondo cui dovresti creare un modello di dominio che rappresenti il ​​problema attuale che possa aiutarti a risolverlo. Evans suggerisce di trovare un linguaggio di programmazione adatto al problema specifico, ad esempio menziona Fortran come un modo per risolvere problemi di natura matematica. O anche la creazione di linguaggi specifici specifici del dominio per il problema in questione.

Quando sei riuscito a creare un buon modello di dominio, scoprirai che il codice di presentazione finisce per essere una shell sottile sopra il livello del dominio.

Ora la cosa con l'applicazione enterprise è che questo tipo di applicazione (se puoi generalizzare sulle applicazioni enterprise) spesso comporta la modifica dello stato delle entità di cui l'identità è importante e il persistere delle entità modificate in un database. Questo tipo di problema molto generalizzato è IMHO molto meglio risolto utilizzando un modello orientato agli oggetti rispetto a un modello funzionale.

Ciò non significa che ci siano aree di un'applicazione aziendale che non potrebbero essere meglio risolte da un paradigma funzionale. Ad esempio un modulo di analisi del rischio di un'applicazione bancaria o un modulo di pianificazione del percorso in un'applicazione di spedizione. E forse alcune applicazioni aziendali potrebbero essere implementate interamente usando un paradigma funzionale.

Ma in generale, penso che il paradigma orientato agli oggetti consenta di creare modelli di dominio più utili per la maggior parte delle applicazioni aziendali.

modificare

A causa di alcuni voti, la mia attenzione è stata attratta da questa risposta - e da quando l'ho scritta, ho imparato molto di più su FP - e non sono del tutto sicuro di essere più d'accordo con la mia risposta. Alcuni linguaggi funzionali possono descrivere molto bene i casi d'uso. Ma devi imparare una mentalità completamente diversa.

Sì, può. Google un po 'e troverai un vero software codificato in linguaggi funzionali puri.

Per quanto riguarda la tua domanda sugli oggetti business, immagino che il tuo vero problema sia l'immutabilità. In tal caso, considera che stai restituendo una nuova "Persona" ogni volta che la muteresti se stessi usando un linguaggio imperativo.

Nota che questa tecnica può essere implementata anche usando linguaggi imperativi!

La programmazione funzionale (FP) come la programmazione orientata agli oggetti (OOP) sono paradigmi. Rappresentano modelli o approcci diversi ai problemi di programmazione. Questi diversi approcci non ostacolano la capacità di produrre software scalabile, gestibile ed estensibile. Ciò non significa che gli approcci siano equivalenti per tutti i tipi di problemi; non lo sono. Alcuni problemi si allineano meglio (o peggio) a particolari paradigmi, ad esempio FP non sarebbe la mia prima scelta per un programma che ha una sequenza dipendente di operazioni con effetti collaterali. Tuttavia, tali programmi possono e sono stati scritti e scritti bene.

Sì, FP può essere utilizzato in applicazioni aziendali. Clojure è un esempio di linguaggio FP con successo nelle imprese: http://cognitect.com/clojure#successstories

Rappresentare lo stato può essere una sfida in FP e cambiare i paradigmi per adattarlo a FP può essere un po 'una distorsione mentale. Alcuni linguaggi FP non consentono completamente gli effetti collaterali e lo stato mutevole. Clojure permette entrambi ma scoraggia o isola quei paradigmi.

In breve, la rappresentazione statale può essere molto simile a OO. La modifica dello stato è molto diversa. Quindi, ad esempio, nello stato FP può essere rappresentato da elenchi e mappe. Un elenco di dipendenti può apparire come:

[[name: "James Brown" address: "Barnwell, SC"]
 [name: "Elvis Presley" address: "Tupelo, MS"]]

Ci sono due modi che conosco per gestire la modifica dello stato in FP. Uno è qualcosa come la programmazione reattiva funzionale. In questo paradigma tutto lo stato viene gestito solo al massimo livello ... ad esempio, una vista HTML dell'applicazione ha uno stato nella vista (come il nome, l'indirizzo della persona, ecc.). Ora, quando si fa clic su "aggiorna nome", viene chiamata una funzione che gestisce tutto ciò che riguarda un aggiornamento del nome, tranne che la modifica del nome. Può sembrare strano ... ma abbi pazienza. Il nome modificato verrà quindi restituito dalla funzione e la vista (o archivio dati persistente, ecc.) Mostrerà il nuovo nome. Oppure, in alternativa, verrà restituita un'intera nuova struttura con il nome aggiornato. Quindi cosa fa la funzione? Convalida il nome e restituisce il nuovo nome se è valido, un errore in caso contrario, e possibilmente una nuova vista o collegamento di navigazione da seguire. Per qualcosa di più complesso di un cambio di nome, potrebbe fare molto di più.

Quindi per FRP l'oggetto restituito dalla funzione è il nuovo stato e può essere dato direttamente alla vista o qualunque cosa sia ad alto livello. In alcuni casi FRP prende l'intero stato e lo passa alla funzione e ripristina l'intero stato.

Con questo paradigma, il contenitore o il framework deve gestire l'aggiornamento del display, del database o di qualsiasi altra cosa necessiti l'aggiornamento dal nuovo stato. Quindi puoi immaginare un framework che disegna l'applicazione sullo schermo. Quando un utente fa clic su qualcosa, vengono invocate le funzioni e viene restituito il nuovo stato. Il framework quindi aggiorna lo schermo ridisegnando tutto o ridisegnando in modo intelligente parti del display. Vedi http://blog.getprismatic.com/om-sweet-om-high-functional-frontend-engineering-with-clojurescript-and-react/

Clojure usa il secondo paradigma che ho incontrato e cioè isolare i cambiamenti di stato ma non necessariamente limitarli al livello più alto. Con Clojure tutto lo stato mutabile deve essere "trattenuto" (a meno che non si utilizzino oggetti Java per stato) da un atomo, un agente o un riferimento. Il modo in cui funziona è l'oggetto trattenuto o puntato o referenziato (comunque tu voglia chiamarlo) dall'atomo / agente / ref è immutabile, ma l'atomo / agent / ref può cambiare per puntare a un nuovo oggetto. In questo caso usi metodi speciali sull'atomo / agente / ref che dicono "aggiorna qui l'oggetto facendo questo e così e riassegnando l'atomo / agente / ref a un nuovo oggetto".

Perché è utile chiedere questo? Perché l'oggetto immutabile a cui fanno riferimento questi costrutti di Clojure può essere passato a una funzione che fa qualcosa e mentre quella funzione sta eseguendo il suo riferimento all'oggetto è garantito che non cambierà. Cioè, l'atomo / agente / ref non viene passato alla funzione ma viene passato l'oggetto immutabile a cui punta. Atomi, agenti e ref hanno proprietà speciali che gestiscono aggiornamenti e concorrenza in modi sicuri e parte del linguaggio. Vedi http://clojure.org/state

Spero che questo possa essere d'aiuto. Suggerisco di leggere di più sullo stato di Clojure e FRP per comprendere meglio come dipendenti e persone possono essere rappresentati in FP. Tuttavia, la rappresentazione reale sarebbe simile alla programmazione orientata agli oggetti ... è la mutabilità che è davvero diversa.