¿Haskell / Clojure es realmente inadecuado para sistemas dinámicos como la simulación de partículas?

Me han dicho en preguntas anteriores que los lenguajes de programación funcional no son adecuados para sistemas dinámicos como un motor de física, principalmente porque es costoso mutar objetos. ¿Cuán realista es esta afirmación y por qué?

Tanto Haskell como Clojure permiten la mutabilidad real, por lo que no es un problema para empezar.

Más allá de eso, si sus datos "mutables" consisten en valores intermedios que se actualizan de manera incremental como parte de un cálculo mayor, ¡es posible que ni siquiera necesite mutabilidad para ser eficiente! Por ejemplo, hay una investigación en curso en Haskell con respecto a una técnica llamada fusión de flujo , donde el compilador fusiona bucles de procesamiento, productores de datos y consumidores de datos para eliminar por completo las estructuras de datos intermedias.

El problema principal con Haskell aquí es la pereza: en un programa de cálculo de números en el que tiene muchos datos de entrada y muchos datos de salida y todo es importante, la pereza le hace muy pocos favores pero aún impone algunos gastos generales. Eso no quiere decir que no pueda escribir programas como ese en Haskell (de hecho, las personas lo hacen), pero no está jugando con las fortalezas del lenguaje y necesita comprender mejor el modelo de evaluación para obtener el rendimiento que desea.

Dicho esto, la gran cantidad de números tampoco juega con las fortalezas de la JVM. Ese tipo de programa es la razón por la que FORTRAN todavía existe.

No puedo hablar por Clojure, pero puedo decir que Haskell tiene muchos paquetes de E / S muy ajustados disponibles que permitirán toda la mutación que pueda desear.

Aquí hay una respuesta a una pregunta que escribí donde alguien detalla los 3 más comunes y considera su desempeño: /programming/15439966/when-why-use-an-mvar-over-a-tvar/15440286 # 15440286

También puede ver aquí un gráfico simple que muestra las métricas de rendimiento de un servidor web haskell llamado Warp, que es una aplicación altamente intensiva en E / S.

Hay mucha confusión sobre esto con respecto a Haskell, la verdad es que tiene fantásticas instalaciones de E / S con muchos paquetes de piratería para usar IO de muchas maneras diferentes, muchas de las cuales han sido muy optimizadas. La razón por la que la gente presume que este no es el caso es porque Haskell hace todo lo posible para separar la E / S de todo lo demás, pero eso no tiene ningún efecto en las características de rendimiento.

Ahora, para hablar sobre las características de rendimiento, sin embargo, la razón por la cual las personas reconocen que tiene un rendimiento bajo se debe a que la evaluación perezosa hace que se comporte de maneras que no siempre son intuitivas. Sin embargo, esto es algo de lo que debe preocuparse mucho menos cuando comienza a trabajar en un contexto de E / S que realiza actualizaciones destructivas, como en un sistema al que se refiere. Además, las personas tienden a descubrir que cuando tienen problemas de rendimiento, las instalaciones integradas para instrumentar e identificar hacia dónde van los recursos ayudan mucho.

Otra mónada que vale la pena buscar para un sistema como el que usted describe sería la mónada ST, que es específicamente para actualizaciones destructivas realizadas por llamadas IO muy pequeñas que le brindan un gran rendimiento.

Lo siento, realmente no puedo hablar con Clojure, espero que alguien más pueda dar detalles allí.