Haskell / Clojure è davvero inadatto per sistemi dinamici come la simulazione di particelle?

In precedenti domande mi è stato detto che i linguaggi di programmazione funzionale non sono adatti per sistemi dinamici come un motore fisico, principalmente perché è costoso mutare oggetti. Quanto è realistica questa affermazione e perché?

Sia Haskell che Clojure consentono l'effettiva mutabilità, quindi non è un problema iniziare.

Inoltre, se i tuoi dati "mutabili" sono costituiti da valori intermedi che vengono aggiornati in modo incrementale come parte di un calcolo più ampio, potresti non aver nemmeno bisogno della mutabilità per essere efficiente! Ad esempio, è in corso una ricerca in Haskell 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 intermedi.

Il problema principale con Haskell qui è la pigrizia - in un programma di analisi dei numeri in cui hai molti dati di input e molti dati di output e tutto ciò è importante, la pigrizia ti fa ben pochi privilegi ma impone comunque un certo sovraccarico. Questo non vuol dire che non puoi scrivere programmi del genere in Haskell (la gente lo fa, in effetti) ma non sta giocando ai punti di forza del linguaggio e devi avere una migliore comprensione del modello di valutazione per ottenere le prestazioni che desideri.

Detto questo, il forte crunching dei numeri non gioca neanche ai punti di forza della JVM. Questo tipo di programma è il motivo per cui FORTRAN è ancora in circolazione.

Non posso parlare per Clojure, ma posso dire che Haskell ha molti pacchetti IO altamente ottimizzati disponibili che permetteranno tutte le mutazioni che potresti desiderare.

Ecco una risposta a una domanda che ho scritto in cui qualcuno descrive in dettaglio i 3 più comuni e riguarda le loro prestazioni: /programming/15439966/when-why-use-an-mvar-over-a-tvar/15440286 # 15440286

Puoi anche vedere qui un semplice grafico che mostra le metriche delle prestazioni di un server Web haskell chiamato Warp, che è un'applicazione ad alta intensità di I / O.

C'è molta confusione su questo riguardo a Haskell, la verità è che ha fantastiche strutture IO con molti pacchetti di hackage per usare IO in molti modi diversi, molti dei quali sono stati altamente sintonizzati. Il motivo per cui la gente presume che non sia così è perché Haskell fa di tutto per separare l'IO da tutto il resto, ma ciò non ha alcun effetto sulle caratteristiche prestazionali.

Ora, per parlare delle caratteristiche prestazionali, tuttavia, il motivo per cui le persone lo riconoscono come prestazioni scarse è dovuto alla valutazione pigra che le fa comportare in modi non sempre intuitivi. Questo è comunque qualcosa di cui devi preoccuparti molto meno quando inizi a lavorare in un contesto IO facendo aggiornamenti distruttivi come in un sistema a cui ti riferisci. Inoltre, le persone tendono a scoprire che quando hanno problemi di prestazioni, le strutture integrate per strumentare e identificare dove stanno andando le risorse aiutano molto.

Un'altra monade che vale la pena cercare un sistema come quello che descrivi sarebbe la monade ST, che è specificamente per gli aggiornamenti distruttivi effettuati da chiamate IO molto piccole che le danno grandi prestazioni.

Mi dispiace davvero non posso parlare con Clojure, spero che qualcun altro possa fornire dettagli lì.