It depends. Most compiled langs can be made performant enough, regardless of their paradigm. But you are correct that over-using certain parts of certain paradigms can certainly slow things down.
However, it's a difficult argument to be made against functional programming. Since the "recent" advancements in FP, from the last ~3 decades of bleeding edge research, has made FP incredibly fast. Haskell, the crown jewel of FP, is ridiculously fast. So much so that it is surprising to people who haven't used FP for a while. Since only a few decades ago - everyone knew that FP was very slow and inefficient.
The reason behind this sudden change, is clear. The papers written on this topic show a clear, strong, and impressive effort in making FP fast. They often lovingly call haskell "25 years of hard work" for papers like these, and it really shows. Incredibly passionate papers like these, demonstrating the strength of formal computer science in practice, is truly refreshing. The best part is that all of this is already implemented in GHC! And research is still ongoing towards greater horizons!
There's more examples of FP being fast other than Haskell (ex: Rust) but I think I've made my point. Moving on to debugging. I suppose it depends? The entire goal of FP is to make things easier to reason about by having formal and pure semantics. Most functions are functions in the same sense as mathematics. There's no tricks and traps. The goal of having "formal semantics" that is "clear to the programmer's eyes" is not unlike the goal of procedural programming. Both do a good job at having explicit semantics. But FP goes the extra way to make functions pure - which truly makes things easier to reason about.
But then, when it comes time to do some impure shenanigans - which is certainly necessary in any practical sense - It may get a bit hairy during debugging depending on what kind of code you write. I myself find it delightfully simple to find exactly what's wrong in my Haskell code compared to, say, my Java/Python/Typescript code. But I also know it is very easy to make non-pure Haskell code extremely difficult to debug (by using outdated concepts). But let's not forget that Haskell is a very extreme example. Many FP languages such as rust, the ML family, clojure actually make it just as easy to debug.
Procedural has the advantage of being foundationally simple with no tricks and traps, which I adore. There's a certain elegance in simplicity that I like. But FP also makes sure that its semantics, even the abstract ones, are explicit and clear - a steep contrast to OOP and its seed of inherent implicit mutability.
It depends. Most compiled langs can be made performant enough, regardless of their paradigm. But you are correct that over-using certain parts of certain paradigms can certainly slow things down.
However, it's a difficult argument to be made against functional programming. Since the "recent" advancements in FP, from the last ~3 decades of bleeding edge research, has made FP incredibly fast. Haskell, the crown jewel of FP, is ridiculously fast. So much so that it is surprising to people who haven't used FP for a while. Since only a few decades ago - everyone knew that FP was very slow and inefficient.
The reason behind this sudden change, is clear. The papers written on this topic show a clear, strong, and impressive effort in making FP fast. They often lovingly call haskell "25 years of hard work" for papers like these, and it really shows. Incredibly passionate papers like these, demonstrating the strength of formal computer science in practice, is truly refreshing. The best part is that all of this is already implemented in GHC! And research is still ongoing towards greater horizons!
There's more examples of FP being fast other than Haskell (ex: Rust) but I think I've made my point. Moving on to debugging. I suppose it depends? The entire goal of FP is to make things easier to reason about by having formal and pure semantics. Most functions are functions in the same sense as mathematics. There's no tricks and traps. The goal of having "formal semantics" that is "clear to the programmer's eyes" is not unlike the goal of procedural programming. Both do a good job at having explicit semantics. But FP goes the extra way to make functions pure - which truly makes things easier to reason about.
But then, when it comes time to do some impure shenanigans - which is certainly necessary in any practical sense - It may get a bit hairy during debugging depending on what kind of code you write. I myself find it delightfully simple to find exactly what's wrong in my Haskell code compared to, say, my Java/Python/Typescript code. But I also know it is very easy to make non-pure Haskell code extremely difficult to debug (by using outdated concepts). But let's not forget that Haskell is a very extreme example. Many FP languages such as rust, the ML family, clojure actually make it just as easy to debug.
Procedural has the advantage of being foundationally simple with no tricks and traps, which I adore. There's a certain elegance in simplicity that I like. But FP also makes sure that its semantics, even the abstract ones, are explicit and clear - a steep contrast to OOP and its seed of inherent implicit mutability.
This is insightful 👍😉 thanks 🙏❤