Hi Jan,
Any chance you could encourage people in industry to give a webinar on their use of Prolog in commercial / enterprise settings. What they did and lessons learned.
I think that could be invaluable to have …
thanks,
Dan
Anne Ogborn is working on some of this. She pointed at a nice talk at StrangeLoop: “Production Prolog” by Michael Hendricks
2 Likes
I can’t know for sure but the way Prolog is introduced to people in universities might be part of the problem. As if the main goal is to convince aspiring software developers that Prolog can never be useful for “production software”. (I understand that this is conflating two separate things, Prolog the language and the implementation, but I don’t see how this can be easily avoided).
I see a lot of hope though. As it stands right now, SWI-Prolog has one of the best documentations I’ve seen, a great and modern “standard library” (the built-ins + the Packages), and the community is well-mannered. It is easy to report bugs (and you @jan help a lot with the reporting itself!) and they get actually fixed. If this keeps up, it can only get better in the foreseeable future.
One thing that in my opinion Python did exceedingly well and I don’t quite see for SWI-Prolog is their “Tutorial”. I have mentioned it in many conversations and no one seems to recognize it as a thing, but hear me out:
Let’s assume I am not a dunce (it starts with a joke!) and I have some previous experience with programming in general. Now I need to pick up Python because of reasons. I google Python, I find the tutorial on the official Python site, and 3 hours later I feel as if I can write decent Python.
With SWI-Prolog, I need to read the “Amzi inc. Adventure in Prolog” and wonder if I’m trippin’; then I have to read “Learn Prolog Now!” and wonder why the only “!” in the whole textbook is in the title; at this point I remember the time before the world wide web and go the the library. I have to read “The Art of Prolog” and go like “man, I wish I understood all this”, then I eventually start imagining I understand most of it and read “The Craft of Prolog” and go like “man, I wish I understood all this”, and so on. It is a great journey, but I never feel as if I can write decent Prolog.
EDIT: I know there are more online tutorial-style intros and even textbooks out there by now, but they only add to the problem.
This is somehow connected to the “multiple implementations” issue.
I admit that on two separate occasions (3 years apart) I thought that I have what it takes to write such a tutorial for SWI-Prolog, and it turned out I don’t.
Just some thoughts.
1 Like
I fully agree. On the other hand, you might be pointing at a solution. There is plenty of material out there on many subjects at many different levels. Maybe something as simple as a reading guide could improve the situation quite a lot. Possibly we can do that as a joined effort here (e.g., on the wiki channel). Steps to take:
- Find the links
- Characterize them (topic, level, maturity, audience, …)
- Assemble (a) reading path(s)
- Merge them? Involves copyright …
Of course, the Tutorials menu on the home page is already a start.
1 Like
Yes, definitely this would help. I started off by following links that were indeed available on the SWI-Prolog website back then, and just reading.
However, and this is a point that I really struggle bringing across so again, bear with me. Also, it goes without saying, I am making a lot of assumptions that I don’t want to or even cannot “prove” in any meaningful way. So…
I am not talking about achieving expertise. I am not talking about availability or discoverability of resources.
What I am talking about is putting a novice at ease. Giving them a feeling of “yeah, I get it, sure”. Because at that point you can confidently start coding, and as you code more and more, you learn things that cannot be explained.
Having one thing to read before you can confidently start writing code is a big part of this.
The reason why I failed miserably in putting together such a resource is, ironically, that I don’t at all think that I know a) what belongs there and b) what is the conventional way of doing things.
I hope I am making sense.
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.
Dan
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.
Dan
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).
https://swish.swi-prolog.org/p/Iteration2.swinb
https://swish.swi-prolog.org/p/Compiler1.swinb
https://swish.swi-prolog.org/p/Graphs1.swinb
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