Prolog, and Constraint Programming especially are great to have in your toolbox. I’ve done research in the field for years, and my job in the industry today is writing Prolog. There are real issues with Prolog:
- no proper module nor package system in the modern sense.
- in large code bases extra-logical constructs (like cuts) are unavoidable and turn Prolog code into an untenable mess. SWI prolog has single-sided unification guards which tackle this to a degree.
- lack of static and strong types makes it harder to write robust code. At least some strong typing would have been nice. See Mercury as an example of this.
All being said, Prolog is amazing, has a place in the future of programming, and gives you a level-up understanding of programming when you get how the types in every OO program is a Prolog program itself.
I'd advise to not use Prolog as general-purpose programming language, but as an embedded DSL or as a service for the part it's really suited for (if your app involves exploration and search over a large combinatorical space in the first place, such as in discrete optimization in industry, logistics, and finance). You really don't need yet another package manager and pointless premature modularization for modelling your business domains in optimization.
I've tried casually to take this approach and what I've found is that basically none of the Prologs out there are really designed to be properly embeddable. Even Scryer Prolog, written in Rust, isn't really set up to linked into a Rust program and run this way. I was able to "sort-of" make it happen, but it wasn't a workflow that had been optimized for.
To be clear what I'd like is to be able to fire up a thread hosting a Prolog runtime and stick predicates into it and query it using an API in the host language's syntax. Instead the best I could do was munge strings together and parse result out, sort-of. And that was after a bunch of time spent trying to reverse-engineer Scryer's API.
I would love to embed a Prolog to host my application's business rules and knowledge. I could see it super useful in a game even (think of the myriad of crazy rules and interactions and special cases in a game like Dwarf Fortress...)
Yeah the preferred approach would be to run a Prolog engine as a service and access it via usual JSON-over-HTTP/REST protocols. Has the benefit of being able to adapt and scale/provision the specific Prolog engine load as well. For smaller projects I guess you could use Minikanren which is specifically for embedding as I understand it, but even standard job shop scheduling and factory/office resource planning tasks would be better served with a Prolog (micro-/whatever) service already IMO.
The domain-specific Prolog code bases you're going to create still can become large and represent a significant development effort. Prolog being an ISO standard with many conformant (or at least mostly conformant) implementations available and relatively strong mindshare and ecosystem compared to extremely niche "CP solver packages and OR-tools" (which one exactly?) significantly reduces project risks such as not being able to find experts, the system not meeting functional or performance requirements, or becoming obsolete down the road. The same cannot be said for some mythical "CP solver packages and OR-tools"; you've nowhere to go if your "CP solver packages and OR-tools" project fails. Optimization and scheduling/planning projects, by their nature, are somewhat experimental and need exploration. It would thus be very difficult to pick "CP solver packages and OR-tools" upfront.
> extremely niche "CP solver packages and OR-tools" (which one exactly?) significantly reduces project risks such as not being able to find experts, the system not meeting functional or performance requirements, or becoming obsolete down the road. The same cannot be said for some mythical "CP solver packages and OR-tools"
"Mythical CP solver packages and OR-tools"? Lol!
Google's OR-Tools [1] has been winning golds in the MiniZinc Challenge since 2013 [2]. In 2023 it won Gold in most categories and the only Prolog to win, SICStus Prolog, took one Silver back. I'm curious where you're spending time in the community if you can word a comment like this as OR-Tools is the behemoth in this area and Prolog is the weird hacker siren call that appeals to people who certainly aren't about to publish anything novel in the space.
I say this as someone who has tinkered a lot with Prolog over the years and finds Prolog's execution model to work really well with the way I think about programming. Prolog and its hybrid solver model just isn't good enough at any one thing to make it SOTA. It's fun to tinker with, but I just don't think in 2024 it has enough to offer anyone who's not interested in the language or the WAM to make it worth exploring, especially not as an embedded constraint solver.
Ok but is the argument now just because it's by Google with its media presence it's not niche? "Constraint solving" is an overly broad term that can encompass most of computer science but at least finite domain solving, interval propagation, and SAT solving as specific algorithmic approaches with very different applications. Going by your post, potential users looking for planning, scheduling, or optimization problems to solve will jump to very specific implementation techniques having won synthetic benchmarks in basically unrelated domains for showcasing "something with constraints". Classic OR is about optimizing systems of linear (in-)equations, but discrete optimization problems and most financial investment planning problems don't come in this flavor and really need very laborious encodings (like into equational systems with 1000s of artificial variables) to fit OR model formulation requirements or SAT checkers. Great, now you're prematurely solving idiosyncratic representation problems; your consultants surely will rub their hands. But I stand by my opinion that Prolog is, by far, a much better starting point for the kind of explorative programming required in this domain. Making Prolog fast/scaling on mainstream cloud hardware (like Quantum Prolog and SICStus are doing) has very much to offer to users, and is behind many or even most real-world scheduling and optimization applications.
I agree with your point, I just would like to point out maybe the OR-tools they meant is the one made by Google, so a specific one: https://developers.google.com/optimization
OR-Tools has a lot of bindings in different languages, though Javascript/Node doesn't seem to be a first-class supported environment. Looks like https://www.npmjs.com/package/node_or_tools ports a few solver packages into Node so if those solvers fit your needs you can use this package.
To me this makes Prolog sound like a tool to reach for similar to SQL. Specialized language for asking specific kinds of search or query over your data.
Indeed Prolog programs are also called databases sometimes. Some things Prolog can do over SQL:
- infinite data defined by recursive predicates
- flexible data structures (think JSON but better, called complex terms) and a way to query them (called unification algorithm)
- execution strategy fine-tuned for reasoning (called resolution algorithm). You can do this with SQL but you’d have to formalize things using set operations and it’d be very very slow.
On the other hand, SQL can query plain data very very fast.
I've also wondered why Prolog or at least Datalog isn't available/used more widely as a query layer, especially considering that the promise of SQLs natural-ish language really didn't lead to a level of adoption among non-tech workers even approaching the popularity of the spreadsheet, so the reason for that style of syntax didn't really pan out, and Prolog would appear to have some syntactic and capability advantages.
I concur, Prolog particularly excels at being an advanced configuration, embeddable DSL that allows one to express system configurations that would otherwise be not easily possible using a bespoke configuration language or a format. I have used an embedded Prolog core to express complex installation configurations in the past with a great success, and I would do it again for the right problem space.
Maybe it's just me but I see a lack of a package manager as a massive, massive pro. I can't stand how seemingly every language has a package manager which requires it's own installation and you have to learn how to use THAT thing and then you need some library off github that does some minor task really well but you can't just download the fucking code, you have to import it via, idk, the Fork-Lyft manager which requires Python 3.3 and the PillJump framework and it's just like, I just want a fucking function to parse JSON, I don't want to saddle my system with 600 MB of shit I don't need.
You can always just download the code, nobody's forcing you to use a package manager. It just turns out that unless you want to spend most of your life building and fixing other people's code, it's much easier to use the package manager. The inefficiency is the price we pay, but it's worth it.
Me too! I absolutely see a lack of package manager as a pro. I also hate to saddle anything with 600MB I don't need. 100% agree.
I would go as far as to say that Prolog is more a problem solving language rather than a system building language. Package managers and module systems are for modularization of big systems. You don't need that when solving small recurrent problems. Furthermore, lack of them forces you to avoid dependencies, that most of the time would end as technical debt. IMHO.
Yes :) we make software that helps sell complex products (If your product has a million options and takes up a whole factory floor you can’t just have a series of dropdowns)
Thanks for the insight, Görkem! I was always thinking CPQs make a really good use case. We had so many problems with performance, not your product, CPQ is becoming a standard software for pricing contracts.
There are a lot of problems that Prolog / Constrain programming will solve very elegantly, and much more easily than imperative languages. I think constraint based programming is seriously under used in the industry, and too many programmers are unaware or unable to write constraint based code. I have always hoped to have just a constrain based programming subsystem in a lot of languages, for those niche cases.
- no proper module nor package system in the modern sense.
- in large code bases extra-logical constructs (like cuts) are unavoidable and turn Prolog code into an untenable mess. SWI prolog has single-sided unification guards which tackle this to a degree.
- lack of static and strong types makes it harder to write robust code. At least some strong typing would have been nice. See Mercury as an example of this.
All being said, Prolog is amazing, has a place in the future of programming, and gives you a level-up understanding of programming when you get how the types in every OO program is a Prolog program itself.