Prolog's Coding Horrors: Why Impure Constructs Break Logic Programs

A Prolog advocate catalogs the language features that quietly sabotage programs written in it. The core sin is reaching for impure, non-monotonic constructs like cut (!/0), if-then (->), var/1, assertz, and retract, which produce code that either reports wrong answers or silently loses valid solutions. Low-level arithmetic predicates such as is/2, =:=/2, and >/2 compound the problem by forcing learners to juggle declarative and operational semantics simultaneously, and by breaking the ability to run a predicate as a true relation under the most general query.

The canonical illustration is a factorial predicate. The textbook version with a cut returns only the base case when queried generally; removing the cut still throws an instantiation error because of is/2. Rewriting with CLP(FD) constraints (#>, #=) yields a clean relation that enumerates all N/F pairs correctly. The author also pushes back on side-effecting output baked into predicates: describe solutions as relations, let the toplevel print them, and reserve formatting for pure DCG nonterminals so tests stay tractable.

The underlying argument is that clinging to Prolog’s older imperative-flavored constructs forfeits the language’s actual value — generality, declarative debugging, and reasoning about programs as relations — for marginal performance or familiarity. Constraints, clean data structures, and meta-predicates like dif/2 and if_/3 are the path forward.