Jerf, thanks so much for sharing your thoughts. I think I agree with all your views. They are taken from the real experience of trying those approaches. And I am grateful that you provide the feedback. I and anyone tackling this steep mountain need all the help we can get.
I am sure that inspectability/debuggability are two of the big issues with such an approach. When things fail, the more magic there is, the more difficult it is to fix it. It's even difficult to understand what's happening!
I do think that there is a gap there. You can specify things and have the environment apply your spec. If it's totally naive, like Prolog's "slowsort", it will take exponential time and be impractical for real-world cases. But if strategies can be found and/or devised, and applied, which get some efficiency, it can be practical for many things. When things fall apart, it's clear that powerful debuggers will be needed. A lot of work will be needed on the tools, similar to SQL Query Strategy Inspectors, etc... maybe even professionals specializing just in this. But I think that it will finally allow us to write code in a sane way. Even if armies of professionals have to come after the fact to tweak it so that it's usable, the same as for SQL.
I totally understand what you see as adavantageous in Haskell. I think that same "it's turtles all the way down", where you can inspect and debug every step, is the reason that Haskell cannot gain the power that I am after. Prolog can't either, for other reasons.
I believe a fundamentally different approach is needed. And that's what I'm trying to sketch out.
And thanks to you and many other people hopefully we can learn whether there is something there or there isn't, and if there is, hopefully reach some useful result!
I am sure that inspectability/debuggability are two of the big issues with such an approach. When things fail, the more magic there is, the more difficult it is to fix it. It's even difficult to understand what's happening!
I do think that there is a gap there. You can specify things and have the environment apply your spec. If it's totally naive, like Prolog's "slowsort", it will take exponential time and be impractical for real-world cases. But if strategies can be found and/or devised, and applied, which get some efficiency, it can be practical for many things. When things fall apart, it's clear that powerful debuggers will be needed. A lot of work will be needed on the tools, similar to SQL Query Strategy Inspectors, etc... maybe even professionals specializing just in this. But I think that it will finally allow us to write code in a sane way. Even if armies of professionals have to come after the fact to tweak it so that it's usable, the same as for SQL.
I totally understand what you see as adavantageous in Haskell. I think that same "it's turtles all the way down", where you can inspect and debug every step, is the reason that Haskell cannot gain the power that I am after. Prolog can't either, for other reasons.
I believe a fundamentally different approach is needed. And that's what I'm trying to sketch out.
And thanks to you and many other people hopefully we can learn whether there is something there or there isn't, and if there is, hopefully reach some useful result!