The limits of the declarative approach

Can I ask- why is a purely declarative solution necessary for any problem? Is it so bad if a solution is 80% declartive, 60% declarative? That’s still “more declarative” than any imperative language, although I guess that’s a bit of a tautology.

The way I’ve learned things is that all Prolog code has both a declarative and an imperative reading and that one must keep both in mind simultaneously while coding to optimise the code’s efficiency. This doesn’t seem to be just my wild imagination. I help with correcting Prolog coursework at my university and we’re directed to give feedback to the students about things like tail-call optimisation, which very often means strategically placing a cut to avoid unnecessary backtracking and that in any case is a purely imperative consideration (it’s firmly in the “control” part of “logic + control”). Or, for example, using an accumulator rather than append/3 to buid-up a list because that makes for more efficient execution, even though declaratively the meaning is the same.

On a more personal note, I like Prolog’s pragmatism. It does sacrifice purity (logical or declarative) to make way for usability and efficiency. It is a real-world programming langauge that does not demand the programmer to twist herself into knots just to be able to perform ordinary tasks that are very simple to do in imperative languages (looking to you Haskell and your hare-brained puritan monads). So, yes, we have cuts and we have impure database writes and stream writes etc.But, this way, we have a language that is as close to the purely declarative paradigm as any general-purpose language has ever got. We cam program in something that looks very much like FOL. What else comes close?

So, to finally answer your question (sorry for the mini-rant) - I think that yes, we’ll always need to have an imperative component if we want to have a useable language, rather than a pretty toy.

4 Likes