Haskell can actually make a pretty good imperative language (and you can put together little imperative sub-languages as well).  That aside...<p>There&#x27;s a reasonable perspective that says the type of problem that&#x27;s best solved in a language is a problem for which there&#x27;s good library support.  For that, I&#x27;d probably recommend scanning <a href="https:&#x2F;&#x2F;github.com&#x2F;Gabriel439&#x2F;post-rfc&#x2F;blob&#x2F;master&#x2F;sotu.md" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Gabriel439&#x2F;post-rfc&#x2F;blob&#x2F;master&#x2F;sotu.md</a><p>But in my experience, where Haskell really shines is sketching out operations on some type that I know I&#x27;m going to get wrong - substantially or subtly - my first many tries.  When I go to fix it, the compiler helps me find everything I need to change in tandem, and feel ahead to find inconsistencies in my model before I get there in the code.  One example of this kind of problem is compilers - where we parse into an AST, transform the AST, and then produce other things from the AST.  As development goes on, the AST evolves, and you have a lot of help knowing what needs to change to match and what you can ignore.  I&#x27;ve recently been doing this for SQL (though with the goal of analyzing the queries, not producing an executable).