There is a very big difference between "too smart" and "too complicated". I think Haskell is dangerously close to the former category while C++ is firmly in the second. I appreciate "smart" for many tasks, but sometimes the operational semantics become important (e.g. it's performance-sensitive) and then you have to understand the stack at a pretty deep level and it can be awfully confusing why a tiny source-level change makes a big performance or space difference.

Sometimes I pretty much know what assembly I want and it's much easier to make a C compiler produce it than to get GHC to produce it.

I agree that it is hard to get GHC produce the assembly you want, but I think this is unfair to "blame" GHC for this. In my eyes Haskell is mostly a high-level language and if you worry about the assembler produced I think we have left high-level language territory and it might easier to just write C and use the FFI.

Tools that fit the task make it simpler. Otherwise, much of your attention is diverted to the tool itself, and not available for the actual task. This can be fun provided the task isn't pressing.

One example is multiplication in the complex roman numeral system vs. (our) simple arabic numeral system.

Another example is PHP (tool) for webapps (task). Worked for YouTube and CDBaby. -- Honestly, I think the concept of embedding commands in HTML is brilliantly simple, because the program is largely isomorphic to the result, making it intuitive to reason about. [disclaimer not a webapp developer]

"Another example is PHP (tool) for webapps (task). Worked for YouTube and CDBaby. -- Honestly, I think the concept of embedding commands in HTML is brilliantly simple, because the program is largely isomorphic to the result, making it intuitive to reason about. [disclaimer not a webapp developer]"

Simple until you have to come in and maintain it. There are many levels of simple. What is often simple for the original writer is horrible for the person who picks it up later on and has to extend and maintain it.