Programmazione funzionale in aumento?

In which scenarios should I consider a functional programming languages better suited to do a given task? Besides the so recently popular multicore problem of parallel programming.

Tutto ciò che comporta la creazione di una sequenza di elementi di dati derivati utilizzando un numero di passaggi di trasformazione.

In sostanza, il "problema del foglio di calcolo". Hai alcuni dati iniziali e set di calcoli riga per riga da applicare a quei dati.

Le nostre applicazioni di produzione eseguono una serie di riepiloghi statistici di dati; questo è il modo migliore per affrontarlo funzionalmente.

Una cosa comune che facciamo è un'unione-fusione tra tre mostruosi set di dati. Simile a un join SQL, ma non come generalizzato. Questo è seguito da una serie di calcoli di dati derivati. Si tratta solo di trasformazioni funzionali.

L'applicazione è scritta in Python, ma è scritta in uno stile funzionale usando le funzioni del generatore e le tuple con nome immutabile. È una composizione di funzioni di livello inferiore.

Ecco un esempio concreto di composizione funzionale.

for line in ( l.split(":") for l in ( l.strip() for l in someFile ) ):
    print line[0], line[3]

Questo è un modo in cui la programmazione funzionale influenza linguaggi come Python.

A volte questo genere di cose viene scritto come:

cleaned = ( l.strip() for l in someFile )
split = ( l.split(":") for l in cleaned )
for line in split:
     print line[0], line[3]

If I decided to switch to a functional programming language which do you consider are the biggest pitfalls that I will face? (Besides the paradigm change and the difficulty to evaluate performance due to lazy evaluation).

Gli oggetti immutabili sono l'ostacolo più difficile.

Spesso finirai per calcolare i valori che creano nuovi oggetti invece di aggiornare gli oggetti esistenti. L'idea che sia un attributo mutevole di un oggetto è un'abitudine mentale difficile da spezzare.

Una funzione derivata o una funzione del metodo è un approccio migliore. Oggetti statici sono una dura abitudine da rompere.

With so many functional programming languages out there, how would you choose the one the better suit your needs?

All'inizio non ha importanza. Scegli qualsiasi lingua per imparare. Una volta che sai qualcosa, sei in grado di prenderne un altro per soddisfare meglio le tue esigenze.

Ho letto su Haskell solo per capire le cose che manca a Python.

"Funzionale" è un insieme di funzionalità diverse, ognuna delle quali è indipendentemente utile, e trovo più utile guardarle singolarmente.

Immutabilità

Ora che mi è familiare, ogni volta che riesco a farla franca restituendo un risultato immutabile, cerco sempre di farlo anche in un programma orientato agli oggetti. È più semplice ragionare sul programma se si dispone di dati di tipo valore. Di solito è necessaria la mutabilità per cose come le GUI e i colli di bottiglia delle prestazioni. Anche le mie entità (che utilizzano NHibernate) sono mutabili (il che ha senso perché stanno modellando i dati memorizzati in un database).

Funziona come un tipo di prima classe

Qualunque cosa tu voglia chiamare, passare attorno a delegati, azioni o funzioni, è un modo davvero pratico per risolvere un'intera classe di problemi del mondo reale, come il "buco nel modello centrale". Ho anche scoperto che passare un delegato, un'azione o una funzione a un oggetto è più pulito di quello che la classe dichiara un evento e l'aggancio di quell'evento (supponendo che normalmente ci sia solo un "ascoltatore"). Quando sai che c'è un ascoltatore, l'azione di callback può essere passata come parametro costruttore (e memorizzata in un membro immutabile!)

Essere in grado di comporre funzioni (ad esempio trasformare Action<T> in appena un Action è anche abbastanza utile in alcuni scenari.

Dovremmo anche notare la sintassi Lambda qui, perché si ottiene solo la sintassi Lambda quando si promuovono le funzioni in tipi di prima classe. La sintassi Lambda può essere molto espressiva e concisa.

Monadi

Certo, questo è il mio punto debole, ma la mia comprensione è che i flussi di lavoro computazionali in F #, come il flusso di lavoro async , è una monade. Questo è un costrutto sottile ma molto potente. È potente quanto la parola chiave yield utilizzata per creare classi IEnumerable in C #. Essenzialmente sta costruendo una macchina a stati per te sotto le coperte, ma la tua logica sembra lineare.

Valutazione Lazy & Ricorsione

Li ho messi insieme perché, mentre sono sempre concentrati come funzionalità di programmazione funzionale, si sono fatti strada così velocemente in linguaggi altrimenti imperativi che è difficile chiamarli più funzionali.

S-espressioni

Suppongo di non essere sicuro di dove metterlo, ma la possibilità di trattare il codice non compilato come un oggetto (e controllarlo / modificarlo), come Lisp S-Expressions o LINQ Expressions, è, in alcuni modi, lo strumento più potente della programmazione funzionale. La maggior parte delle nuove interfacce "fluenti" .NET e DSL utilizzano una combinazione di sintassi lambda e LINQ Expressions per creare alcune API molto concise. Per non parlare di Linq2Sql / Linq2Nhibernate in cui il codice C # è "magicamente" eseguito come SQL anziché come codice C #.

Questa è stata la lunga risposta alla prima parte della tua domanda ... ora ...

If I decided to switch to a functional programming language which do you consider are the biggest pitfalls that I will face? (Besides the paradigm change and the difficulty to evaluate performance due to lazy evaluation).

Il più grande trabocchetto che ho dovuto affrontare è stato cercare di trovare la linea tra l'uso di soluzioni funzionali e soluzioni imperative. Tuttavia, dopo aver provato entrambi gli approcci un paio di volte, si inizia a capire quale funzionerà meglio.

With so many functional programming languages out there, how would you choose the one the better suit your needs?

Se hai familiarità con .NET, consiglio vivamente F #. D'altra parte, se hai familiarità con la JVM, c'è sempre Clojure . Se sei più accademico che pratico, andrei con Common Lisp o Scheme. Se conosci già Python, credo che ci siano molti costrutti funzionali già disponibili lì.

And this has been the case for quite some time. Functional programming simply has not become as popular as other models (i.e object oriented programming).

Questo è vero se conti i programmi sviluppati da programmatori professionisti (o almeno persone che si vedono come tali). Se diffondi la tua rete più ampia includendo programmi sviluppati da persone che non si considerano tali, FP (o almeno la programmazione in uno stile funzionale) è molto vicino a OO (Excel, Mathematica, Matlab, R ... anche "moderno" JavaScript ).

In which scenarios should I consider a functional programming languages better suited to do a given task? Besides the so recently popular multicore problem of parallel programming.

La mia opinione personale è che multicore non è la caratteristica killer di FP (almeno fino a quando i compilatori di Haskell, Scala, Clojure, F # risolvono il problema della localizzazione della cache). La funzione killer è map , filter , fold e amici che consentono un'espressione più succinta di un grande gruppo di algoritmi. Questo è aggravato dai linguaggi FP con una sintassi più concisa rispetto alla maggior parte delle controparti OO più popolari.

Inoltre, FP essendo più vicino al modello relazionale riduce il disadattamento di impedenza con RDBMS ... che è - di nuovo almeno per i non programmatori - molto bello.

Anche quando è particolarmente difficile soddisfare i requisiti di 'correttezza' - in una forma che è difficile da testare (comune nel calcolo scientifico / analisi di grandi dati dove l'obiettivo è quello di ottenere risultati precedentemente non conosciuti e in quanto tali non specificabili) FP può offrire vantaggi.

If I decided to switch to a functional programming language which do you consider are the biggest pitfalls that I will face?

• mancanza di supporto per gli strumenti (F # e alcuni Lisps sono l'eccezione, Scala in arrivo)
• più difficile da spremere l'ultimo bit di prestazioni dal tuo hardware
• comunità che si concentrano spesso su questioni diverse da quelle affrontate da un ampio gruppo di progetti di sviluppo di software commerciale
• pochissimi sviluppatori esperti nell'uso FP in un ambiente industriale e se riesci a trovarli probabilmente devi competere con lo stipendio e i benefici che l'industria finanziaria può offrire
• lo stile funzionale della programmazione tende ad essere più difficile da eseguire in fase di debug; Ad esempio, osservare i risultati di una lunga catena di funzioni composte non è generalmente possibile nella maggior parte dei (tutti?) debugger

With so many functional programming languages out there, how would you choose the one the better suit your needs?

• Quanti dei tuoi problemi possono essere risolti aprendo già librerie / framework su quale piattaforma (ad es. JVM o .Net) quanti sono nuovi di zecca? Esistono costrutti linguistici in grado di esprimere direttamente questi problemi?

• Quanto è necessario un controllo di basso livello sulle prestazioni dello spazio e del tempo dell'applicazione?

• Quanto sono severi i tuoi requisiti di "correttezza"?

• Puoi permetterti di riqualificare gli sviluppatori e / o competere con i vantaggi offerti da alcune nicchie altamente redditizie nello sviluppo di SW?

If I decided to switch to a functional programming language which do you consider are the biggest pitfalls that I will face? (Besides the paradigm change and the difficulty to evaluate performance due to lazy evaluation).

Supponendo che tu sia uno sviluppatore C ++ / C # / Java nell'industria ...

Sii preparato per i colleghi scontrosi che non vogliono imparare nulla. Preparati per i boss dai capelli a punta che impongono cattive scelte linguistiche "perché erano un programmatore una volta". Siate pronti per gli studiosi concisi sui forum che vi patronizzano sui monoidi. Preparati a infinite guerre linguistiche perché Scala non ha nemmeno un'eliminazione di coda e Clojure richiede davvero pedali per tutte le parentesi e non mi fa iniziare su Erlang.

Se sei un programmatore web, probabilmente il più grande trabocchetto saranno i tuoi capelli.

With so many functional programming languages out there, how would you choose the one the better suit your needs?

Vorrei iniziare con la piattaforma:

• OCaml è ottimo su Linux e terribile su Windows.
• F # è eccezionale su Windows e terribile su Linux.
• Scala e Clojure sono fantastici su JVM.

Per una prospettiva (esplicitamente parziale) su questa domanda, potresti controllare il blog di Bob Harper, Tipo esistenziale . Carnegie Mellon ha recentemente rielaborato il proprio curriculum CS per insegnare la programmazione funzionale in primo luogo, con altri paradigmi che vengono insegnati solo una volta stabilita una solida base nella programmazione funzionale, e Harper sta dando un colpo di grazia mentre il nuovo programma di studi viene implementato nella pratica .

Harper è uno dei principali sviluppatori del linguaggio di programmazione Standard ML, quindi è giusto dire che la sua opinione sulla questione può essere indovinata in anticipo, e di certo non esita da dichiarazioni controverse nel sostenere questa posizione, ma fa bene il suo caso.

In which scenarios should I consider a functional programming languages better suited to do a given task? Besides the so recently popular multicore problem of parallel programming.

Non esiste una formula magica che ti indichi quando utilizzare la programmazione funzionale. Non è come se la programmazione orientata agli oggetti fosse più adatta alle nostre attuali situazioni di programmazione. È solo un altro modo di strutturare i programmi in termini di un altro insieme di astrazioni.

If I decided to switch to a functional programming language which do you consider are the biggest pitfalls that I will face? (Besides the paradigm change and the difficulty to evaluate performance due to lazy evaluation).

La programmazione funzionale non ha nulla a che fare con la pigrizia. ML e OCaml sono lingue funzionali e rigorose. Il più grande ostacolo che dovrai affrontare è strutturare le cose in termini di valori immutabili e avvolgere la tua mente attorno a qualsiasi astrazione utilizzata nel sistema di tipi per effetti collaterali. I linguaggi funzionali sono più adatti per l'ottimizzazione a causa del fatto che rendono gli effetti collaterali molto espliciti nel sistema di tipi. Haskell usa le monadi ma ci sono altri modi per usare gli effetti nei linguaggi funzionali puri. Clean ha tipi di unicità e altri linguaggi in sviluppo hanno altre cose.

With so many functional programming languages out there, how would you choose the one the better suit your needs?

Tra i linguaggi di programmazione di cui sono a conoscenza, direi che solo Haskell e Clean possono essere chiamati linguaggi funzionali. Tutti gli altri consentono effetti collaterali senza rendere espliciti quegli effetti nel sistema di tipi. Quindi, se hai intenzione di dedicare del tempo all'apprendimento della programmazione funzionale, Haskell è probabilmente l'unico che si adatta al conto. Tutti gli altri che conosco, Erlang, Scala, Clojure, ecc. Forniscono solo astrazioni funzionali oltre a un linguaggio imperativo. Quindi se vuoi avvicinarti al paradigma funzionale in bit allora consiglierei Scala o Erlang e se vuoi affrontare tutto in una volta e magari rinunciare alla frustrazione, allora dovresti andare con Haskell.

Attribuirei l'attuale aumento di interes nei linguaggi funzionali al fatto che sono ideali per il calcolo parallelo. Ad esempio, l'intera idea di riduzione della mappa si basa sul paradigma funzionale. E non c'è dubbio che il calcolo parallelo sarà in aumento, in quanto è chiaro che attualmente la scalabilità è molto più semplice ed economica, piuttosto che scalabile. Anche nel mercato consumer le CPU ottengono più core, non più GHz.

EDIT: poiché non è ovvio per tutti.

Nella pura programmazione funzionale una funzione prende input, produce output e non ha effetti collaterali. Non avendo alcun effetto collaterale, significa che non ha uno stato condiviso, quindi non necessita di meccanismi di sincronizzazione, che altrimenti sarebbero necessari durante l'esecuzione simultanea. La sincronizzazione è la parte più difficile di qualsiasi software concorrente / parallelo, quindi è puramente funzionale, in pratica non è necessario affrontare la parte più difficile.

Come per map-reduce, anche il nome deriva dalla programmazione funzionale (sia la mappatura che la riduzione sono operazioni tipiche nel paradigma funzionale). Entrambi i passaggi di map-reduce sono funzioni, che funzionano in parallelo, prendono input, producono output e non hanno alcun effetto collaterale. Quindi questa è esattamente la pura idea di programmazione funzionale.

Pochi esempi di FP usati per il parallelismo:

• CouchDB - build su Erlang
• chat di Facebook - costruire su Erlang
• Twitter - gran parte costruita su Scala