Prolog was designed to do ‘logic programming’. When I first used Prolog, back in the 1980s, I was initially overwhelmed by its expressive power. When using other (‘procedural’) programming languages, you had to find solutions to all your programming problems at the development stage and then hard-code those solutions into your program. With Prolog, on the other hand, you could ask your program questions at runtime and let it look for one or more possible solutions. Heady stuff. This (I thought) must surely be the way that all programs will be written one day.
 |
| You can try out Prolog online using Swish |
oop(smalltalk).
oop(ruby).
To find a list of all known OOP languages you would just enter this query:
oop(L).
In Prolog, when an identifier begins with capital letter, this indicates an ‘unbound’ variable which Prolog will try to match with known data. In this case, Prolog replies:
L = smalltalk
L = ruby
Now you can go on to define some rules. For example, let’s says that you want to write the rule that Reba only likes Languages that are OOP as long as Dolly does not like those languages. This is the Prolog rule:
likes(reba,Language) :-
oop(Language),
not(likes(dolly,Language)).
Let’s assume that the program also contains this rule:
likes(dolly, ruby).
You can now enter this query:
likes(reba, L).
The only language returned will be:
L = smalltalk
This is just the tip of the iceberg with Prolog. The language gets really interesting once you start defining enormously complex sets of rules, each of which depends on other rules. The essential idea is that each rule should define some logical proposition. When you write a rule, you can concentrate on a tiny fragment of what might eventually become an amazingly complex set of interdependent propositions. The programmer (in principle) doesn’t have to worry about the ultimate complexity. Instead, as long as each tiny individual rule works, you can rely on the fact that the vast logical network of which they will ultimately form a part will also work. Making sense of that complexity is Prolog’s problem, not the programmer’s.
In principle, Prolog seemed to offer the potential to do ‘real’ AI (programming) of great sophistication. Some people even believed that Prolog would provide the natural path to creating a truly ‘thinking machine’.
Well, years went by and Prolog failed to live up to its promise. Part of the problem was that, while it was great at finding numerous solutions to a problem, it wasn’t so good at finding just one. A nasty little thing called the ‘cut’ (the ! character) was used to stop Prolog searching when once a solution had been found. But the cut, in effect, breaks the logic and scars the beauty (and simplicity) of Prolog. Another problem was that Prolog interpreters were fairly slow. Prolog compilers were created to get around this limitation and Visual Prolog even introduced strict typing (which is not a part of standard Prolog). But in order to gain efficiency, the compiler sacrificed the metaprogramming (self-modifying) capabilities which many people consider fundamental to the language.
 |
| Visual Prolog has a good editor, a built-in debugger, design tools and compiler - but purists would say that it isn't 'real' Prolog. |
Still, it was, and is, an amazingly ambitious language that did lots of really interesting things. Unlike most of today’s ‘new and better’ programming language, it didn’t just recycle old ideas in slightly new ways. However, there was another programming language that was just as ambitious as Prolog but ultimately far more influential: Smalltalk. That will be the subject of my next post.
