To go into another timeless paradigm, logical programming is famous for unexpected exponential execution times. It's rare that those get past tests, but it's something that developers are constantly having to fix (this or ensuring the type system detects determinism). SQL has a much milder version or this with underspecified joins.
Getting ride of time makes a lot of things easier, but is not trouble-free.
I have never heard of those famous "unexpected exponential times" in logic (not "logical") programming. Could you please give an example of what you mean?
I'm also not sure what you mean by "this or ensuring the type system detects determinism". What logic programming languages with a type system do you mean? Why would a type system be required to detect determinism?
Non-buggy performance follows different rules.
1. Interested in Haskell. Learn the language, read papers, enjoy the PL concepts and interesting academic work.
2. Does it scale? Implement small program in in C++ and Haskell. Optimize as best I can. Talk to people who work on ghc who happen to be in my lab. Further optimize. Everybody agrees, no further clear way to optimize the Haskell program.
C++ implementation remains several orders of magnitude faster.
If it were a time and space trade off, laziness would lead to good performance. But it doesn’t. It tends to produce stupendously bad cache behavior.
Haskell is a lovely platform for understanding some recent PL theory. It is possible to write the sort of obviously correct programs that make it so desirable.
It isn’t resource efficient. Worse, laziness means that performance tends to be chaotic. Small seemingly unrelated changes can change the execution order and change your profile a lot. Similar challenges exist in logical programming.
Of course I prefer writing in a functional style, because pure functions are just simpler. But all of computation can’t be reduced to just pure functions, which is why even Haskell has to call out to its runtime eventually.
All of computation provably can, but not everything computers do, despite the name, is computation.
This is also the same reason why I like SQL, it describes properties of the result set--if your thinking of it as procedural steps it's more difficult. When it comes down to performance tuning however, you do have to consider what really happens in terms of index choices, loop nesting, etc. I never got into FP problems large/complex enough to hit this point where I have to understand how FP sausages are made.