After a rocky day 2 of Prolog, I’m back for a 3rd day in my Seven Languages in Seven Weeks series of blog posts.

## Prolog, Day 3: Thoughts

Today, I got to see Prolog flex its muscles. After just 2 days of using the language, we were already able to use it to solve two relatively complicated puzzles: Sudoku and eight queens. Even more impressively, the Prolog solutions were remarkably elegant and concise.

I had complained on the previous day that, for simple problems, the Prolog approach did not communicate its intent particularly well. Day 3 turns that completely around. For example, let’s check out the 4x4 Sudoku solver in the book. Here’s how you run it:

And here is the code:

Even if you don’t know Prolog, the code is so eminently declarative and
visual, that you can still get an idea of what’s going on. We break the 4x4
puzzle down into individual elements, rows, columns, and squares. After that,
we just apply some constraints to them: all elements must have a value between
1 and 4 (`fd_domain`

) and the values in each row, column, and square must be
different (`fd_all_different`

).

And that’s it.

A few lines of code and the Prolog compiler figures out values that satisfy these criteria to get you a solution. Although not an entirely even comparison, take a look at Sudoku solvers I found online in Ruby, Java, and C++. I’m sure each of these imperative solutions could be made prettier; perhaps they are faster; but none of them comes close to the declarative solution in terms of communicating the code’s intent.

## 6x6 Sudoku

Modify the Sudoku solver to work on six-by-six puzzles, where squares are 3x2. Also, make the solver print prettier solutions.

The code:

The output:

I took the easy way out on this problem, just extending the 4x4 solver to handle 6x6 puzzles with some copy and paste.

## 9x9 Sudoku

Modify the Sudoku solver to work on nine-by-nine puzzles.

The code:

The output:

With an even bigger puzzle, I finally decided to avoid copy and paste and build something more generic. The code above should be able to solve any NxN puzzle, where N is a perfect square (4x4, 9x9, 16x16, etc).

The approach is the same as before: ensure the values are all in the range 1..N, carve them into rows, columns, and squares, and check that no value in each row, column, or square repeats.

The bulk of the work is done by a rule called `slice`

:

The goal of `slice`

is to chop the `Puzzle`

into a list of `N`

sublists. Each
sublist represents a row, column, or square (depending on the variable `Type`

)
in `Puzzle`

. The `slice`

rule takes one element at a time from `Puzzle`

and
uses one of the `slice_position`

methods to put this element into the proper
spot in its sublist. For example, here is `slice_position`

for rows:

For each element `I`

of `Puzzle`

, we first figure out which row (sublist) it
lives in: `X = I // Size`

. The `//`

in prolog is a shortcut for integer
division. We then figure out where in that sublist the element belongs:
`Y = I mod Size`

. Pretty simple. Squares, however, are a lot more complicated:

To get the math right on this one, I got some help from Hristo. He even posted his reasoning on the Math StackExchange to see if anyone could come up with a formal proof for his formula. Once that piece was in place, the Sudoku solver was pumping out solutions to 9x9 puzzles in no time.

## Wrapping up Prolog

Prolog is a fascinating language. If you’ve done imperative programming your whole life, you really owe it to yourself to try it out. It’s a refreshingly different approach to problem solving that will definitely impact the way you think.

I found it particularly bizarre to be manipulating the *solution or output* to
some programming puzzle, even though the solution wasn’t yet known! Of course,
in Prolog, you’re not actually *manipulating *the solution, you’re merely
describing and defining it. Sometimes it was easy to invert my thinking this
way; at other times, it was brutally difficult, like trying to mentally
reverse the direction of the spinning girl
illusion.

Unfortunately, much like
Io
before it, Prolog suffers from the lack of an active online community. You can
find *some* information via Google and StackOverflow, but it’s often sparse
and incomplete. The documentation is a bit scattered, seems to be written in a
very academic language, and is often more confusing than helpful. Worst of
all, there are several flavors/dialects of Prolog and the code from one often
doesn’t work in another.

Having said all that, I have a suspicion that declarative programming is going
to grow in popularity in the future (10+ years). Being able to just tell the
computer *what* you want instead of *how* to get it could provide enormous
leverage for programmer productivity and creativity. Of course, I think we’ll
need a language more intuitive and expressive than Prolog, as well as a smart
enough compiler to understand it, but the declarative approach to coding seems
like a much bigger leap forward than, say, the whole object oriented vs.
functional programming debate.

## Onto the next chapter!

Changing gears one more time, head over to Scala, Day 1 to learn about a language that mixes OO and functional programming.

### Bryan Covell

If you enjoyed this post, you may also like my books,
*Hello, Startup* and
*Terraform: Up & Running*.
If you need help with DevOps or infrastructure, reach out to me at
Gruntwork.