Or, maybe the language is very poorly designed. There are many programming languages. From Basic to LISP to C to Java to Haskell to ... Brainfuck. Some of them are used in the software industry and some are not. There are many claims about many languages: language x is good because [insert some random ramblings], language y is good because [...]
However, no language is adopted by the industry solely based on claims (and btw. I have seen some utterly ridiculous claims made by those who try to promote Haskell.) Every once in a while, some companies try out new languages.
Very few such languages get adopted and as you can see functional languages are almost completely absent from the industry. And there's a very good reason for it: they're simply not suitable for producing professional grade commercial software. If it had been otherwise, someone would have figured it out. The funny thing is that the start-ups that try to use them (usually founded by FP advocates themselves) also fail one after another. But some people never learn. Furthermore, many companies forbid the use of functional style or characteristics implemented in certain imperative languages. The code of good, proper lanaguages for general purpose software engineering, is almost self describing! What is unclear should be sorted out quite easily using the documentation.
Those "professionals who actually know what they are doing" don't seem to exist when it comes to functional languages. The evidence is the very fact there's not a single piece of important commercial software written in such a language.
The question is rather: can such specialists exist? Because I'm afraid they can't exist because the functional approach is fundamentally wrong.
Examples of ambiguity in FP?
What is the following line supposed to mean and what part of it suggest anything about that:
a b c
How is ~ an intuitive replacement for minus? How is (* 5 5) supposed to be as clear as 5 * 5 ?
ps. dynamic typing and type inference are two awfully bad things and either of them can lead to trouble in large programs