Sto appena iniziando a imparare la programmazione funzionale (FP). Vengo da un mondo OOP, in cui tutto è un oggetto e la maggior parte di essi è mutevole. Ho difficoltà a comprendere il concetto che le funzioni non hanno effetti collaterali.
Se qualcosa non è mutabile, in che modo oggetti comuni come Employee o Person sono rappresentati in FP.
È possibile utilizzare FP per creare un'applicazione aziendale completa?
La domanda non è Può essere usato FP nell'Enterprise? ma Dovremmo usare FP nell'Enteprise?
Certo che puoi. Puoi sviluppare qualsiasi tipo di applicazione con qualsiasi tipo di linguaggio di programmazione, per questo sono chiamati "Turing complete".
Ora, alla domanda "Dovrebbe essere usato nell'Enterprise?" Dipende da te o dai tuoi datori di lavoro, FP può essere davvero utile in qualche tipo di applicazione, e infatti è usato parecchio: Haskell nel settore
Ora potresti chiedere "Allora, perché non viene usato di più?" principalmente perché altri linguaggi imperativi / OO sono più comuni e le aziende si rifiutano di passare a un linguaggio più "esotico" perché sono utilizzati in Java o C ++.
Ho iniziato a conoscere i linguaggi FP un paio di anni fa (Haskell, Scala, Scheme) e, anche se sono lontano dall'essere un esperto, ho scoperto che possono rendermi estremamente produttivo, per certi compiti più che C ++ o Java.
IMO, alcuni dei punti di forza dei linguaggi FP sono:
Fino ad ora, ho trovato il passaggio al paradigma FP abbastanza eccitante e non troppo difficile una volta trascorso abbastanza tempo su di esso. (Ma quanto tempo ho speso per imparare C o C ++? Molto!)
Quindi penso che da un punto di vista tecnico ha perfettamente senso sviluppare un'applicazione aziendale completa utilizzando 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 dalla FP fino a quando non avranno sufficienti prove del suo funzionamento effettivo, che ci sono abbastanza sviluppatori, strumenti, librerie e framework. Quindi è (molto) più difficile trovare un lavoro in cui si possa fare la programmazione FP full-time 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 scrivere software concorrente.
Inoltre, vi è la tendenza a introdurre alcune funzionalità FP in linguaggi mainstream e non funzionali come C #, C ++ in modo che i programmatori possano utilizzare alcuni FP senza la necessità di un completo switch di paradigmi. 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 , che dovresti creare un modello di dominio che rappresenti il problema che ti può aiutare a risolvere il tuo problema. Evans suggerisce di trovare un linguaggio di programmazione adatto al particolare problema in questione, ad es. egli menziona Fortran come un modo per risolvere problemi di natura matematica. O persino creando linguaggi specifici specifici per il 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 sottile shell in cima al livello del dominio.
Ora la cosa con l'applicazione enterprise è che questo tipo di applicazione (se è possibile generalizzare sulle applicazioni aziendali) spesso comporta la modifica dello stato delle entità di cui l'identità è importante e la persistenza delle entità modificate in un database. Questo tipo di problema molto generalizzato IMHO è risolto molto meglio utilizzando un modello orientato agli oggetti rispetto a un modello funzionale.
Questo non significa che ci siano aree di un'applicazione aziendale che non potrebbero essere risolte meglio con 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 utilizzando 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.
Modifica
A causa di alcuni upvotes, la mia attenzione è stata attirata 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 un set mentale completamente diverso.
Sì, può. Google un po 'e troverai software reale codificato in puro linguaggio funzionale.
Per quanto riguarda la tua domanda sugli oggetti di business, immagino che il tuo problema reale sia con l'immutabilità. In tal caso, considera che stai restituendo una nuova "Persona" ogni volta che dovresti mutarla se stavi usando una lingua imperativa.
Nota che questa tecnica può anche essere implementata usando linguaggi imperativi!
Le funzioni di programmazione (FP) come Object Oriented Programming (OOP) sono paradigmi. Rappresentano diversi modelli o approcci ai problemi di programmazione. Questi diversi approcci non eliminano la capacità di produrre software scalabile, gestibile ed estensibile. Questo non vuol dire che gli approcci siano equivalenti per tutti i tipi di problemi; non lo sono. Alcuni problemi si allineano meglio (o peggio) a particolari paradigmi, per 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 essere scritti e scritti bene.
Sì, FP può essere utilizzato nelle applicazioni aziendali. Clojure è un esempio di un linguaggio FP con successo nell'impresa: link
Rappresentare lo stato può essere una sfida in FP e cambiare i paradigmi per adattarli a FP può essere un po 'una distorsione mentale. Alcuni linguaggi FP non consentono completamente di disabilitare gli effetti collaterali e lo stato mutabile. Clojure consente entrambi ma scoraggia o isola questi paradigmi.
In breve, la rappresentazione dello stato potrebbe essere molto simile a OO. La modifica dello stato è molto diversa. Quindi, ad esempio, nello stato FP può essere rappresentato da liste e mappe. Un elenco di dipendenti può essere simile a:
[[name: "James Brown" address: "Barnwell, SC"]
[name: "Elvis Presley" address: "Tupelo, MS"]]
Ci sono due modi in cui so di gestire la modifica dello stato in FP. Uno è qualcosa di simile alla programmazione reattiva funzionale. In questo paradigma tutto lo stato viene gestito solo al massimo livello ... ad esempio, una vista HTML della tua applicazione ha uno stato nella vista (come il nome della persona, l'indirizzo, ecc.). Ora quando si fa clic su "Aggiorna nome" viene chiamata una funzione che gestisce ogni cosa relativa ad un aggiornamento del nome, tranne che in realtà cambia il nome. Può sembrare strano ... ma avere pazienza con me. Il nome modificato verrebbe quindi restituito dalla funzione e la vista (o l'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 se non lo è, ed eventualmente una nuova vista o un link 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 assegnato direttamente alla vista o qualunque cosa sia al livello alto. In alcuni casi, FRP prende tutto lo stato passa alla funzione e restituisce l'intero stato.
Con questo paradigma, il contenitore o il framework deve gestire l'aggiornamento della visualizzazione, del database o di qualsiasi altra cosa che richiede l'aggiornamento dal nuovo stato. Quindi puoi immaginare un quadro 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 aggiorna lo schermo ridisegnando tutto o rielaborando in modo intelligente le parti del display. Vedi link
Clojure utilizza il secondo paradigma che ho trovato e cioè quello di isolare i cambiamenti di stato ma non necessariamente li limita al massimo livello. Con Clojure tutto lo stato mutabile deve essere "tenuto" (a meno che tu non stia usando oggetti Java per lo stato) da un atomo, agente o riferimento. Il modo in cui funziona è l'oggetto trattenuto o puntato o referenziato (comunque lo si voglia chiamare) da atomo / agente / rif è immutabile, ma l'atomo / agente / riferimento può cambiare per puntare a un nuovo oggetto. In questo caso si usano metodi speciali sull'atomo / agente / ref che dicono "aggiorna l'oggetto qui eseguendo tale e così e riassegnando l'atomo / l'agente / il riferimento a un nuovo oggetto".
Perché è vantaggioso chiedere? Poiché l'oggetto immutabile referenziato da questi costrutti Clojure può essere passato a una funzione che fa qualcosa e mentre quella funzione sta eseguendo il suo riferimento all'oggetto è garantito che non cambi. Cioè, l'atomo / agente / rif non viene passato alla funzione ma l'oggetto immutabile a cui si riferisce viene passato. Atomi, agenti e ref hanno proprietà speciali che gestiscono aggiornamenti e concorrenza in modo sicuro e parte della lingua. Vedi link
Spero che questo aiuti. Suggerisco di leggere di più sullo stato di Clojure e su FRP per capire meglio come dipendenti e persone possono essere rappresentati in FP. Tuttavia, la rappresentazione effettiva sarebbe simile alla programmazione orientata agli oggetti ... è la mutabilità che è davvero diversa.
Leggi altre domande sui tag functional-programming