gorkempacaci

Hi Adrian! You’re doing great work Scryer Prolog, keep up the good work! :)

They're considering an IPO. I'd say an acquisition is unlikely. Even then, they'd be worth more to Facebook or MS.

nvidia hates this one little trick

How about the costs? Isn’t this a very expensive bandaid? How is it not a priority? :)

Yeah probably.

The generated programs are only technically Prolog programs. They use CLPFD, which makes these constraint programs. Prolog programs are quite a bit more tricky with termination issues. I wouldn’t have nitpicked if it wasn’t in the title.

Also, the experiment method has some flaws. Problems are hand-picked out of a random subset of the full set. Why not run the full set?

If I may nitpick, the call to children’s accept methods should be in the visitor, not the parent. Imagine you’re writing an XMLGeneratorVisiter. The visit method for the parent would print <parent>, call child accepts, and then print </parent>. If you do it the way it is done here you lose the control on when the children are visited.

Also, the point of the visitor pattern is not just pattern matching/polymorphism. Of course you could do it with polymorphism or conditionals or whatever. But the visitor pattern reduces coupling and increases cohesion. So you get a more maintainable, testable code base. Pattern matching with a candied switch doesn’t give you that.

Prolog was never good at the things they thought it would be at, like AI, which is better done by ML today, specifically often like you said, with NNs. But it turned out to be good for other things, and those use cases are still alive today, even though there are many competitors. Look at Tiobe index, Prolog's usage is constant just under 1 percent, and has been for decades. So it's good for something.

Yes :)

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.

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)

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.