Programmazione funzionale in aumento?

Ho notato di recente che i linguaggi di programmazione funzionale stanno guadagnando popolarità . Di recente ho visto come l' indice Tiobe mostra un aumento della loro popolarità rispetto allo scorso anno, anche se la maggior parte di loro non raggiunge nemmeno le prime 50 lingue più popolari secondo questo indice.

E questo è successo da un po 'di tempo. La programmazione funzionale semplicemente non è diventata così popolare come altri modelli (ovvero la programmazione orientata agli oggetti).

Ho visto un interesse rinato nel potere della programmazione funzionale, tuttavia, e ora che i multicore sono sempre più popolari, gli sviluppatori hanno iniziato a mostrare interesse per altri modelli di concorrenza già esplorati in passato da linguaggi come Haskell ed Erlang.

Vedo con grande interesse il fatto che nonostante la loro mancanza di significativa accettazione da parte della comunità, sempre più lingue di questo tipo continuano ad emergere. Clojure (2007), Scala (2003), F # (2002) sono solo tre esempi dell'ultimo decennio.

Anch'io ho investito un po 'di tempo ad imparare Haskell e Scala. E trovo un grande potenziale nel paradigma che per me era nuovo nonostante fosse là fuori da così tanto tempo.

E, naturalmente, la mia più grande domanda è se qualcuno di questi diventerà abbastanza popolare da prendere in considerazione la possibilità di sforzarli, ma questa è una domanda a cui nemmeno Mandrake potrebbe rispondere, nonostante tutto il clamore che la gente sta facendo su di loro.

Quello che voglio chiedere è:

• In quali scenari dovrei considerare un linguaggio di programmazione funzionale più adatto a svolgere un determinato compito? Oltre al recente problema multicore della programmazione parallela.
• Se decidessi di passare a un linguaggio di programmazione funzionale quale considereresti le più grandi insidie ​​che dovrei affrontare? (Oltre al cambio di paradigma e alla difficoltà di valutare le prestazioni a causa di una valutazione pigra).
• Con così tanti linguaggi di programmazione funzionale, come sceglieresti quello più adatto alle tue esigenze?

Eventuali raccomandazioni per ulteriori ricerche saranno più che benvenute.

Ho cercato sul web opinioni, e sembra che tutta questa rinnovata popolarità provenga dall'idea che ora stiamo per colpire il muro della Legge di Moore e che i linguaggi di programmazione funzionale verranno e ci salveranno eroicamente. Ma se fosse così, direi che ci sono più probabilità che le lingue popolari esistenti si adattino al paradigma.

Alcuni di voi, forse con più esperienza lavorativa ogni giorno con queste lingue, possono offrire maggiori informazioni sull'argomento. Tutte le tue opinioni saranno meglio apprezzate e attentamente considerate.

Grazie in anticipo!

In quali scenari dovrei considerare un linguaggio di programmazione funzionale più adatto a svolgere un determinato compito? Oltre al recente problema multicore della programmazione parallela.

Tutto ciò che comporta la creazione di una sequenza di elementi di dati derivati ​​mediante una serie di passaggi di trasformazione.

In sostanza, il "problema del foglio di calcolo". Sono disponibili alcuni dati iniziali e una serie di calcoli riga per riga da applicare a tali dati.

Le nostre applicazioni di produzione fanno una serie di riassunti statistici dei dati; questo è tutto meglio affrontato funzionalmente.

Una cosa comune che facciamo è una fusione tra tre insiemi di dati mostruosi. Simile a un join SQL, ma non così generalizzato. Questo è seguito da una serie di calcoli di dati derivati. Queste sono solo trasformazioni funzionali.

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

Ecco un esempio concreto di una 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]

Se decidessi di passare a un linguaggio di programmazione funzionale, quali ritieni siano le più grandi insidie ​​che dovrò affrontare? (Oltre al cambio di paradigma e alla difficoltà di valutare le prestazioni a causa di una valutazione pigra).

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 si tratti di un attributo mutevole di un oggetto è un'abitudine mentale difficile da spezzare.

Una funzione derivata da proprietà o metodo è un approccio migliore. Gli oggetti con stato sono un'abitudine difficile da rompere.

Con così tanti linguaggi di programmazione funzionale, come sceglieresti quello più adatto alle tue esigenze?

All'inizio non importa. Scegli qualsiasi lingua da imparare. Una volta che sai qualcosa, sei in grado di sceglierne un altro per soddisfare al meglio le tue esigenze.

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

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

Immutabilità

Ora che ne ho familiarità, ogni volta che riesco a ottenere un risultato immutabile, cerco sempre di farlo, anche in un programma orientato agli oggetti. È più facile ragionare sul programma se si hanno dati di tipo valore. Di solito è necessaria la mutabilità per cose come le GUI e i colli di bottiglia delle prestazioni. Le mie entità (usando NHibernate) sono anche mutabili (il che ha senso perché stanno modellando i dati memorizzati in un database).

Funziona come tipi di prima classe

Qualunque cosa tu voglia chiamarlo, passare delegati, azioni o funzioni, è un modo davvero utile per risolvere un'intera classe di problemi del mondo reale, come il "buco nel mezzo". Ho anche scoperto che passare un delegato, un'azione o una funzione a un oggetto è più pulito rispetto al fatto che quella classe dichiari un evento e l'aggancio di quell'evento (supponendo che di solito ci sia solo un "ascoltatore"). Quando sai che esiste un listener, l'azione di callback può essere passata come parametro del costruttore (ed essere memorizzata in un membro immutabile!)

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

Dovremmo anche notare la sintassi Lambda qui, perché ottieni la sintassi Lambda solo quando promuovi funzioni per 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 asyncflusso di lavoro, sono una monade. Questo è un costrutto sottile ma molto potente. È potente come la yieldparola chiave utilizzata per creare IEnumerableclassi in C #. In sostanza sta costruendo una macchina a stati per te sotto le coperte, ma la tua logica sembra lineare.

Valutazione e ricorsione pigri

Li ho messi insieme perché mentre sono sempre raggruppati come caratteristiche della programmazione funzionale, si sono fatti strada così rapidamente in linguaggi altrimenti imperativi che è difficile chiamarli più funzionali.

S-Espressioni

Immagino di non essere sicuro di dove inserirlo, ma la capacità di trattare il codice non compilato come un oggetto (e controllarlo / modificarlo), come Lisp S-Expressions o LINQ Expressions, è, in qualche modo, lo strumento più potente di programmazione funzionale. La maggior parte delle nuove interfacce "fluide" di .NET e le DSL utilizzano una combinazione di sintassi lambda ed espressioni LINQ per creare alcune API molto concise. Per non parlare di Linq2Sql / Linq2Nibernare dove il codice C # viene "magicamente" eseguito come SQL anziché come codice C #.

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

Se decidessi di passare a un linguaggio di programmazione funzionale, quali ritieni siano le più grandi insidie ​​che dovrò affrontare? (Oltre al cambio di paradigma e alla difficoltà di valutare le prestazioni a causa di una valutazione pigra).

La più grande trappola che ho dovuto affrontare è stata quella di trovare la linea di demarcazione tra soluzioni funzionali e soluzioni imperative. Tuttavia, dopo aver provato entrambi gli approcci un paio di volte, inizi a farti un'idea per quale funzionerà meglio.

Con così tanti linguaggi di programmazione funzionale, come sceglieresti quello più adatto alle tue esigenze?

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

E questo è successo da un po 'di tempo. La programmazione funzionale semplicemente non è diventata così popolare come altri modelli (ovvero programmazione orientata agli oggetti).

Questo è vero se si contano i programmi sviluppati da programmatori professionisti (o almeno le persone che si vedono come tali). Se allarghi la tua rete più ampia per includere programmi sviluppati da persone che non si considerano tali, FP (o almeno la programmazione in uno stile funzionale) è abbastanza vicino a OO (Excel, Mathematica, Matlab, R ... persino JavaScript "moderno" ).

In quali scenari dovrei considerare un linguaggio di programmazione funzionale più adatto a svolgere un determinato compito? Oltre al recente problema multicore della programmazione parallela.

La mia opinione personale è che il multicore non è la caratteristica killer di FP (almeno fino a quando i compilatori Haskell, Scala, Clojure, F # non risolvono il problema della localizzazione della cache). La caratteristica killer è map, filter, folde gli amici che consentono un'espressione più succinta di un folto gruppo di algoritmi. Ciò è aggravato dai linguaggi FP che hanno una sintassi più concisa rispetto alle controparti OO più popolari.

Inoltre FP essendo più vicino al modello relazionale riduce la discrepanza di impedenza con RDBMS ... che è - ancora una volta, almeno per i non programmatori - molto carina.

Anche quando si hanno particolari difficoltà a soddisfare i requisiti di "correttezza" - in una forma che è difficile da testare (comune nel calcolo scientifico / analisi di dati di grandi dimensioni in cui l'obiettivo è quello di ottenere in precedenza sconosciuti e come tali risultati non specificabili) FP può offrire vantaggi.

Se decidessi di passare a un linguaggio di programmazione funzionale, quali ritieni siano le più grandi insidie ​​che dovrò affrontare?

• mancanza di supporto per gli strumenti (F # e alcuni Lisps sono l'eccezione, Scala sta arrivando)
• più difficile spremere l'ultimo bit di prestazioni dal tuo hardware
• le comunità spesso si concentrano su problemi diversi rispetto a quelli affrontati da un folto gruppo di progetti di sviluppo di software commerciali
• pochissimi sviluppatori hanno esperienza nell'uso di FP in un ambiente industriale e se riesci a trovarli probabilmente devi competere con lo stipendio e i benefici che il settore finanziario può offrire
• lo stile funzionale della programmazione tende ad essere più difficile da eseguire il debug; cioè l'osservazione tra i risultati in una lunga catena di funzioni composte di solito non è possibile nella maggior parte (tutti?) debugger

Con così tanti linguaggi di programmazione funzionale, come sceglieresti quello più adatto alle tue esigenze?

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

• Di quanto controllo di basso livello hai bisogno sullo spazio e le prestazioni nel tempo della tua 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 del software?

Se decidessi di passare a un linguaggio di programmazione funzionale, quali ritieni siano le più grandi insidie ​​che dovrò affrontare? (Oltre al cambio di paradigma e alla difficoltà di valutare le prestazioni a causa di una valutazione pigra).

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

Preparati a colleghi scontrosi che non vogliono imparare nulla. Preparati a capi dai capelli a punta che impongono scelte linguistiche sbagliate "perché una volta erano programmatori". Preparati agli accademici pithy nei forum che ti patrocinano di monoidi. Preparati a infinite guerre linguistiche perché Scala non ha nemmeno l'eliminazione della coda e Clojure richiede davvero dei pedali per tutte le parentesi e non farmi iniziare su Erlang.

Se sei un programmatore web, la più grande trappola sarà probabilmente i tuoi capelli.

Con così tanti linguaggi di programmazione funzionale, come sceglieresti quello più adatto alle tue esigenze?

Vorrei iniziare con la piattaforma:

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

Per una prospettiva (dichiaratamente di parte) su questa domanda, puoi dare un'occhiata al blog di Bob Harper, Tipo esistenziale . Carnegie Mellon ha recentemente rielaborato il proprio curriculum CS per insegnare prima la programmazione funzionale, con altri paradigmi che sono stati insegnati solo dopo che è stata stabilita una solida base nella programmazione funzionale e Harper sta dando un colpo alla volta mentre il nuovo curriculum viene implementato nella pratica .

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

In quali scenari dovrei considerare un linguaggio di programmazione funzionale più adatto a svolgere un determinato compito? Oltre al recente problema multicore della programmazione parallela.

Non esiste una formula magica che ti dice quando usare la programmazione funzionale. Non è che la programmazione orientata agli oggetti sia adatta alle nostre attuali situazioni di programmazione. È solo un altro modo di strutturare i programmi in termini di un'altra serie di astrazioni.

Se decidessi di passare a un linguaggio di programmazione funzionale, quali ritieni siano le più grandi insidie ​​che dovrò affrontare? (Oltre al cambio di paradigma e alla difficoltà di valutare le prestazioni a causa di una valutazione pigra).

La programmazione funzionale non ha nulla a che fare con la pigrizia. ML e OCaml sono linguaggi funzionali e rigorosi. Il più grande ostacolo che dovrai affrontare è strutturare le cose in termini di valori immutabili e avvolgere la testa su qualunque astrazione venga utilizzata nel sistema dei tipi per gli effetti collaterali. I linguaggi funzionali sono più adatti all'ottimizzazione perché rendono gli effetti collaterali molto espliciti nel sistema dei tipi. Haskell usa monadi ma ci sono altri approcci all'uso degli effetti in linguaggi funzionali puri. Clean ha tipi di unicità e alcune altre lingue in sviluppo hanno altre cose.

Con così tanti linguaggi di programmazione funzionale, come sceglieresti quello più adatto alle tue esigenze?

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 renderli espliciti nel sistema dei tipi. Quindi, se hai intenzione di dedicare tempo all'apprendimento della programmazione funzionale, probabilmente Haskell è l'unico adatto 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 forse rinunciare alla frustrazione, dovresti andare con Haskell.

Vorrei attribuire l'attuale aumento di intere in 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 vi è dubbio che il calcolo parallelo sarà in aumento, poiché è chiaro che attualmente il ridimensionamento è molto più semplice ed economico rispetto al ridimensionamento. Anche sui mercati 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 c'è bisogno 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 devi assolutamente occuparti della parte più difficile.

Per quanto riguarda la riduzione della mappa, anche il nome deriva dalla programmazione funzionale (sia la mappatura che la riduzione sono operazioni tipiche nel paradigma funzionale). Entrambe le fasi di riduzione della mappa sono funzioni che funzionano in parallelo, accettano input, producono output e non hanno effetti collaterali. Quindi questa è esattamente la pura idea di programmazione funzionale.

Pochi esempi di FP usati per il parallelismo:

• CouchDB - basato su Erlang
• Chat di Facebook - basata su Erlang
• Twitter - gran parte costruita su Scala