Pensi che il linguaggio funzionale sia utile per le applicazioni che hanno un sacco di regole aziendali ma pochissimi calcoli?

Question

Sono convinto che la programmazione funzionale sia una scelta eccellente quando si tratta di applicazioni che richiedono molti calcoli (data mining, AI, nlp ecc.).

Ma è consigliabile utilizzare la programmazione funzionale per una tipica applicazione aziendale in cui esistono molte regole aziendali ma non molto in termini di calcolo?

Si prega di ignorare il fatto che ci sono pochissime persone che utilizzano la programmazione funzionale e che è un po 'dura.

Grazie

Answer 1

I linguaggi di programmazione funzionale come Clojure e Scala sono ideali per praticamente tutto. Per quanto riguarda Haskell, una programmazione Haskell esperta sarebbe probabilmente in grado di sostituire Haskell con qualsiasi linguaggio per qualsiasi problema - Efficiente o meno. Non so se esiste un linguaggio di programmazione funzionale che potrebbe essere considerato/migliore/fuori da tutte le lingue per questo specifico problema, ma ti assicuro che lo sarà e funziona molto bene.

Inoltre, Clojure e Scala sono implementati sulla JVM. Quindi tecnicamente sono/sono su una piattaforma aziendale.

Answer 2

Quali sono le regole aziendali se non funzionano? L'applicazione delle regole può essere espressa applicando una funzione a un insieme di dati. Può anche essere combinato con il polimorfismo. per esempio. attraverso funzioni generiche (anche la distribuzione multipla può essere utile) e l'ereditarietà.

Codice è dati, dati è codice e entrambi dovrebbero essere come l'acqua.

Answer 3

Presumo che quando parli di molte regole aziendali stai pensando allo sviluppo di applicazioni. Sviluppo di applicazioni nel senso che si desidera modellare un flusso di lavoro reale. A differenza della programmazione vaniglia, lo sviluppo di applicazioni comporta livelli più elevati di responsabilità (in particolare per l'acquisizione e il test dei requisiti). In tal caso, suggerisco caldamente di verificare se è possibile applicare lo sviluppo basato sul dominio. Una scelta naturale per lo sviluppo orientato al dominio è un approccio orientato agli oggetti. Questo e il fatto che molti programmatori sono decenti nella programmazione orientata agli oggetti è una delle ragioni della sua popolarità nello sviluppo di applicazioni. Tuttavia, questo non significa che i progetti reali su larga scala siano sempre scritti in questo modo (leggi http://www.paulgraham.com/avg.html).

Answer 4

Più di un anno fa ho approfondito un po 'in Haskell e ho anche provato alcune cose che considererei un tipico problema aziendale (per dirla senza mezzi termini, data una serie di valori, qual è la risposta corretta?). Quindi, direi, sì, dovresti essere in grado di modellare una serie di problemi di business con la programmazione funzionale.

Personalmente non ho trovato la stessa ovvietà in Haskell a cui posso spingere un approccio funzionale OO + come con C#, ma questo potrebbe essere perché non ho fatto molto con Haskell e molto altro con C#.

Poi c'è la cosa come comunicare con un cliente. La mia esperienza è che molti di loro pensano in termini strettamente cronologici, il che favorisce la programmazione imperativa. Anche andando in modelli di cambiamenti di stato ecc. Puoi perdere il cliente dispari. Pensare insieme a composizioni di funzioni e monadi che potrebbero rappresentare le operazioni cronologiche del business potrebbe probabilmente essere al di là di molti, molti clienti.

In entrambi i casi, è possibile trovare il mio business-esempio here.

Answer 5

Da quello che ho visto, Scala sembra che gestisca correttamente il normale Java.Quindi, tutto ciò che Java può gestire per il business, potrebbe farlo anche Scala.

Sul lato .NET, F # è un altro grande esempio di un linguaggio funzionale che funziona bene per le applicazioni "business". Per dirla semplicemente, F # può fare tutto ciò che C# può fare, e molto altro ancora.

Ma per entrambi questi linguaggi, la "programmazione nel lato grande" tende a prendere a prestito da OOP. Non che ci sia qualcosa di sbagliato nel mescolare le cose, ma forse questo non è quello che hai chiesto. Se si desidera attenersi a un approccio più funzionale e dire, non utilizzare gli oggetti, si potrebbe incorrere in un po 'più di fastidio perché il supporto degli strumenti non sarà sullo stesso livello. Con linguaggi che si integrano facilmente con .NET/Java, non è un grosso problema.

Per "è saggio?": Ciò dipende dal progetto, dall'azienda e da altri fattori ambientali. Sembra che un comune "modello di impresa" sia che il codice deve essere estremamente oscurato in modo che chiunque possa lavorarci su. In tal caso, potresti coinvolgere le persone che penserebbero che l'uso di una lambda lo rende troppo difficile da comprendere per gli altri.

Answer 6

È possibile controllare lo iTasks system che è una libreria per il linguaggio funzionale Pulisci ed è progettato esattamente per esprimere il flusso di lavoro e i processi aziendali.

Answer 7

Ma è consigliabile utilizzare la programmazione funzionale per una tipica applicazione aziendale in cui esistono molte regole aziendali ma non molto in termini di calcolo?

Le regole aziendali sono solo calcoli e spesso è possibile esprimerle in modo più sintetico e chiaro utilizzando la programmazione funzionale.

Un numero crescente di app aziendali è scritto in lingue funzionali. Citrix XenDesktop e XenServer sono basati su uno stack di strumenti scritto principalmente in OCaml. Il motore di ricerca di People MyLife è scritto in OCaml. Siamo una piccola azienda ma tutti i nostri software LOB (ad esempio transazioni con carte di credito, account, analisi web) sono scritti in F #. Gli annunci di Microsoft su Bing utilizzano il codice F #. Forse l'esempio più ovvio è chiunque utilizzi versioni recenti di C# e .NET perché utilizzano quasi certamente concetti funzionali (ad esempio delegati).

Se intendete linguaggi funzionali più esotici come Clojure, Scala e Haskell, allora credo che alcune persone li stiano usando ma io non ho nessun dettaglio io stesso.