I think your procedural paradox is really a case of confirmation bias or ingrained familiarity. I remember way back in the dark ages (8 bit processors) and thinking about how unnatural defining the how not the what was a challenge. Now it seems very normal because I have been doing it for thirty years. But I don't think it has any natural or intuitive advantage.
Further more the 'how' can easily mask the why. And that is critical information. I cannot count the number of times I have asked, "What is the code supposed to do?" In procedural programming it is a vacuous tautology that the code is the documentation. The code is telling us what the program is doing in pain-staking, tedious detail. But it is usually not obvious what the code is supposed to be doing, or what the intention of the programer is.
Also, I think you missed one of the key aspects of Haskell, and Scala to a lesser degree. The type system. Programming to types and strong type inference in these languages make a whole category of bug impossible.
Fun article to read. Thanks
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.