Nelle domande precedenti mi è stato detto che i linguaggi di programmazione funzionale non sono adatti per sistemi dinamici come un motore fisico, principalmente perché è costoso modificare gli oggetti. Quanto è realistica questa affermazione e perché?
Sia Haskell che Clojure consentono la mutevolezza effettiva, quindi è un non-problema con cui iniziare.
Oltre a ciò, se i dati "mutabili" sono costituiti da valori intermedi che vengono aggiornati in modo incrementale come parte di un calcolo più grande, non è nemmeno necessario che la mutabilità sia efficiente! Ad esempio, in Haskell è in corso una ricerca su una tecnica chiamata stream fusion , in cui il compilatore fonde loop di elaborazione, produttori di dati e consumatori di dati per eliminare completamente le strutture di dati intermedie.
Il problema principale di Haskell qui è la pigrizia - in un programma di crunch numerico in cui hai molti dati di input e molti dati di output e tutto ciò è importante, la pigrizia ti fa pochissimi favori ma impone ancora un po ' spese generali. Questo non vuol dire che non si possano scrivere programmi come quelli in Haskell (la gente lo fa, in effetti) ma non sta giocando ai punti di forza della lingua e bisogna avere una migliore comprensione del modello di valutazione per ottenere le prestazioni che si desidera.
Detto questo, il pesante frantumare il numero non gioca ai punti di forza della JVM. Questo tipo di programma è il motivo per cui FORTRAN è ancora in circolazione.
Non posso parlare di Clojure, ma posso dire che Haskell ha a disposizione molti pacchetti di I / O molto ottimizzati che permetteranno tutte le mutazioni che potresti desiderare.
Ecco una risposta a una domanda che ho scritto dove qualcuno descrive i 3 più comuni e riguarda le loro prestazioni: link
Puoi anche vedere qui un semplice grafico che mostra le metriche di rendimento di un server web haskell chiamato Warp, che è un'applicazione altamente intensiva di IO.
C'è molta confusione riguardo a Haskell, la verità è che ha delle fantastiche strutture IO con molti pacchetti in hackage per usare IO in molti modi diversi, molti dei quali sono stati altamente sintonizzati. La ragione per cui la gente presume che non sia così è perché Haskell fa di tutto per separare IO da tutto il resto, ma ciò non ha alcun effetto sulle caratteristiche delle prestazioni.
Ora per parlare delle caratteristiche delle prestazioni, tuttavia, la ragione per cui le persone riconoscono che le loro prestazioni sono scadenti è dovuta alla pigra valutazione che lo fa comportarsi in modi che non sono sempre intuitivi. Questo è comunque qualcosa che devi preoccuparti di molto meno quando inizi a lavorare in un contesto IO facendo aggiornamenti distruttivi come in un sistema a cui ti stai riferendo. Inoltre, le persone tendono a scoprire che quando hanno problemi di prestazioni, le strutture incorporate per lo strumento e l'identificazione delle risorse disponibili aiutano molto.
Un'altra monade che vale la pena di cercare per un sistema come te descritto sarebbe monad ST che è specifico per gli aggiornamenti distruttivi fatti da piccolissime chiamate IO che gli danno grandi prestazioni.
Mi dispiace davvero non posso parlare con Clojure, spero che qualcun altro possa fornire dettagli lì.
Leggi altre domande sui tag immutability functional-programming haskell clojure