Back when I was in college, there was considerable interest in Prolog and logic programming languages, but you scarcely hear about it at all anymore. I wonder why that is? I mean, I was never a huge fan, but in most respects it just never enters any modern discussion of programming languages.
It became SQL. Only sort of kidding.
Prolog is awesome, but in the end it’s really just a query language. At least, it only makes sense to me when I think of it as a query language and not a programming language proper.
I have this disease where every programming problem I encounter eventually cries out for a prolog-like logic programming solution. Problems that are hard to reason about imperatively often make more sense to me when described as entities and relations and rules, and interesting computations can be expressed simply if you have a backtracking expression solver. This usually comes up when I have a large set of entities and I want to do search-like operations or complicated rule evaluation.
And that’s the sort of situation where most people would turn to SQL, for a lot of the same reasons.
In those situation where I want to use logic programming, it always ends up embedded as a sub-language in the outer (inevitably imperative) language. I find SQL serves the same sort of function–you turn to it when you want to do complicated queries, but not to write the app itself.
Prolog is alive and well, sort of. It’s definitely still in use in the big bad world, albeit in small under-the-cover ways.
But the main reason why research on Prolog itself has stagnated is that logic programming researchers have the idea in their heads that logic programming is Prolog, and vice versa. You may or may not be shocked at the number of researchers in the 90s whose research agenda centred on understanding the nature of the Prolog cut. Lots of research dollars were, IMO, wasted on understanding an efficiency hack/misfeature when they should have been trying to eliminate it instead.
To understand the insanity of this, imagine where functional programming would be today if everyone doing the research thought that functional programming is MACLISP.
I’m biassed on this point, but I used to hack on Mercury, which was a serious attempt to make a real-world engineering language. I think it had some serious shortcomings, but it was on the right track.
Mercury had three main things going for it that Prolog did not: Strong types (a Hindley-Milner-esque polymorphic type system), strong modes (a way to declare the dataflow of a predicate) and strong determinism (no more unexpected failure, and it allows you to implement algorithms other than exponential backtracking search). Plus, of course, it had all of the stuff that you’d expect of a decent modern programming language, like a profiler and a module system.
The main thing which Mercury didn’t do right, IMO, is higher-order programming which, when you think about it, is one of the things that Hindley-Milner-esque type systems are supposed to give you. The problem was the mode system: when you have to specify the dataflow of a predicate, then that information has to be part of the higher-order argument. Expressing this elegantly is difficult. (Functional programming doesn’t, of course, have this problem because the dataflow is simple.)
But still, it wasn’t until we implemented it and worked with it that we found this out. At least we know what the next research hurdle is, and we have an idea about what Mercury’s successor should look like. (I suggested that it should be called “Deacon”, “May” or “Taylor”.)
Hi. I am getting back interested in Prolog-type languages after Haskell. I’m playing with Mercury right now! Anyway, have you heard anything along these lines lately? Also, would I be able to get in touch with the Mercury guy? Thanks alot for your blog posting!
Rich
rvnygord@yahoo.com