Encouraging industry about Prolog

Because no argument is good without an irrelevant personal anecdote:

At my current job, we do use Python for some stuff. We also have (and have had) a couple of “junior” developers. None of them had touched Python before, and I tell them, “yeah, just read the Tutorial” (note the capital T there). Some read it, some don’t. Those who did read it started putting out useful code in a couple of days.

In a hypothetical situation where you replace Python with Prolog, what do I tell them? I honestly don’t know. And this is vexing me greatly, because SWI-Prolog is a better tool than Python for about 2/3 of the cases in which we currently use Python.

EDIT: now that 3 more years are gone, I could re-visit my incomplete work and see how I feel about it now. Don’t hold your breath. I have two other things that are very high priority at the moment. Maybe, if I can show something and say “this is what I meant” it would be much easier to judge whether it is a good idea at all.

1 Like

When I learned Prolog (in the glory days before the 2nd AI winter), I read various tutorials and just didn’t “get it”. Then one day, the sun shone, and it all made sense. I wonder how typical my experience is? (It probably helps to have not learned a conventional programming language; and it’s not clear whether knowing SQL helps or hinders.) One suggestion: “make” is like Prolog without any arguments, and people don’t seem to have trouble understanding how “make” works, even with alternative rules.

[My only other “ah-ha” moment with programming was when I took a logic course, which contained my ways of proving Gödel’s Incompleteness Theorem (plus all the set theory that leads up to it). One day, I understood and felt enlightened … but the feeling faded after an hour or so.]

Going faaar off topic now (do I start a new thread?), but anyway:

Whenever I’ve had the “I got it!” feeling, some time later it turns out I didn’t really get it. This is not a bad attempt at a joke, I promise.

On the other hand, the feeling that you can take a tool and understand it just enough to do something useful with it: this is a feeling I actively seek. Because experience has taught me that the only way to get better at most things is to keep on doing them.

It might be just my own personal view, but I have come to realize that the younger generations when learning tend to desire instant feedback, e.g. (SWISH with notebooks), or watching a video (YouTube).

Also another part is that when I went to university in the 1980’s, textbooks were about the only real way to get information and your choices were very limited to either the campus bookstore or the university library. So that is what we learned, tend to stay with, and try and pass on to and expect of others.

When I deal with the younger generation I have come to learn that if I embrace how they think and work and work with it as opposed to against it, we are much more productive and amicable toward learning about the ethos of each other.

Another significant change over the years for learning I see some people embrace is research papers, Amazon Books and sites that put you in direct contact with subject matter experts, e.g. (this site for SWI-Prolog), StackExchange and others; just like some read it, some don’t.

That is pretty much similar to my story. I took it in a university class in the 1980’s and finished the class still in mass confusion; never really understood the code I wrote, and it worked more out of lucky hacking than intuitive design. The one important idea I did learn and take with me from the class was that Prolog (Logic Programming) was one of the most useful programming languages; if only I knew how to use it. So over the years I would touch base with it and never really get it. Also during those few decades I never ran into a single sole who knew Prolog other than those who took it with me in class.

So I then decided to learn Prolog by using it on a real world problem, solving differential symbolic calculus problems, and with the help of others at StackOverflow started to understand Prolog. Still don’t know all of Prolog but feel confident enough with Prolog that now I can tackle those parts on my own when needed, e.g. constraints, tabling, ontologies.

Now that I know Prolog I came to realize the main problem I had in the class; I never really understood unification. As we know if you don’t understand unification, and unification being the foundation of logic programming, the rest is a house of cards.

If it wasn’t for people at universities fighting for keeping logic programming in the curricula and keeping logic programming research alive, is quite likely that Prolog would be long dead. Having been there, teaching logic programming for a decade, I lived and witnessed the struggle, in my university and elsewhere, to prevent logic programming from fading into memory of past days. Notably in Europe, where the normalization of undergraduate and master degrees translated to cuts in the number of years (required for the degrees) and consequent cuts to the subjects considered essential. At the other side of the Atlantic, there were several attempts to drop logic programming from official recommendations of Computer Science curricula. In these and other cases, academic people have been in the frontend fighting the good fight. Last, but not the least, let’s not confuse university purpose and goals in the pursue of knowledge with industry wants. Think about that when claiming that universities are “doing it wrong”.

“, e.g. (SWISH with notebooks), or watching a video (YouTube).” (from Eric’s post).

I think it would be a great idea to collectively put together the insights into an accessible tutorial. Also, I would strongly suggest to do this on swish and not in text only – a living tutorial!

And, if there are skilled amongst us to create youtube tutorials to walk through the swish tutorials, so its can also be taken in as a lecture.

I personally, learn best these days by listening to lectures, and seeing and trying out examples – in particular when i know what i am looking for to understand – based on what i am working on.

Hence tutorial shouldn’t be toy problems but examples readily usable in projects.


I had the great pleasure to have an intensive email exchange with Markus Triska early last year – who opened my eyes on relational thinking.

Before this discussion, i just programmed away – essentially a procedural program written in Prolog syntax.

Due to the email discussions with him, and his insistence of pushing me further, I eventually realized what relational programming is, why the use of cuts, assert i had made wasn’t the way to go – and revamped my code – and then managed to elegantly solve some key problems I had in mind in my application.

I think this should be reflected in new tutorials as well.

Hi Jan,

Michaels talk is really nice.

It would be good if he could have expanded further on how the novel capabilities of prolog were put to use, such as running predicates in all directions (he gave one example).

I think if we can encourage others, who used swi-prolog in production, to give an experience report as well, this could provide further encouragement to others to jump in and make use of Prolog.


The particular reason I noted SWISH with notebooks is because after many failed attempts of trying to incorporate custom HTML, SVG and iframes into the Discourse Wiki pages that seems the better way to go.

So when I get back out of my current rut with PostScript I hope to expand creating tutorials with SWISH starting at the basic levels and working up, e.g. move the wiki pages over to SWISH notebooks. Also I would like to expand the types of cells available for use with tutorials and training based on examples I have used in a classroom at this site.

To add to my thoughts.

Researchers among us (including me) could be quite willing to interview practitioners, and write (and perhaps even publish) the experience report for them – as part of a study on how swi-prolog is used in production.

If published in a publication read by industry as well, perhaps this could raise further interest.

Apparently, prolog programs are often much shorter than imperative programs – which should translate into significant enough cost savings as well, providing a commercial justification as well.

Hello Paulo,

my comment was indeed too general, and my personal experience is very specific. I apologize to all educators who read my message. I know I have this terrible character trait where I say things that sound like “you are doing it wrong” even though it is obvious that I could never do it any better.

The lack of an official tutorial echoes very much my own frustration with learning Prolog, and I’ve tried to do my bit my putting up three tutorials on Swish (which taught me a lot, though I’m not sure if anyone else found them useful).




When Udacity, Coursera and Edx first launched (and their courses were free), I did just about all of them and found the best courses were the ones where you submitted assignments for grading by a test suite. This was an eye opener for me on the power of test driven development since the really well designed courses made it easy to get 50%, but turned getting 100% into a tough game since figuring out all the corner cases was very tricky.

A great thing about the early Udacity courses, which standardised on Python, was the assignments were not just little standalone exercises, but built to a larger goal. Instead of just teaching coding basics, the first course was “write your own search engine”, followed by “write your own browser”.

In my mind, this kind of interactive education is truly revolutionary. Unfortunately, the more recent MooCs I’ve done were expensive and pretty much old school learning jargon by rote to pass “proctored” multiple choice exams.

I don’t enjoy video lecturers much. There is a Prolog course on Youtube at https://www.youtube.com/watch?v=vcQD2iPOc6Q&list=PLWPirh4EWFpFLjsd3IUqymnCVBaz1Yagg, which I stopped watching when the lecturer tried to illustrate the difference between imperative vs declarative programing by labouriously going through the steps to make a cup of tea.

When I first started programming in the commercial world, the shops (a group of programmers at a company) as they were called, tended to use just one programming language (C, COBOL, Fortran, assembly) and using any other programming language was taboo. Then as the Internet arrived many started to diversify in the programming languages they used because you typically had to use HTML and SQL and then others but even then and to a good extend now, logic programming and purely functional programming was not picked up.

To chime in on your comment, I do agree that in order to make head way with getting industry to make more use of logic programming, be it Prolog, LogTalk, or something else, that you have to address specific use cases. In other words if someone comes to me and tries to convince me that one programming language is the answer to all of your programming needs, they will not get much of my attention, but if they point out that any programming language are not great at every thing but here are some specific use cases that this paradigm (logic programming) will make an impact, then they will get my attention.

Another way to get logic programming into industry is by the back door. The other day a logic programming question popped up on StackOverflow but it was used as a subset of an app, and the logic was used selection rules. However I hate to say it that it is not getting answers and I even commented on possibly why. (Maybe I should take the time to learn Garret logic rules and answer the question). If logic programming is added to open source popular projects for certain use-cases and gets into the project, then industry will be using logic programming whether they know it or not.

One use case that I find in very few other programming languages, and while not specific to logic programming languages, is almost exclusive to them and has the easiest syntax to use is DCGs. But it is not the use of DCGs specifically that I find of value, but the use of DCGs for lexing and parsing. I have written lexers and parsers in many different programming languages and with different apps/tools/generators, and as I have noted here before, using DCGs for lexing and parsing is by far the nicest way to go. Now while many in industry may want a faster parser than DCGs, there is nothing that says the prototype for the lexer parser can not be done with DCGs, then once the grammar is stable and found to be deterministic, it can then easily be converted to something like lex/yacc or Bison or something. Don’t think about using logic programming for just the final product but as a prototype language, which is another use case where it excels.

Corner cases are tricky at first, but if you learn combinatorics then they become much easier. However then you run into combinatorial explosion of test cases and then have another problem of limiting the number of test cases.

However, since computers are so fast now, that if the run time for a complete set of auto-generated uses case (DCGs as generators helps a lot here) is reasonable (a few seconds can run millions of test at times), I just generate and run the full set; where is it written in stone that test cases have to be coded by hand and that there has to be only a few hundred. If you start doing it this way sometimes you spend more time hemming and hawing over what test to write when in the same time you could have in a few lines generated and test all of the test cases. In other words the use of auto-generated use cases is reaching a tipping point where it is faster to let the computer create and run the test rather than hand code the test.

In one application I did millions of computer generated test cases and it found some problems I would have never imagined by hand coding the test cases. The hard part about those test cases were that part of the code was recursive with a base case, so auto generating all test cases was out as it would have been an infinite set. I have found that when dealing with recursive code (loops) always test at least three repetitions through the loop to catch problems with passing values back into the recursion, e.g. state variables.

See: Auto-generating tests
NB Auto-generating test cases is experimentally supported through the library library(test_wizard) .

1 Like

Perhaps, Cojure is a good example (https://clojure.org/).

It’s essentially Lisp “modernized” and made available for the JVM ecosystem. It seems to have gained its followers.

Perhaps some tight integration with one of the large ecosystems could help as well – Java perhaps, but tighter than the current a bridge – some kind of tight / binary interoperability, so one could seamlessly work in both environments – and java developers could easily gain access to the prolog paradigm.

I guess this would mean many kinds of deterministic calls (when using java in prolog) – but, some could be non-deterministic as well.

Perhaps Logtalk is a better fit for that … given its object-oriented flavor.




IMHO using a language that needs tail-call optimization and uses the JVM is to be done knowing that not all JVMs are created equal and doing tail-call optimization is not required. The problem is well noted and easy to find.

Is (re)writing prologs “VM” to run on / with a JVM the only solution for binary interoperability ?

Could Jini be something to consider … (trading off portability to some extent?)

Just to clarify. .NET or more specifically the Microsoft CIL has the tail call opcode. I still don’t see a tail-call opcode in the JVM. This is not implying that a VM needs the tail-call opcode (goto is another possible means) but it does make it nicer for code analysis; when you see the tail-call opcode, you know what you get, when you see a goto, what does it mean?

The point is that when the JVM is used with code that should make use of tail-call optimization, you have to look more closely under the hood to make sure you are getting what you seek, while with other technologies it is standard; in other words just because tail-call optimization is something that is known and standard in many areas does not mean it is should be assumed to be there. :slightly_smiling_face:

Sorry if what I wrote was interpreted that way. Yes a trampoline and a goto are different, I was just pointing out that sometimes in the complication of the code, in some cases a goto is used where other VMs have more specialized op-codes.