> I've encountered few C programmers who can predict what instructions will be emitted by their compiler.
That's an irrelevancy. Predicting those specific instructions does not preclude one from making reasonably correct judgements about a program's performance.
It is a fact that reasoning about performance of Haskell program is virtually impossible, unless you're an active ghc developer, and that's why the language remains unused for practical problems. Apart from buggy pandoc and few blockchain scams, that is.
That's simply not true. You can use the same tools used to reason about performance in time as we do for nearly every program. Predicting memory performance is harder due to optimizations and how untrained Haskell developers have a hard time spotting where there code is leaving unevaluated thunks on the heap. However the memory profiling tools are there and are great at catching them so in practice, as it is in C++ and many other languages, it's a pain but not a huge deal.
As for practical problems, I dunno. I work in Haskell full-time at a company that isn't doing block-chains. And I stream myself working in Haskell once a week on pretty practical things. I've made a couple of small games, a PostgreSQL logical replication client, have been learning different algorithms. All pretty practical to me.
That's an irrelevancy. Predicting those specific instructions does not preclude one from making reasonably correct judgements about a program's performance.
It is a fact that reasoning about performance of Haskell program is virtually impossible, unless you're an active ghc developer, and that's why the language remains unused for practical problems. Apart from buggy pandoc and few blockchain scams, that is.