Prolog Basics Through Pokémon: A Pragmatic Guide to Logic Programming

Most developers learn programming through imperative steps: do this, then this, then return. Prolog flips that model. You describe what’s true about your world, and the runtime figures out the rest by searching for proofs. That’s a hard sell when the examples are dry — family trees, ancestor relations, Socrates as a man. A post from unplannedobsolescence.com swaps the dry stuff out for Pokémon, and the paradigm suddenly clicks. We worked through it ourselves to see whether the metaphor holds up.

Why Pokémon makes Prolog click

The post starts with facts. In Prolog, a fact is a statement you assert to be true:

type(charmander, fire).
type(squirtle, water).
type(bulbasaur, grass).

That’s it. No variables to declare, no functions to define. You’ve populated a tiny knowledge base, and you can already query it. Ask ?- type(charmander, X). and Prolog binds X = fire and reports it back.

This is where the Pokémon framing earns its keep. A list of family-tree facts feels like rote memorization. A list of type assignments feels like a thing you actually want to reason about — because every player has, at some point, asked the same questions Prolog answers naturally: what beats water, which fire types evolve into something with two types, whether an evolution chain is valid.

Rules extend facts with logic:

strong_against(fire, grass).
strong_against(water, fire).
strong_against(grass, water).

effective(Attacker, Defender) :-
  type(Attacker, AType),
  type(Defender, DType),
  strong_against(AType, DType).

Read it backwards: effective(Attacker, Defender) is true if you can find an AType and a DType such that the attacker has that type, the defender has that type, and the first beats the second. Prolog doesn’t execute this top-down like a function call. It searches.

Unification and backtracking, demystified

Two mechanics carry the entire paradigm. The Pokémon example surfaces both without needing to name them academically.

Unification is pattern matching with variables that can flow in either direction. Query ?- effective(charmander, X). and Prolog looks at the rule, sees that Attacker = charmander, then tries to find a DType such that strong_against(fire, DType) holds. It binds DType = grass, then searches for any Pokémon with type(X, grass). It finds bulbasaur. Answer returned.

Now press semicolon — Prolog’s “give me another answer.” This is where backtracking shows up. Prolog reverses out of X = bulbasaur, checks if there are other grass types, finds none, and reports false. Add type(oddish, grass). and re-query. Prolog finds bulbasaur, then on semicolon finds oddish. You didn’t write a loop. There is no for keyword in your code. The search is the program.

Evolution chains push the example further. A fact like evolves(charmander, charmeleon). plus evolves(charmeleon, charizard). lets you write:

evolves_to(X, Y) :- evolves(X, Y).
evolves_to(X, Y) :- evolves(X, Z), evolves_to(Z, Y).

That’s a recursive rule. Two clauses, six tokens of logic, and you’ve defined transitive closure. Query ?- evolves_to(charmander, charizard). and Prolog proves it by finding charmeleon in the middle. Ask ?- evolves_to(charmander, X). and it lists every descendant in the chain. Write the imperative equivalent in JavaScript and you’re looking at twenty lines of graph traversal with a visited set.

Where this paradigm shows up today

Prolog itself is rarely the language you reach for in production. SWI-Prolog has a real community, IBM Watson used it for parts of Jeopardy, and constraint logic programming variants ship in real schedulers — but most developers won’t write Prolog at work. The reason to learn it is paradigm fluency.

Datalog, which is essentially restricted Prolog, runs inside several modern systems. Datomic uses it for queries. The Rust compiler uses Datalog (via the chalk crate) for trait resolution. Authorization engines like Oso and SpiceDB use logic-language cousins. When you see ?- syntax in a Rust borrow-check internals doc, you’ll know what’s happening.

The other place it surfaces is AI reasoning systems. Modern LLM agents are doing something Prolog programmers recognized fifty years ago: searching a space of possible proofs. Tools that wrap LLMs in structured reasoning loops are reinventing forward chaining and resolution under different names. Reading the Pokémon walkthrough won’t make you an expert in any of that, but it gives you a working intuition for the kind of computation involved.

Reading the post critically and what to do next

The post’s strength is pedagogy. It picks a domain where readers already have semantic intuition and uses that to carry the abstract concepts. The weakness — common to introductory Prolog material — is that it stops before the parts where Prolog gets weird. Cut (!), negation-as-failure, the difference between = and is, and the moment your innocent-looking rule causes an infinite loop are all left for later. That’s the right call for a beginner post. Just don’t mistake the clean parts for the whole language.

If you’re using an AI-assisted editor to learn the paradigm, the experience has improved noticeably. Autocomplete for Prolog now catches obvious unification mistakes and surfaces predicate signatures inline. Two years ago, Prolog support in mainstream editors was hit-or-miss.

Read the source post first. It’s short, and the examples carry their own weight. Then write your own knowledge base — not Pokémon. Pick a domain you know better than the author did: your music library, your team’s on-call rotation, the dependency graph of a project you maintain. The point isn’t to ship a Prolog program. The point is to feel what it’s like to describe a problem instead of solving it step by step. That feeling is what you take back to your day job.