Il paradigma funzionale non è troppo divergente con l'hardware sottostante per essere generalmente efficiente?

C'è un'enorme incomprensione nell'immutabilità.

L'immutabilità è una caratteristica della semantica, ma non implica l'immutabilità nell'implementazione.

Un semplice esempio è l'implementazione della pigrizia.

Quando i calcoli sono pigri, il risultato di un'espressione è concettualmente un valore, ma l'implementazione sottostante è un thunk che contiene gli argomenti da valutare e una funzione per creare il valore, nonché uno slot per memorizzare il valore in .

La prima volta che chiederai (nella lingua) il valore, il calcolo verrà effettivamente eseguito, il suo risultato sarà valutato e il valore restituito a te (o a un handle).

Questo è trasparente nella semantica del linguaggio e tutto ciò che sai è che questa variabile è stata associata a un valore (o a un valore futuro) e che una volta eseguita non è possibile modificare il valore che verrà restituito. La rappresentazione della memoria sottostante cambierà, ma non ne saprai nulla.

La stessa differenza di implementazione / semantica esiste in qualsiasi linguaggio ed è in effetti al centro dell' ottimizzazione . Qualunque sia la lingua, la semantica garantisce alcune cose, ma lascia gli altri non specificati per lasciare spazio all'ottimizzazione.

Ora, è vero che le lingue praticamente funzionali non sono veloci come il C ++, per esempio. Tuttavia, Go (che è ancora abbastanza hype) è più lento di Haskell o Lisp, e lo stesso vale per C # Mono ( fonte ).

Quando vedi come C ++ o C inaffidabili possono darti quei risultati, potresti desiderare di lasciarti andare un po '.

Quando ti rendi conto che Haskell sta crescendo rapidamente oggi e c'è ancora molto spazio per l'ottimizzazione nel suo compilatore / runtime (GHC è appena passato di recente a LLVM, ad esempio, Microsoft Research sta finanziando i miglioramenti del runtime), potresti essere disposto scommettere che presto migliorerà.

Divertimento: A Play on Regular Expressions o come un team Haskell ha creato un matcher di espressioni regolari che sovraperforma re2 , la libreria C di Google, in una serie di scenari.

Il paradigma funzionale è utile per suddividere le cose in un ambito ristretto. Questa è davvero una buona cosa considerando come si evolve il computer.

Le CPU multicore hanno grossi problemi nel gestire le risorse condivise e i costi di sincronizzazione sono davvero elevati. Il paradigma funzionale consente un modo naturale di esprimere programmi che non hanno problemi. Questo è veramente buono per il parallelismo.

Inoltre, stiamo utilizzando server farm sempre di più con SaaS e cloud computing. Pertanto, la stessa applicazione deve essere eseguita su più macchine. In questa posizione, i costi di sincronizzazione sono ancora più costosi. Google ha fatto un po 'di lavoro e pubblicato alcuni documenti di ricerca sulla programmazione e sull'algoritmo delle funzioni che puoi scrivere. Questa è una cosa fondamentale per loro perché hanno un problema di sciabilità.

Inoltre, puoi facilmente fare una pila nell'heap del computer, e anche uno non continuo usando gli elenchi collegati. Questo è fatto per generare lo stack trace in molti linguaggi di programmazione. Quindi questo non è un problema.

OK, la programmazione funzionale implica alcune limitazioni. Ma offre anche un modo naturale per esprimere le problematiche che abbiamo nell'informatica moderna, che sono estremamente difficili da gestire nei paradigmi a cui sono abituati. La scalabilità è una di queste e sta diventando un vero affare.

Tutti quelli che hanno già a che fare con un sistema parallelo complesso sanno di cosa sto parlando.

Quindi vorrei sfumare la risposta. Sì, il funzionale ha un problema con l'hardware moderno, ma ne ha anche una semplice vecchia programmazione. Come sempre, troverai vantaggi e svantaggi. Il punto è sapere cosa sono in modo da poter fare la scelta giusta quando necessario.

Non ho davvero una risposta, dato che non conosco lo stato attuale o persino quanto sia difficile, ma solo perché il compilatore assicurerebbe quelle cose dall'input, non significa necessariamente che l'output li avrebbe In teoria, un compilatore sufficientemente intelligente potrebbe superare tutti questi problemi, ma in pratica probabilmente esisterà sempre.

Tuttavia, un altro modo di guardare è guardare la storia della macchina Lisp. Se ricordo bene, erano originariamente progettati per superare gli stessi problemi che Lisp aveva con la differenza dalle macchine in quel momento. Lo sviluppo di queste macchine alla fine si è interrotto, dato che il desktop è diventato abbastanza veloce da rendere meno efficaci le inefficienze con cui vivere, piuttosto che supportare un'altra macchina.

Generalmente, ad eccezione della maggior parte delle applicazioni critiche per le prestazioni, i linguaggi FP sono ancora abbastanza veloci. Scegli qualsiasi lingua di livello superiore, sarai disposto ad abbassare la priorità sul controllo fine e sulle prestazioni per una priorità più sicura, più facile, più gestibile o altre.

Fine alla fine, la programmazione si basa su trade off, quindi è sufficiente scegliere ciò che conta di più per il progetto a portata di mano.

È vero che il paradigma funzionale implica immutabilità e apolidia, ma non abbiamo alcun linguaggio di programmazione completamente puro. Anche il più puro, Haskell, consente effetti collaterali.

Detto questo, per rispondere alla tua domanda sull'efficienza, ho usato sia Haskell che Clojure e non ho notato alcun problema di prestazioni con nessuno dei due.