Hey,folks who are working with Prolog - what sort of work are you doing?
To be honest, it's not the most exciting system to be working on. It's basically using Prolog to encode business rules and perform calculations that you would sometimes expect to see in a spreadsheet (but then, there are parallels between logic programming and spreadsheets, e.g. see [1,2]). Prolog of course is a great language for that sort of use. On the other hand, I think the idea of turning Prolog into an object-oriented language is the worst idea of all times. I mean, when I quit my job in the industry to do a PhD, a big draw was that I could work with Prolog, but not OOP. And now I'm back in the industry working with an OOP Prolog. Resistance is futile.
The fun part is that the project I'm working on has been developed over 20 years by multiple people with very, ah, let's say varied opinions on the necessity of maintainability of old code. There are missing sources, old configurations that break compilation, no structured comments whatsoever, no version control (NO VERSION CONTROL!!! AAAAAH!!!), about 1/10th of the LOCs are commented-out for reasons unknown and unspecified in any comments, and so on, so forth.
So it's really cool to work with. I absolutely love digital archeology! :D
_________________
[1] https://www.j-paine.org/spreadsheet_structure_discovery.html
I remember the ads in Dr Dobbs!
Thanks for sharing.
As to OOP, I think I'm not alone when I say that I've seen the horrors that people create when given the freedom to instantiate their classes, and I will never unsee them. A great idea, but so was the Industrial Revolution, and now we have climate change.
For this purpose I used Golog (a very simple, and not very performant Prolog interpreter written in Go). We had already a lot of infrastructure code written in Go, so it would've been a big problem if we couldn't reuse it during migration.
I extended the interpreter in two major ways:
1. Marshalling of structs from Go to Prolog and back. 2. Made most of the meta-predicates parallizable.
The second was meant to be an essential improvement over existing testing framework because it struggled with deploying tests in a large distributed system, running them while allowing various communication patterns and collecting results. The system that was supposed to be tested in this way was a distributed parallel filesystem. The kind of tests I was hoping to leverage with my proposed framework were along the lines of: let multiple users perform various filesystem-related operations on the shared filesystem tree while connecting from different physical nodes and see if anything goes wrong.
The system worked enough for a demo, but was never approved for real use.