Апологеты функци-онального программирования объясняют это решение, в частности, тем,
что отказ от изменяемых данных резко повышает корректность программ
и делает их значительно более удобными для анализа с помощью фор-
мальных методов. Это действительно так, и в данной статье мы в этом убе-
димся. Однако полный отказ от изменяемых данных зачастую не оправ-
дан по следующим причинам:

1. Некоторые техники программирования, применяющиеся в функци-
ональных языках без присваиваний (к примеру, ленивые вычисле-
ния), применимы в более традиционных языках, таких как Java или
C++, лишь с огромным трудом.

2. Для некоторых алгоритмов и структур данных не известно или
не существует столь же эффективных аналогов без использования
присваиваний (к примеру, для хэш-таблиц и систем непересекаю-
щихся множеств).

3. Многие предметные области по своей сути содержат изменяемые
объекты (например, банковские счета; элементы систем в задачах
имитационного моделирования, и т. п.), и переформулировка зада-
чи на язык неизменяемых объектов может «извратить» задачу.

Исходя из пунктов 2 и 3 и из того что в haskell'e нет присваиваний (изменяемых состояний), делаю вывод что применимость haskell'я весьма ограничена и использовать его в качестве универсального ЯВУ будет весьма затруднительно. Написание исключительно на haskell'e какой-либо достаточно большой программы/системы вследствие указанных выше пунктов было бы крайне затруднено.

Почему?
Во-первых, в Хаскелле таки есть присваивание и мутабельное состояние, причём двух видов: функционально-чистое в монаде State (имитация мутабельного состояния) и императивно-грязное в монаде IO (ввод-вывод).

Кроме того, никто Вам не мешает взять и реализовать такой чиста императивный код на Сях и прилинковать к основной программе на Хаскелле...

If only Haskell programmers could take some time away from writing Fibonacci functions perhaps they could also build some kind of adequate compiler.

А есть на этих State/IO эффективная реализация hash table?

А эффективная реализация избитого уже quick sort?

If only Haskell programmers could take some time away from writing Fibonacci functions perhaps they could also build some kind of adequate compiler.

Стандартный модуль в GHC Data.HashTable.
Насколько эффективна эта реализация -- не могу сказать, не тестировал. Используйте Data.Map -- более идиоматично для Хаскелла

Или вот Galois в финансовой отрасли используют Хаскелл -- тоже не нарадуются, прям как наши оберонщики...

Ну, мне в принципе никто не мешает взять и реализовать весь проект на С++

Терехов формулирует это так: "Если для создания программного продукта требуется, чтобы предварительно год работал профессор математики, то это - наши задачи, задачи, которые должны решаться в России... И там знают, что в этом случае, когда ничего не получилось со своими, надо искать русских".

Или как обычно - хорошо можем делать только танки и ракеты, а автомобиль для людей - это слишком просто

Но японцы танки и ракеты не могут создать. Почему нет. Специализация. Причем тут "родина слонов".

Ну, мне в принципе никто не мешает взять и реализовать весь проект на С++

Если на С++ Вы быстрее получите качественный результат, то им и следует Вам пользоваться в этом случае...

Стандартный модуль в GHC Data.HashTable.
Насколько эффективна эта реализация -- не могу сказать, не тестировал. Используйте Data.Map -- более идиоматично для Хаскелла

Внешне правильный совет ("выбирать под задачу..") сформулирован крайне примитивно. Надо выбирать что-то не под быстрое получение качественного результата, а под получение качественных результатОВ на протяжении длительного времени.

Вот у меня и возникают сомнения что рассматриваемый инструмент (Haskell) рано или поздно не даст осечку и для достижения качественного результата не придется заниматься грязными хаками на уровне С.

... Оберон - "Си-Юникс 89-го года"