Исправление qnikst, (текущая версия) :
чтобы вернуть разговор в нормальное русло. В целом нужно смотреть на компромисы надо идти и какие проблемы вносит RTS haskell. Во-первых это Boxed типы их наличие дает возможность собирать их GC и делать отложенные вычисления, но разносит значения в памяти и добавляет пару тактов на их получение, в целом это не страшно учитывая анализатор строгости, и то, что реально многие переменные сделаются unboxed (unlifted) при этом компилятор их может удобно раскидать по регистрам, во-вторях это то, что целочисленные переменные хранятся в 32bit/64bit в зависимости от разрядности, несмотря на реальный размер, итого, чтобы сделать сжатый массив short-ов, нужно немного попрыгать, а иногда это важно, в-третьих это concurrency модель, которая позволяет дешево запускать кучу конкуретных тредов и спарков, но при этом вносит под вес в случае однопоточной программы в которой надо вычислять всё (я пока не знаю можно ли это преодолеть), в-четвертых это GC сильно ухудшающее жизнь, периодически всплывают статьи о region-based подходах типизированной мапяти, но пока полноценнго production ready подхода нет. Бонусы: возможности fusion (работа над массивами без фактического их создания), dph (только в GHC-HEAD) позволяющее распараллеливать мелкие операции, parallel-strategies - неявный параллелизм, удобные библиотеки типа vector-space. Соответственно писать численные методы можно только нужно сразу выделить для себя чем и за что придется платить и решить стоит ли оно того, вопрос неочевидный и сильно зависит от решаемой задачи.
Замечу, что все вышеперечисленное совершенно ортогонально проблемы мутабельности - иммутабельности, и это являлось причиной моего первого комментария тебе.
Исходная версия qnikst, :
чтобы вернуть разговор в нормальное русло. В целом нужно смотреть на компромисы надо идти и какие проблемы вносит RTS haskell. Во-первых это Boxed типы их наличие дает возможность собирать их GC и делать отложенные вычисления, но разносит значения в памяти и добавляет пару тактов на их получение, в целом это не страшно учитывая анализатор строгости, и то, что реально многие переменные сделаются unboxed (unlifted) при этом компилятор их может удобно раскидать по регистрам, во-вторях это то, что целочисленные переменные хранятся в 32bit/64bit в зависимости от разрядности, несмотря на реальный размер, итого, чтобы сделать сжатый массив short-ов, нужно немного попрыгать, а иногда это важно, в-третьих это concurrency модель, которая позволяет дешево запускать кучу конкуретных тредов и спарков, но при этом вносит под вес в случае однопоточной программы в которой надо вычислять всё (я пока не знаю можно ли это преодолеть), в-четвертых это GC сильно ухудшающее жизнь, периодически всплывают статьи о region-based подходах типизированной мапяти, но пока полноценнго production ready подхода нет. Бонусы: возможности fusion (работа над массивами без фактического их создания), dph (только в GHC-HEAD) позволяющее распараллеливать мелкие операции, parallel-strategies - неявный параллелизм, удобные библиотеки типа vector-space. Соответственно писать численные методы можно только нужно сразу выделить для себя чем и за что придется платить и решить стоит ли оно того, вопрос неочевидный и сильно зависит от решаемой задачи.