[ Jocelyn Ireson-Paine's Home Page | Publications | Contact ]

Why Use Prolog?

Here are some notes I wrote in a reply to a colleague who asked me why I used Prolog to program the spreadsheet-manipulation program Model Master. I'll be pointing a few readers at them anyway, so why not make them public? Perhaps some readers will find them useful in justifying their choice of language and implementation.

To make sense of the comparisons, you need to know that I programmed the first version of MM in Java, for portability, and then switched to Kawa, so that I could keep the portability but ditch Java's verbosity and object-oriented excesses. After that, I changed again, to SWI-Prolog. You can see some of my SWI examples at The Watchmaker And The Spreadsheet Factory.

There are several reasons, some not having much to do with logic programming. The order is, roughly, that in which one approaches the essence of the language.

1) SWI-Prolog is free, open-source, and very well maintained. (Thanks Jan!)

2) It's much much easier to distribute SWI-Prolog applications than Java ones. For Java, you need to package the Java VM with your compiled code, using a special installer, or ask the user to do it themselves - Sun have funny restrictions on redistributing the Java VM. This is inconvenient, and the best installers are expensive. With SWI, by contrast, the compiler can easily generate stand-alone .exe files. Or, when one doesn't care about hiding the source code, you can just mail that.

3) Java applications tend to be very big, because of all the libraries that come with it. Java is a real gimme pig (Grunt, snuffle, oink, gimme another 100M of RAM). SWI isn't.

4) Prolog is much less verbose, and I find that terribly helpful when developing. The conciseness works for legibility, not against it, in the same way that Edward Tufte's principle of purging chart junk does for visual data. The essential information is in predicate and variable names, which can still be as long as you want.

5) Prolog allows one to define any word or collection of "symbol characters" (e.g. >>, +, /, , //, :===/===: ) as an infix, postfix, or prefix operator. This makes it relatively easy to approximate conventional mathematical notation in one's program, not just for numerical operations, but for matrix multiplication, vector addition, and so on. It also makes rapid prototyping of "little languages" - special notations developed for the end-user - easy, because you can make a first try at the syntax using your own operators, rather than having to write a special parser. The downside is that you have to make a few syntactic compromises, because you do have to follow the rules of Prolog syntax. But it is quicker than doing it all from scratch.

6) In Prolog, you can treat data as programs. You can read a Prolog expression from file and then execute it, or build it on the fly and then execute it. That flexibility can be very useful.

7) Prolog is interactive. It comes with a top-level interpreter: a command interface that you can type code at and get it executed immediately. In conjunction with the previous two points, this makes it very handy for rapid prototyping of command interfaces. And, although you might say "Well, I don't want a text interface, I want a GUI", there's no point building the latter until you have decided what you need to tell it to do.

8) In Java, and in most imperative languages - C, C++, Pascal, ... - there are problems with identity. If you define your own data structures to represent mathematical entities such as sets, matrices, vectors or whatever, then the imperative languages treat different copies of a structure as different entities. An equality test on a structure and its copy will fail, because they reside in different parts of store, and equality is by pointer. This is, philosophically speaking, ludicrous. You can't have different "copies" of a number: no matter how many times you write "1" on a piece of paper or carve it into a stone, all the marks refer to the same thing. The same should apply to other mathematical entities too, but in the imperative languages, it doesn't, unless you take a lot of bother. Prolog gets this much more right. Not completely right, but almost. This isn't just program aesthetics for its own sake. Having to worry about these pointers, when they point at the same thing and when not, introduces a level of coding complexity that Prolog spares you.

9) You can do functional programming in Prolog, by using a translator such as Grips. That's useful for me as a developer,and also - via point 7 - useful for the end-user of MM, because the functional style seems to be a good one when building spreadsheets out of pieces, or when chopping them into pieces.

10) In Prolog, you can write logical specifications of searches and get them executed without recoding into some more primitive language. For example, I can write:

     mortal(X) :- man(X)     % X is mortal if X is a man.
     man(socrates).          % Socrates is a man.

     ?- mortal(socrates).    % Is Socrates mortal?

The fact that Prolog is a logic programming language only comes in at point 10. The user of the current MM would notice Prolog at points 5, 6, 7, 9 and 10. Points 5, 6 and 7 were good for me as a rapid prototyper, but not particularly good for the user, because he's getting a less-than-custom interface. On the other hand, he's getting something now rather than this time next September. But, point 10 is extremely good for the user, if willing to learn a bit, because it makes the tool so flexible.