I think the original quote is from O’Keefe “Prolog is different, but not that different.”
Those students used to procedural/imperative languages sometimes have a hard time getting started with prolog, because it is a bit different, more a database query language than a command. There’s some truth in this.
Be careful not to get too much used to prolog, though. At some point it ruins your skills in procedural/imperative languages. I noticed this recently. I fail in rather simple tasks, when I have to solve problems in R or so.
Funny. I’ve always considered learning Prolog adds something to my skills in imperative languages. Notably, rather than just doing the thing you want to do, create a data structure that describes properties of the domain and have generic routines using these. In other words: encode more in data and less in code.
Interesting point. My observation (N = 1, of course) may also be a bit special to R. In 90% of the use cases in R, one just wants something to get done, so there is an impulse to start writing before actually thinking about the problem.
I agree with the tittle. Most of any prolog program i’d write has one mode of use, and can be described as non-backtracking functions. Some functions are conditions that guide an if/else, and actually when it comes to fancy loops I often build those as iteration rather than recursion too.
And then there’s the other part of the program which is completely different in how you program from other languages.
The point about most of a Prolog program having a single mode of use and behaving like non-backtracking functions rings true, and it shows the gap is often narrower than the title suggests. On impulsive programming, I’d separate writing a rough draft from skipping design; the former is fine, but the latter is what actually causes trouble. On whether imperative practice erodes Prolog skill, it probably depends on whether you keep both active. Mostly the two paradigms competed for my habits rather than one erasing the other.