Вот наткнулся на такую вот статью:

Experience Report: Haskell in the “RealWorld”: Writing a Commercial Application in a Lazy Functional Language
http://www.starling-software.com/misc/icfp-2009-cjs.pdf

Статья в целом хвалебная, они очень довольны своим выбором языка.

We were lucky with our choice of Haskell and GHC and, in light of our experience, we would make the same choice again.

Но они при этом честно описывают проблемы, с которыми столкнулись (раздел 4, цитирую кусочки, которые мне показались весомыми, но лучше прочитайте раздел целиком, это полторы странички):
1. Language Issues

We found that to use many common Haskell structures, such as functors, monoids and monads, we needed to think in significantly different ways than we did in other languages, even other functional languages such as Scheme.

2. Refactoring

The main issue was that where, with a language such as Ruby, one can change a small handful of functions and leave the rest “broken” while testing the change, in Haskell one must fix every function in the module before even being able to compile.

3 Profiling Tools, and Deficiencies Thereof

One of the major problems, directly connected to lazy evaluation, is that where the work happens is quite a slippery concept.
One module may define and apply all of the functions for the work to be done, but in actuality leave only a few thunks in the heap: the real work of the computation occurs in some other place where the data are used.
It’s quite possible to have a final consumer of “work” actually doing all of the work that one wanted to have done in several other threads running on different cores.

A last note about a particular problem for us with GHC: profiling builds must run using the non-parallel runtime.

4 Lazy Evaluation and Space Leaks
там весь раздел придется цитировать в Standard Chartered они фактически убили ленивость, причем прямо в компиляторе.


Статья 2009 года, так что интересно, изменилось ли что-нибудь за последние 5 лет, как в инструментарии, так и в подходах. Особенно интересуют пункты 2-4. С проблемами рефакторинга в строгой системе типов я сталкивался и в С++: начинаешь менять тип — и нужно испрвить все и везде, пока оно просто скомпилируется. В этом смысле прототипировать на строгих языках очень неудобно — слишком много изменений нужно делать везде на каждый чих в системе типов, чтобы только удовлетворить компилятор — задолго до того, как перейдешь к собственно юнит-тестам, чтобы проверить свои изменения.

You will always get what you always got
  If you always do  what you always did